1 5 min Admin: Call plan All 04 Feb 2022 Leader: Kam 11 Feb 2022 Leader: Bernd 18 Feb 2022 Leader: Scott; (Not available: Nigel) 25 Feb 2022 Leader: Martin 04 Mar 2022 Leader: Andrea 11 Mar 2022 Leader: Nigel 18 Mar 2022 Leader: Kam 25 Mar 2022 Leader: Scott 2 15 min
IISOMI Action Items status IISOMI Action Items review (every meeting) Action items done Nigel Davis 28 Jan 2022 Try to move TR-512 v1.5 core model to 2020-06 (4.16) Eclipse. Scott Mansfield 04 Feb 2022 Confirm that Gendoc works reliably with Papyrus 2020-06 Done. Scott confirmed that Gendoc works reliably with Papyrus 2020-06 Refreshed Action Items Nigel Davis determine what Jira form structure etc. 18 Feb 2022 ONF can create IISOMI. Provide example/detail etc. for discussion. Martin Skorupski 18 Feb 2022 To update on the progress in O-RAN of getting approval of an O-RAN project on UML-YANG tooling. Action item from 2022-01-21 IISOMI Meeting notes. 3 0 min UML → YANG Mapping Tool funding Martin O-RAN cooperation October 1: O-RAN policy has changed collaboration rules. (O-RAN Alliance is registered in Germany)
Martin Skorupski checked with O-RAN the tooling funding status. There is hope, not dead, but not moving either. Martin Skorupski 19 Nov 2021 Get a written statement from O-RAN leadership on state of tooling funding's November 19 discussion: Martin reported on the progress of requesting funding from O-RAN for UML-YANG tooling. The proposal will be up for voting in O-RAN. 2022-01-21: Martin Skorupskihe proposal reached the next level and moved from O-RAN TSC to O-RAN Executive Committee (EC). Discussion in O-RAN EC will start. has informed that t 2022-02-18: 4 15 min Attribute referencing Martin
Reference from an ObjectClass to a specific attribute(!) of another ObjectClass
we - the ONF OTCC 5G-xHaul group - have the "use case" to reference from an ObjectClass a specific attribute(!) of another ObjectClass, which is by itself a reference to the next ObjectClass.
[ClassAA] -> [ClassBB]
So in ClassAA there is an attribute of "classBB" with type ClassBB.
Now, we would like to configure in another ClassCC an attribute called "pointerToClassBBbyClassAA" - which points to the attribute ClassAA::classBB of type "ClassBB".
I'm looking into UML specifications and UML Modelling Guidelines.
https://wiki.opennetworking.org/display/OIMT/IISOMI+Deliverables#IISOMIDeliverables-IISOMI514UMLModelingGuidelines(editorBernd) Is my understanding correct that UML is not designed to reference a specific attribute but "only" ObjectClasses, DataTypes, ....? If yes, (and I still hope the answer to question #1 is no :) ) - could/should the "Reference Stereotype" be used for such case. an other option might by to add an association from ClassCC to ClassBB and constrain it with the values given in attribute ClassAA::classBB
Any suggestions how to handle the situation in Papyrus UML following IISOMI guidelines?
2022-02-04: The discussion concluded that option 3 (i.e., add an association from ClassCC to ClassBB and constrain it with the values given in attribute ClassAA::_classBB) is the right way to do. See the below. Post call email correspondence on using OCL 5 25 min Coding of target path In particular, if I understand correctly, for the root element object class (i.e., red element), the format is actually not “[/<ModelName>:<ClassName>:<navigable association end role name>]” as indicated in the UML guidelines v1.3.03 but it is in the format of “[/<ModelName>:<ClassName>:<name of the RootElement stereotype>]” Model Name or Prefix 2022-01-21: Italo Busi indicates that the UML guideline is not requiring the undescore in the nameof the RootElementstereotype, while the examples in the UML to YANG guideline include the undescore (e.g. TAPI currently has "_context"). It is recommendable to clarify and align the guidelines.
In particular, for the root element object class (i.e.,
red element), the format is actually not “[/<ModelName>:<ClassName>:<navigable association end role name>]” as indicated in the UML guidelines v1.3.03 but it is in the format of “[/<ModelName>:<ClassName>:<name of the RootElement stereotype>]”, e.g.
ptp:Ptp:_ptp/ptp:Ptp:_instanceList/ptp:Ptp:_transparentClockDefaultDs 2022-01-28: See 2022-01-28 IISOMI Meeting Minutes #4 for details of discussion Discussion conclusion:
The referencing mechanism used in the target path identifies each element in the path by going one step up the path (hierarchy) to find the referencing attribute from the class that references the class to be identified. This works for all but the root entity (where there is clearly nothing one step up the path hierarchy). This is why an artificial role end was used reference the root entity.
This is conveyed in the <<RootElement>> stereotype as shown above. It is as if a class Context references the TapiContext via a composition with a navigable attribute _context. The class "Context" does not exist in the model. Both the class name "Context" and its reference are derived from the value of the name in the <<RootElement>> Stereotype (i.e., "_context") where the class name is an upper camel form of the string with the "_" removed.
The mechanism should be described more clearly in the modeling guidelines.
Remaining issue Italo's second question " Should we use the module name (i.e., IetfPtp) or the module prefix (i.e., ptp) or either option? " Only briefly discussed. No definitive conclusion yet. It seems that in UML it should be the module name, and the mapping tool will then maps the module name to the module prefix. 2022-02-04: Bernd shared his off-line email discussion with Andrea on how to improve the explanation in section 5.4.3/TR514. In his off-line discussion, Bernd raised a question on second part ( of the path. yellow highlighted) No conclusion reached from the long discussion. Will continue the discusion in the next call. On Italo's second question " Should we use the module name (i.e., IetfPtp) or the module prefix (i.e., ptp) or either option? " Agree that in the UML model, the module name should be used because module prefix is a YANG term. Post call email from Italo: 0 min
UML modeling guidelines
UML modeling guidelines
Convention for the name of the non-navigable member ends of an association Have seen cases where these member ends do not have names, cases where they have LCC names and cases where they have names following the same convention as navigable attributes (_ + LCC) Cardinality for conditionally mandatory associations: should it be 1 or 0..1? 2022-02-04: No discussion. Deferred to 2022-02-11 6 0 min Papyrus Releases
November 19 discussion: The TR-512 v1.5 Core model was developed using Eclipse 2019-09. It the model can migrate to 2020-06 seamlessly, Q14/15 might move G.7711 v4.0 (12/2021 consent) also to Eclipse 2020-06. To verify the seamless migration: Nigel Davis 14 Jan 2022 Try to move TR-512 v1.5 core model to 2020-06 (4.16) Eclipse Hing-Kam Lam Try to move TR-512 v1.5 core model to 2020-06 (4.16) Eclipse 2021-12-03: from Kam - diagrams from TR-512 v1.5 core model on 2020-06 (4.16) Eclipse looks fine proposal for next week ITU-T: IISOMI moves to 2020-06, because gen-doc works find TAPI will follow after some tests will be done by Andrea Mazzini Nigel Davis 21 Jan 2022 Try to move TR-512 v1.5 core model to 2020-06 (4.16) Eclipse 2022-01-21: 2022-01-21: Brief discussion on 2020-06 (4.16) noting that Papyrus appeared to be OK (but Nigel Davis noted that in his environment Gendoc was still not working due to memory apparently). 2022-02-04: No discussion. Deferred to 2022-02-11 7 0 min
Proposals for capturing discussion items
2021-10-29 IISOMI Meeting Minutes #2
Prior discussion pointed out that:
a private repository is not the appropriate place for the items since not everyone has access to this the ONF GitHub is publicly available but not all participants are allowed to contribute to it there is no single ONF repository which could host such Issues; IISOMI is spread over many repositories it might be possible to cover the discussions in Wiki pages new discussions should be captured in the Meeting Minutes and then copied to the Wiki pages Bernd Zeuner 08 Oct 2021 Draft an example Wiki page that capture an discussion item
Proposal wiki page from Bernd for capturing discussion items:
2022-01-07: Follow-up after progress made with Jira ( 14 Jan 2022 ) as per action for Nigel Davis 2022-01-21: Scott Mansfield informs that IETF is not using JIRA, but Githuband its Issues. But as highlighted above, relying on Github for IISOMI seems not feasible. 2022-02-04: No discussion. Deferred to 2022-02-11 8 0 min Guideline/Tooling wiki page(s) for listing the tasks Andrea Mazzini Andrea Mazzini shows Guidelines and Tooling Discussion Items 2022-01-28
2022-02-04: No discussion. Deferred to 2022-02-11 9 0 min Feature/condition
IISOMI 2021-09-03 Meeting Minutes, #3 2022-02-04: No discussion. Deferred to 2022-02-11 10 0 min
Convention of UML property names in document/comment/description
2021-10-29 IISOMI Meeting Minutes #5 Bernd Zeuner 15 Oct 2021 Update the Mapping Guidelines with a rule that . artefact names within the descriptions should be converted to YANG style 2022-01-07: 2022-01-28
2022-02-04: No discussion. Deferred to 2022-02-11 11 0 min Papyrus-Model2Doc feature
2021-05-28 IISOMI Meeting notes #3 2022-01-21 post meeting notes: Scott Mansfield found the following links to various update sites and performed some tests:
last successful build (model2doc 0.8.0) works fine in 2021-12 (4.22) (Eclipse 4.22 and Papyrus 6.0).
2020-06 (4.16), none of the found Model2Doc versions works.
Even with Eclipse
2021-12 (4.22) but Papyrus 4.8, Model2Doc does not work.
The conclusion so far is that
only version 2021-03 (4.19) - Papyrus 5.1 and later seem to work with the 0.8.0 Model2Doc version. 2022-01-28
2022-02-04: No discussion. Deferred to 2022-02-11 12 0 min
2022-02-04: No discussion. Deferred to 2022-02-11 13 0 min
Cleanup of the existing public GitHub (ONF EAGLE), rationalize the forks/branches
IISOMI 2021-09-24 Meeting Minutes #10 2022-01-28
2022-02-04: No discussion. Deferred to 2022-02-11 14 0 min
2021-05-28 IISOMI Meeting notes #6 Scott Mansfield 18 Feb 2022 Provide gendoc examples to implement the first two bullets 2021-05-28 IISOMI Meeting notes #6 GenDoc didn't generate constraint GenDoc OstigOTtpSource::txti:EByte multiplicity  is not generated correctly Discussion Needed: To agree on a specific format for operation, then implement 2022-01-28
2022-02-04: No discussion. Deferred to 2022-02-11 15 0 min Modular and decoupled modeling process
CoreModel FD - to of the tree
Composed FC-Switch .... with no sense if
Driver of Model structure (arrangement)
usage of stereo-types
aggregate leaf admin relationships Chris has nice ideas - but needs to be further analyzed.
First try of "modelling profiles" on CoreModel
Target: Split CoreModel in "smaller" parts - decoupling Rules needs to be described/defined/documented. Further details: 2022-01-07: Nigel Davis noted that OIMT have agreed to develop the profile and apply to a part of the core as an example. This can be presented to IISOMI in February. Nigel Davis 18 Feb 2022 Provide an overview of the DDD trial profile and show application to the core model. 2022-01-28
2022-02-04: No discussion. Deferred to 2022-02-11 16 Agenda of next call All Administrative Coding of Target Path UML modeling guidelines questions from ITU-T Q14/15 YANG expessions for Union & Intersection UML → YANG Mapping Tool funding (Feb. 18) Papyrus Releases Consider a plan for convergence of ITU-T Q14/15, ONF Common IM and TAPI to 2020-06 (4.16) version Proposals of capturing discussion items Feature/condition Convention of UML property names in document/comment/description Papyrus-Model2Doc further investigations? Private GitHub Public GitHub cleanup Gendoc Issues: output for Interfaces, Operations, Associations, Abstractions Modular and decoupled modeling process AOB