Due to a ransomware attack, the wiki was reverted to a July 2022 version. . We apologize for the lack of a more recent valid backup.
Child pages
  • 2022-02-18 IISOMI Meeting Minutes

Date

Attendees

Apologies 

Agenda

  • Administrative
  • Coding of Target Path – defer to next weeks call
  • Add values to an existing core-model enumeration
  • 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

Discussion items

#

Time

Item

Who

Notes

15 minAdmin: Call planAll

 Leader: Martin

 Leader: Andrea

 Leader: Nigel

US/Canada: Daylight Savings Starts 13 March.  Eastern Daylight Time is UTC-4

Leader: Kam

Leader: Scott

Europe: European Summer Time Starts 27 March CEST is UTC+2

210 min

Admin: IISOMI Action Items status

All

IISOMI Action Items review (every meeting)

No Action Items with due date today

Action Items done

none

Refreshed Action Items

UML-YANG tooling discussion is still underway in O-RAN and more meetings will be held next week.

  • Scott Mansfield    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 [64] is not generated correctly
    • Discussion Needed:  To agree on a specific format for operation, then implement
  • Scott Mansfield  To take the gendoc examples from the guidelines and perform regression test. 
    • Also decide on version of gendoc and Papyrus
    • Version for initial regression test is p2020-06
    • Andrea indicated the had attempted to apply analogous rules to member-end to include other properties. Andrea tried various techniques to get client and supplier but with no success 
      • Probably need to review the UML metadata
    • Andrea was able to print the target string
  • Scott Mansfield  To investigate how to get client and server values for an abstraction association for gendoc.
30 min

Add values to an existing core-model enumeration

Martin

the ONF OTCC 5G-xHaul group would like to get guidance how to add microwave specific layer-protocol-names to core-model:layer-protocol-names (e.g. microwave-physical-section, microwave-section, ....). More abstract: How can a conditional package add values to an existing (extensible) core-model enumeration?

To demonstrate, create a enum and then extend the enum using either specify or generalization. Determine how to display this in GenDoc.  Determine the guidelines needed to convert this structure to YANG.  Initial thoughts are to ensure isLeaf = false so Identity is used in YANG.  For example the core model enum would be the base and the specify or generalization would extend the base identity.

40 min

UML modeling guidelines questions from ITU-T Q14/15

Italo
50 minUML → YANG Mapping Tool fundingMartin

O-RAN cooperation

October 1: O-RAN policy has changed collaboration rules. (O-RAN Alliance is registered in Germany)

October 15: Martin Skorupski checked with O-RAN the tooling funding status.  There is hope, not dead, but not moving either. 

  • Martin Skorupski  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 Skorupski has informed that the proposal reached the next level and moved from O-RAN TSC to O-RAN Executive Committee (EC). Discussion in O-RAN EC will start.


60 minAttribute referencingMartin

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.

Example:

[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)

  1. Is my understanding correct that UML is not designed to reference a specific attribute but "only" ObjectClasses, DataTypes, ....?
  2. If yes, (and I still hope the answer to question #1 is no :) ) - could/should the "Reference Stereotype" be used for such case.
  3. 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

750 minCoding 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 name of the RootElement stereotype, 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. 

    • PtpTlpDefaultDsSpecSpecifiesPtpDefaultDs: /ptp:Ptp:_ptp/ptp:Ptp:_instanceList/ptp:PtpInstance:_defaultDs

    • PtpTlpPortDsSpecSpecifiesPtpPortDs: /ptp:Ptp:_ptp/ptp:Ptp:_instanceList/ptp:PtpInstance:_portDsList

    • PtpTlpTcDefaultDsSpecSpecifiesPtpTcDefaultDsPac: /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.

      • Andrea Mazzini Bernd Zeuner:  To improve the explanation of target sterotype string content formation by  

  • 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 (yellow highlighted) of the path.
  • 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:

2022-02-11:

In order to be able to compose the target path of the two «Specify» relationships the class diagram below has been extended with the greyed out "non existing" object class and composition relationships.

Andrea Mazzini will draft rules for the UML Modelling Guidelines for creating the target paths; this is part of the existing action item "Improve explanation of target sterotype string content formation in the UML Guidelines". Discussion will continue in two weeks.

80 min

UML Modeling Guidelines

Italo

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

90 minPapyrus Releases

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  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  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

100 min

Proposals for capturing discussion items 


Prior discussion: 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  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 (  ) as per action for Nigel Davis 

2022-01-21:

  • Scott Mansfield informs that IETF is not using JIRA, but Github and its Issues. But as highlighted above, relying on Github for IISOMI seems not feasible.

2022-02-04: No discussion. Deferred to 2022-02-11

110 minGuideline/Tooling wiki page(s) for listing the tasks Andrea Mazzini 

Andrea Mazzini shows Guidelines and Tooling Discussion Items

2022-01-28

No update.

2022-02-04: No discussion. Deferred to 2022-02-11

120 minFeature/condition

Prior discussion: IISOMI 2021-09-03 Meeting Minutes, #3

2022-02-04: No discussion. Deferred to 2022-02-11

130 min

Convention of UML property names in document/comment/description

Prior discussion: 2021-10-29 IISOMI Meeting Minutes #5

  • Bernd Zeuner  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

No update.

2022-02-04: No discussion. Deferred to 2022-02-11

140 minPapyrus-Model2Doc feature

Prior discussion: 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:

The last successful build (model2doc 0.8.0) works fine in 2021-12 (4.22) (Eclipse 4.22 and Papyrus 6.0).

Regarding 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

No update.

2022-02-04: No discussion. Deferred to 2022-02-11

150 min

Private GitHub

2022-01-28

No update.

2022-02-04: No discussion. Deferred to 2022-02-11

160 min

Cleanup of the existing public GitHub (ONF EAGLE), rationalize the forks/branches

Prior discussion: IISOMI 2021-09-24 Meeting Minutes #10

2022-01-28

No update.

2022-02-04: No discussion. Deferred to 2022-02-11

170 min

GenDoc Issues

Prior discussion: 2021-05-28 IISOMI Meeting notes #6

  • Scott Mansfield    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 [64] is not generated correctly
    • Discussion Needed:  To agree on a specific format for operation, then implement

2022-01-28

No update.

2022-02-04: No discussion. Deferred to 2022-02-11

180 minModular and decoupled modeling process

2021-12-03

from OIMT

CoreModel FD - to of the tree

Composed FC-Switch .... with no sense if independent

.

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  Provide an overview of the DDD trial profile and show application to the core model.

2022-01-28

No update.

2022-02-04: No discussion. Deferred to 2022-02-11

19
Agenda of next callAll
  • Administrative
  • Coding of Target Path
  • Continue discussion on adding values to an existing core-model enumeration
  • 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

Action items

  •