AI: Nigel Davis To provide the WT profile mechanism for discussion with Chris next week.
Conditional augmentation using constraint with simple xPath statement
A general profile class and a set of pacs of attributes associated to the profile
The application of the pacs are governed by the constraints. There is example in the UML-YANG guideline section 5.6.2.
A more general approach would be: Soft class with hard attributes (e.g., profile role that drives the augment).
WT driving use case: Lp profile
Two type of profiles: constraint profile (e.g., with range), instance profile (e.g., with specific concrete values)
Much discussion occurred on datatypes
Karthik: In TAPI, LayerProtocolName and LayerProtocolQualifier are defined in the TapiCommon module.
The LayerProtocolName is a Enum
The LayerProtocolQualifier is an extensible Enum, but it is intentionally empty in the common module and is expected to be augmented with layer-specific values in the respective technology-specific modules. Note that some example qualifiers of some LP names are provided in the description (Applied comments) of LayerProtocolQualifier.
Nigel comment: they should be in one place.
Karthik response: there are (will be) lot of unnecessary stuff in the Common datatype;
Nigel: no problem to remove those unnecessary stuff and even rename to such as ONF Common datatype.
AI: Nigel DavisKarthik Sethuraman (TAPI call) Discuss off line for a proposal on which datatypes should go into Common vs technology-specific modules. Datatypes to be considered will include Layer protocol (go to common), qualifier, and other things, such as operational state, alarm, performance monitoring, etc.
Nigel is working on aligning the TAPI equipment and the WT equipment models
Discussion on the use of class vs datatype.
Nigel reported that
Currently what the WT folks has been done with the Core model differ from the TAPI that they use classes rather than datatypes
Nigel and Martin think that the output YANG from the Core model form and output YANG from the datatypes from the tooling are essentially the same.
Nigel is trying to transform the core to datatype base and in parallel Martin will generate YANG from the core class to see what will come out from that. And see whether to align the core with TAPI.
Karthik noted that we should revisit the datatype mapping. He thinks the current way of dataype mapping is wrong, it should be a type, cannot be a grouping.
Nigel: What will the implication then?
Nigel: In core, use datatype for structural content
Karthik: If as class, then one has to provide an API for operations
Nigel: So the output YANG of class and datatype are the same is wrong. The output YANG of class and datatype should not be the same.
Datatype does/should not have object ID.
Nigel: What does the tool do with class without an ID defined?
Karthik: The tool map it to grouping. In YANG, one can have a list of things as typedef without a key. For class without and ID defined, you need to put a key in there so that looks like a class. Need a key if it is configurable.
Nigel: If it is not configurable, it is read-only, you don't need to address it. No key is fine.
Nigel: We can augment a list to add a member to the list.