| 45min | Ethernet CFM | Bernd, Kam | - IEEE p802.1Qcx CFM YANG
- UML of IEEE p802.1Qcx CFM YANG July 3rd version
- oimt2018.BZ.001.05_PapyrusIeeeCfmOxygenWorkspace_180703.zip
- Conclusion from previous discussion 2018-07-17 OT-IM Meeting Notes
- YANG key leaf is mandatory (and no need of the mandatory statement)
- Thus in the UML model, the object key attributes should be mandatory
- maintenanceGroup: MaintenanceGroupType [1]
- mdId: NameKeyType [1]
- maId: NameKeyType [1]
- _mepId: Mep [1]
- Bernd presented the updates to the CFM UML that he has made (posted as oimt2018.BZ.001.06_PapyrusIeeeCfmOxygenWorkspace_180731.zip):
- Attributes marked as "partOfObjectKey" have now a multiplicity of "1"
- Groupings containing a choice statement are now modeled according to the latest state of the discussion in IISOMI: I#298
- bridge::ServiceId
- types::MdNameChoice
- types::MaNameChoice
- Typedefs of type "bits" are now modeled according to the latest state of the discussion in IISOMI: I#296
- types::MepDefectsType
- types::ConfigErrorType
- types::MepTxLtmFlagsType
- Need explanation from Marc:
- Why the key attribute of Mep is a pointer attribute: _mepId
- In the UML, do we still need a pair of leaf to identiy a MA? To identify a Mep? etc.
- Following the pattern of the YANG module will end up with the non-ideal UML model, e.g.,
- having a pair of leafref to identify an object instance
- having the extra level of containment (MaintenanceDomains contain MaintenanceDomain, etc.)
- No conclusion yet.
- G.8052.1:
- Consider augmenting the (Mepieee802-dot1q-cfm::Interface)Actions with (G.8052.1::Interface)EthMepActions, which consists of the G.8052.1 pruned/refactored operations.
|