1. Pages
2. …
3. OIMT
4. Core Model
5. OIMT minutes
6. 2019 OIMT Minutes

2019-07-11 OIMT Meeting notes

• Face-to-Face Meetings
  • 2019 September 9-13 ONF OIMT & OTCC Silicon Valley Meeting
    • Nigel has had a new open git repository created at https://github.com/OpenNetworkingFoundation/CoreInfoModel. It is currently empty.
    • Nigel will populate the repository with the 1.4 version of the model in master and then the recent changes that have been applied (minor corrections) in develop.
      
      • In this process various old model fragments will NOT be propagated from the private git repository. This repository will continue to be present  It is intended that that repository be deleted later this year once all relevant material has been moved to the public repository.
• O-RAN
  • Nigel mentioned the meeting later today (invite sent by email to the distribution).
    • This will provide an opportunity for us to share insight with O-RAN
• There was no feedback on the Action items and work items

• Nigel gave some background
  • The WT model is a pruned/refactored form of the Core model that is close to the Core model
  • The Core Equipment model is defined with classes for ExpectedEquipment etc.
  • The TAPI model is a pruned/refactored from of the Core model
  • The TAPI Equipment model is defined with data types for ExpectedEquipment
    • This resulted from agreement in the Sydney meeting on when to use classes and when to use data types
  • The intention is to align the core with the Sydney agreement but this has not yet been done
    • This will mean the TAPI model and the Core model are the same in this area
      
  • Several weeks back it was agreed that the WT Equipment model would continue to follow the Core
    • At the time it was expected that there would be no difference between the coding of data types and composed classes
    • It was expected that when the Core migrated to data types, the WT Yang would not change
      
• Nigel explained the position that has been agreed in IISOMI wrt data type and class mappings into Yang.
  • Both classes and data types will be mapped to yang groupings
  • All classes will also have an identity generated (triggered indirectly by a reference attribute _xxx and directly for root classes)
    • The identity will be a UUID
      
      • Note that there is still an outstanding action to consider the implications of the removal of local id
  • When an attribute of a class is defined by a data type then this will become substructuring in the instance of the class that has the attribute
    
    • When the attribute definition is multiplicity >1 then there will be a key in Yang and this Key can be any local value (Integer etc.)
  • When an attribute of a class is named xxx and is hence defined by a referenced class and where the association is composite, in the instance the referenced class structure will become substructure of the referencing class with the attribute (i.e., as for the data type)
    • When the attribute definition is multiplicity >1 then there will be a key in Yang and this Key will normally be the UUID of the instance of the class
  • The structures are essentially the same but the key type is different. This was a larger difference than had been expected
    • Nigel emphasized that this meant that when the core was migrated to align with the data type agreement the Yang would change in this area
• Chris asked whether this changed the identity agreement
  • Nigel emphasized that this did not cause or require any changes in the Sydney agreements on IDs
• Martin indicated that he could use his pruning/refactoring tooling and the UML/Yang tooling to deal with this such that the WT Yang aligned with the TAPI Yang in this area even with no change to the Core model. When the core model is updated to align with the data type agreement the WT Yang would not change in this area.
  
  • This was considered as the right approach.

• AI: Nigel DavisMartin Skorupski: Discuss the fine details of the class/data type mapping 12 Jul 2019

Note also that:

• In TAPI the properties that are available in ExpectedEquipment and ActualEquipment differ as there are two distinct data types collecting properties where both are used in the ActualEquipment and only one is used in the ExpectedEquipment.

• In the core, and hence WT, there is only one collection of all relevant properties that both use.

Hence there will be subtle differences if the Core is changed to align fully with TAPI. There is good reason for keeping all properties in one collection in future.

• It was agreed to defer the agenda item until other key participants were available
• Nigel/Andrea summarized the essential concern
  • An intent can be defined in terms of constraints where those constraints may identify specific entities. If the constraint is intended to be throughout the life of the entity then this puts a lifecycle dependency between the constrained thing and the constraining thing. There appear to be various possible dependencies but the constraint is not explicit as to which one is relevant.
  • It appears that this has not been covered in any known prior work

• AI: Hing-Kam Lam Nigel Davis: Add CoRouting Constraint to next week's agenda.

Brief update on progress by WT team (Martin)

• Martin described the profile model (note that the model and diagram below is not finalized)
  • The model represents the view exposed by an NE at the NE interface
  • The control construct is being used to represent the device control
    • Chris noted that constraint domain is used for this and is also used between the ControlConstruct and Equipment
    • Martin/Nigel explained that the wireless devices are very simple compared to other devices and that unnecessary complexity would cause the device teams to not use the model
  • Chris asked why there was a ProfileCollection that has a 1:1 relationship to ControlConstruct
    • Nigel noted that in a general case a ControlConstruct may have many (indirectly) associated
    • It was agreed that the profiles ought to be attached to the ControlConstruct via an augmentation (this could either be ControlConstruct augmented with ProfileCollection or with Profile)
    • Martin Skorupski Nigel Davis: Associate the ProfileCollection to the main model via «Specify»
  • The Profile is a class that is used in a similar way to LayerProtocol
    • When a Profile instance is created it is augmented with specific properties defined in groups
      
      • The augment is triggered by the «Specify» stereotype as per LayerProtocol from LpSpec
    • Unlike LayerProtocol, all the properties are write-create
      • It was noted that write-create is denoted by the attribute being set to Invariant via the appropriate stereotype and to not read only (normal UML property)
    • In a deployment, many different groups of properties will be associated the Profile class via
      
      • The augment method has been advanced using a constraint (not shown in the specific model but shown in the the modeling guidelines figure lower down) that is encoded in Yang as a "when" statement and where the value of profileName drives the specific augment (the type is an extensible enum).
        • It was noted that the profileName is invariant

• Figure 5.31: Conditional «Specify» Abstraction Relationship Example from Draft_TR-514_UML_Modeling_Guidelines_v1.3.02.docx

• It was agreed that the «Specify» mechanisms were not sufficiently documented

• AI: Nigel Davis Andrea Mazzini: Provide rich documentation on the «Specify»/Augmentation approach.

Deferred

AI: 2019-07-11 OIMT Meeting notes 2019-07-11 OIMT Meeting notes: Add "next release of TR-512" to next week's agenda.