Determine what the correct Spec reference is (UUID etc.)
Ensure that all model elements can refer to a spec
Develop spec for each entity through value-justified-steps
Multiple Contexts and other approaches to providing views of subsets of information Nigel Davis
Note that this has been moved up from "Next Major Release" as it does not appear to need TAPI changes and is more of a usage description.
As Context is the root of the tree, there can clearly only be one context per provider connection
There could be multiple alternative connections (connection sets) that would be separately secured where each would provide a context with a specific view (slice etc.).
This could be used as a solution to provide only relevant profiles (e.g., the client is only interested in OAM profiles and other OAM things as it deals only with OAM so there is an OAM Context)
An alternative solution for providing subsets (as opposed to using a full context) is for a "constrain domain" equivalent to be used to collect together things of interest based upon some policy etc. and that list of items can then be retrieved as a collection or streamed based upon the collection
This could collect all oam profiles or all services of a particular characteristic etc.
This could be used
Get the "constraint domain" to provide the list of uuids and then getting each individually
Further development of transmission capability feature
Extension mechanism: This is not documented visibly:
Determine what degree of extension is allowed and where (especially accounting for the spec work – a vendor must be enabled to insert a spec that expresses their precise equipment capability as a replacement for the standard spec (e.g., Ethernet port)
Ensure that we document the approach and define some level of “enforcement”
Overall document structure
may want to separate out informative/explanatory model text from normative text (as per core)
may want to separate out definitions (such as top level connection)
Where alarm etc. analysis has taken place in the controller and it is able to provide a summary of problems with associated alarms
There are two focusses
Resolving the problem
Understanding the impact
May incorporate service jeopardy reporting
Adoption of a specification model approach as described in the ONF Core model (Nigel Davis )
Each entity/aggregate will have the opportunity for addition of a specification
The specification is per type and it constrains legal values (sometimes to invariant values that then do not need to be reported in the instance)
CSEP and ConnectivityService represent a hybrid of intent and abstraction of actual state of the CEP. The purpose of each field is sometimes unclear. It is important to separate intent from current state clearly. (Nigel Davis )
The client may also want to send an initialization value but hand control to the provider to choose the value after initialization.
For example, the client may wish to set a constraint on the channel/wavelength or may wish to leave the choice to the provider. Regardless, there will be an actual channel/wavelength. Clearly, the CSEP could reflect the current channel/wavelength, but this must be separate from the intent statement, as otherwise it will appear that the channel/wavelength was an intent.
Considering this, it appears that there are several cases:
Initialization value, that does not need to be retained in the intent once the intent has been initially realized. It is provided in the request but only available until the first realization is determined.
e.g. AdminState of Locked
Constraint value, that does need to be retained in the intent. There should also be an achieved state that is separate from the intent.
e.g., channel should be between 6 and 12... actual channel is 9
No constraint value where current state does not need to be reflected.
e.g., channel where the control plane is fully in charge and the client is not interested in an abstraction of the CEP in the intent as it can get the CEP
Current state that is never has a constraint
e.g., OperationalState where the client requires a reflection of the operational state of the CEP in the CSEP (why??)
A constraint that is further narrowed on design
e.g., use any connector in the range AccessPort 1 to AccessPort 12. What ever is chosen becomes the intent, so if AccessPort 3 is chosen, the intent changes from 1-12 to 3.
It is not clear whether there is a relevance to keeping the initial intent and the new narrower intent, or whether it is irrelevant.
A preferred value under certain circumstances
The above list suggest a multiplicity of values for each property
The provider should not reflect an actual value in the initial intent etc.
Where it may not be necessary, based upon some policy, to reflect current state in the CSEP/ConnectivityService as it is considered as pure intent
It should also be recognized that it may not be possible to constrain some parameters under some circumstances.
Ideally, the provider should express capability under all relevant conditions and for all relevant combinations
Minimally, the provider should reject cases that it cannot support
Clearly some constraints may be preferences and/or there may be options. The structure should reflect degree of relevance of a constraint
And this should be reflected by the provider as appropriately
(Previous item was a subset "Support for "initialization parameters" (Nigel Davis )
For example, where the property is provided in the CSEP but is not intent and hence does not appear in a CSEP read (it is a write only parameter! - need to develop this further)
Note that the property will appear in the CEP and may need to be subsequently adjusted"