2022-05-13 IISOMI Meeting Minutes

Date

13 May 2022

Link to web conference: https://onf.zoom.us/j/853336915?pwd=N1d5SnltUmhHOHlvVk44WmgrNkxDdz09

Attendees

Apology

Martin Skorupski

Agenda

Administrative
- Call plan (schedule, leader)
- Review IISOMI Action Items
MetaModelAgent for Papyrus (brief discussion)
Other potential agenda items [None discussed]
- Relationship between the support property and the multiplicity property of an attribute, operation and operation parameter
- Coding of Target Path
- UML modeling guidelines questions from ITU-T Q14/15
  - Cardinality for conditionally mandatory associations: should it be 1 or 0..1?
- 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
- 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

1

0 min

Admin: Call plan

All

13 May 2022 Leader: Andrea

20 May 2022 Leader: Kam

27 May 2022 Leader: Scott

03 Jun 2022 Leader: Bernd

10 Jun 2022 Leader: Andrea

2

0 min

Admin: IISOMI Action Items status

All

IISOMI Action Items review (every meeting)

Action Items with due date today/done/discussed

None.

Refreshed Action Items

Nigel Davis 20 May 2022 Determine what Jira form structure etc. ONF can create for IISOMI. Provide example/detail etc. for discussion.
Italo Busi 20 May 2022 Coding of target path: Provide an update to the diagram and propose text for the mapping guidelines.
Andrea Mazzini 20 May 2022 Review the proposed Gendoc script from Scott on retrieving the «Cond» properties of an association.
- Andrea considered yang translation
  - «Cond» on attributes is translated into if-feature statement but with limits (e.g., OR/AND is not supported)
  - «Cond» on associations usage is limited to abstractions and conditional augmentations. This is not translated into Yang.
  - Reference by value translation loses the condition statement in the yang translation. This will have to be done by hand.
    - Many of the property conditions could be on groups of properties that are in packages and hence referenced by value and hence on member end and hence lost.
  - Note that the «Cond» works on containers and leaves.
- Noted that «OpenModelClass» has a condition.
Scott Mansfield 20 May 2022 Firstly, explore all condition statement that are in other stereotypes (not just «Cond»). Fix if statements as necessary. Consider any place where stereotype information is to be printed (this requires this code). Consider code for (perhaps using several separate runs):
- - - Loop over all stereotypes and print all attributes that are NOT empty/default
    - Selecting specific stereotype list
    - Printing all

2a

0 min

MetaModelAgent for Papyrus (brief discussion)

All

Tool and models would be useful for modeling. Challenge is licensing. Understanding how this would work in an open source standards solution (licensing, copyright, trademarks). May be worth a meeting. How would the tool be used in an open source.

This is the juncture of Open Source, Standards, and proprietary software licensing and trademarks.

Scott Mansfield 20 May 2022 Invite MetaModelAgent to the call on 27 May 2022 to discuss their tooling. Open the invitation with an explanation of the open source nature of our work and the implication for them.

3

0 min

Add values to an existing core-model enumeration

Scott/Bernd/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.

Scott Mansfield 04 Mar 2022 Demonstrate small example of enums with gendoc

2022-03-18:

Scott Mansfield 01 Apr 2022 Demonstrate small example of enums with gendoc

2022-03-25:

Determine the enumeration literal equivalent for allAttributes() method to get all the attributes (including the inherited ones.

2022-04-22:

Conditional relationship in Gendoc

Scott presented to following Gendoc script:

Stereotypes need to be extracted from the association not from the class.

Andrea Mazzini 29 Apr 2022 Review the proposed Gendoc script from Scott on retrieving the «Cond» properties of an association.

Client and server values for an abstraction association in Gendoc

Scott presented to following Gendoc script:

→

Using "inheritance" (IISOMI) or "abstraction" (TAPI) to enhance Enumerations?

Requirement: Need to be able to use the complete set of all defined literals (left part of the figure) as a type of an attribute/parameter; this is not possible using inheritance.

Decision: Use «abstraction» and map this in YANG to identity/base.

Open issue: Abstract Enums required?

Scott Mansfield 29 Apr 2022 Upload Word files from presentations on Conditional relationship in Gendoc and Client and server values for an abstraction association in Gendoc to the minutes.

4

0 min

UML modeling guidelines questions from ITU-T Q14/15

Italo

Decision expected from IISOMI

Concern on augment rules

UML/YANG Guidelines should be improved(?)

keep text in UML to YANG Guidelines

UML Guidelines RootElement

multiplicity: 0 or 0...n or * → the root element is optional
multiplicity: 1 or n or 1..* or n ... * → root element is mandatory
multiplicity: n...*, n → root element is a list (not in container)

Update in mapping Guidelines expected

Discussion to be continued ....

suggestion: manual adoptions after yang generation

Examples about RootElement representation in YANG (thanks Italo)

/tapi-context/tapi-topology-context/topology[uuid=<topology-uuid>]

/topologies/topology[id=<topology-id>]

container example {
   presence
     "Presence represents <condition>"
   leaf foo {
     type string;
     mandatory true;
   }
   leaf bar {
     type string;
   }
}

container example {
  leaf is-present {
    type boolean;
    default false;
    description
      "Represents <condition>";
  }
  leaf foo {
    type string;
    mandatory true;
    when ../is-present;
  }
  leaf bar {
    type string;
    when ../is-present;
  }
}

  leaf bar {
    type string;
    when true() {
      description
        "<UML condition>";
    }
  }

2022-04-01:

Usage of abstract class
Please see too email from Italo
Value of the root-element property ('target' attribute)
- model name
- class name (camel-case)
- navigable attribute
There is an agreement that we use such pattern/rule in future - Bernd is going to update the guidelines.

multiplicity on root element → value "1" will be the default value

Is it described that the composite class of the a abstract "spec" class becomes an attribute the the class which will be "specific".
- yes
- ... but there is a following finding
  - in TAPI topology the "TAPI Topology Context" class is not abstracts
  - The UML guidelines should get a note about the consequences if the class is NOT abstract as assumed and preferred by the UML Guidelines.

Please see latest adaptation by G.7721.1 PTP Overview (Thanks Italo)

5

60 min

UML modeling guidelines

Bernd

2022-04-29:

UML modeling guidelines

Cardinality for conditionally mandatory associations: should it be 1 or 0..1?

Guideline document section 5.10; proposal:

2022-05-13:

Bernd Zeuner shows paragraph 5.9.6 Enumeration Enhancements

Agreed that both the intra and inter module examples of augmentation are valid.
Agreed to add the clarification regarding Is Leaf property of the enums, which must be false if it is not excluded a priori any extension.
Recalled and agreed that the augmenting classes/data types/enums shall be defined as abstract, as they will never be instantiated independently, but always as a part of the augmented artifact.
Agreed to remove the generalization/inheritance regarding enums. The abstraction works better, allowing more flexible combinations of supported values per given environment.

Bernd Zeuner shows paragraph 4.4 Model Extension Restrictions

Bernd Zeuner proposes a restructure of the chapter, removing the descriptions of UML Papyrus features which we have never used so far (e.g. the attribute redefinition).
- Also agreed to simplify the description of specialization, keeping the figure below:

Andrea Mazzini Maybe mention that another way to extend a base class is the composition, i.e. the conditional package concept.

6

0 min

Coding of target path

Andrea Mazzini Italo Busi

Hing-Kam Lam

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 18 Feb 2022

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:

RE_ IISOMI_ Action Item on Specify target path.msg

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.

2022-03-04:

Italo Busi presents an UML diagram with abstraction examples and related translations into Yang augment statements.

The following cases are considered:
- augment <--> simple composition (one additional node in the tree)
- augment <--> extendend composition (no additional node in the tree)
Another reference is the email "Augmentation issues with UML2YANG" of 18 Feb 2022 by Italo Busi
Clarified that the root of a Yang tree could also be a leaf or a list, besides a container.
Clarified that the Yang augment statement applies when elements are distributed across different Yang modules.
Italo Busi proposes to set as abstract the augmenting class in case the container is not required.
Andrea Mazzini currently in TAPI UML the translation always leads to a container, e.g. the odu-connectivity-service-end-point-spec:

 augment "/tapi-common:context/tapi-connectivity:connectivity-context/tapi-connectivity:connectivity-service/tapi-connectivity:end-point" {
     container odu-connectivity-service-end-point-spec {
         uses odu-connectivity-service-end-point-spec;
         description "none";
     }
     description "none";
 }

Which is then an additional node in the Yang tree:

  +--rw context
     | ...
     +--rw tapi-connectivity:connectivity-context
     |  +--rw tapi-connectivity:connectivity-service* [uuid]
     |  | ...
     |  |  +--rw tapi-connectivity:end-point* [local-id]
     |  |  | ...
     |  |  |  +--rw tapi-odu:odu-connectivity-service-end-point-spec
     |  |  |  |  +--rw tapi-odu:odu-csep-common-pac
     |  |  |  |  |  +--rw tapi-odu:odu-type?                  odu-type
     |  |  |  |  |  +--rw tapi-odu:odu-rate?                  uint64
     |  |  |  |  |  +--rw tapi-odu:opu-tributary-slot-size?   odu-slot-size
     |  |  |  |  +--rw tapi-odu:odu-csep-ctp-pac
     |  |  |  |  |  +--rw tapi-odu:tributary-port-number?   uint64
     |  |  |  |  |  +--rw tapi-odu:tributary-slot-list*     uint64
     |  |  |  |  +--rw tapi-odu:odu-csep-ttp-pac
     |  |  |  |     +--rw tapi-odu:configured-mapping-type?   mapping-type
     |  |  |  |     +--rw tapi-odu:configured-client-type?    tapi-dsr:digital-signal-type

Italo Busi highlights that current translation does not allow distinct labels for the container and for the used class. By always specifying as abstract the augmenting class we may allow both ways.

Post meeting note: Italo Busi provides the updated diagram with a summary of the agreements-

Below the base model example:

The tree, note the abstract ClassA which is not translated, and abstract ClassC which is forcedly translated by the "presence condition".

  +--rw root
     +--rw element* [element-key]
        +--rw element-key    string
        +--rw leaf-1?        string
        +--rw leaf-2?        string
        +--rw leaf-a-1?      string
        +--rw leaf-a-2?      string
        +--rw container-b
        |  +--rw leaf-b-1?   string
        |  +--rw leaf-b-2?   string
        +--rw container-c!
        |  +--rw leaf-c-1?   string
        |  +--rw leaf-c-2?   string
        +--rw list-d* [key-d]
           +--rw key-d       string
           +--rw leaf-d-1?   string
           +--rw leaf-d-2?   string

The schema:

module base-model-example {
yang-version 1.1;
namespace "urn:test:base-model-example";
prefix b;

grouping model-root {
list element {
key element-key;
uses model-element;
}
}

grouping model-element {
leaf element-key {
type string;
}
leaf leaf-1 {
type string;
}
leaf leaf-2 {
type string;
}
uses class-a;
container container-b {
uses class-b;
}
container container-c {
presence
"Presence condition";
uses class-c;
}
list list-d {
key key-d;
uses class-d;
}
}

grouping class-a {
leaf leaf-a-1 {
type string;
}
leaf leaf-a-2 {
type string;
}
}

grouping class-b {
leaf leaf-b-1 {
type string;
}
leaf leaf-b-2 {
type string;
}
}

grouping class-c {
leaf leaf-c-1 {
type string;
}
leaf leaf-c-2 {
type string;
}
}

grouping class-d {
leaf key-d {
type string;
}
leaf leaf-d-1 {
type string;
}
leaf leaf-d-2 {
type string;
}
}

container root {
uses model-root;
}
}

Below the augment model example:

The tree:

  augment /b:root/b:element:
    +--rw leaf-a-1?   string
    +--rw leaf-a-2?   string
  augment /b:root/b:element:
    +--rw class-b
       +--rw leaf-b-1?   string
       +--rw leaf-b-2?   string
  augment /b:root/b:element:
    +--rw container-c!
       +--rw leaf-c-1?   string
       +--rw leaf-c-2?   string
  augment /b:root/b:element:
    +--rw list-d* [key-d]
       +--rw key-d       string
       +--rw leaf-d-1?   string
       +--rw leaf-d-2?   string

The full tree:

  +--rw root
     +--rw element* [element-key]
        +--rw element-key      string
        +--rw leaf-1?          string
        +--rw leaf-2?          string
        +--rw leaf-a-1?        string
        +--rw leaf-a-2?        string
        +--rw container-b
        |  +--rw leaf-b-1?   string
        |  +--rw leaf-b-2?   string
        +--rw container-c!
        |  +--rw leaf-c-1?   string
        |  +--rw leaf-c-2?   string
        +--rw list-d* [key-d]
        |  +--rw key-d       string
        |  +--rw leaf-d-1?   string
        |  +--rw leaf-d-2?   string
        +--rw a:leaf-a-1?      string
        +--rw a:leaf-a-2?      string
        +--rw a:class-b
        |  +--rw a:leaf-b-1?   string
        |  +--rw a:leaf-b-2?   string
        +--rw a:container-c!
        |  +--rw a:leaf-c-1?   string
        |  +--rw a:leaf-c-2?   string
        +--rw a:list-d* [key-d]
           +--rw a:key-d       string
           +--rw a:leaf-d-1?   string
           +--rw a:leaf-d-2?   string

The schema:

module augment-model-example {
yang-version 1.1;
namespace "urn:test:augment-model-example";
prefix a;

import base-model-example {
prefix "b";
}

grouping class-a {
leaf leaf-a-1 {
type string;
}
leaf leaf-a-2 {
type string;
}
}

grouping class-b {
leaf leaf-b-1 {
type string;
}
leaf leaf-b-2 {
type string;
}
}

grouping class-c {
container container-c {
presence
"Presence condition";
uses class-c-pac;
}
}

grouping class-c-pac {
leaf leaf-c-1 {
type string;
}
leaf leaf-c-2 {
type string;
}
}

grouping class-d {
leaf key-d {
type string;
}
leaf leaf-d-1 {
type string;
}
leaf leaf-d-2 {
type string;
}
}

augment "/b:root/b:element" {
uses class-a;
}

augment "/b:root/b:element" {
container class-b {
uses class-b;
}
}

augment "/b:root/b:element" {
uses class-c;
}

augment "/b:root/b:element" {
list list-d {
key key-d;
uses class-d;
}
}
}

2022-03-25:

Italo Busi 22 Apr 2022 Italo to provide an update to the diagram and propose text for the mapping guidelines.

7

0 min

Papyrus Releases

- Consider a plan for convergence of ITU-T Q14/15, ONF Common IM and TAPI to 2020-06 (4.16) version
- Prior discussion: IISOMI 2021-09-24 Meeting Minutes
  - Reaffirmed the need to explore 2020-06 (4.16) version

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:

Scott Mansfield clarifies that the Gendoc application depends on Papyrus version, and not on Eclipse version.
Hing-Kam Lam in ITU-T SG15 we plan to migrate to 2020-06 (4.16) version by the end of February.
Scott Mansfield and Andrea Mazzini agree to create a wiki page dedicated to the examples of Gendoc templates.
Scott Mansfield model2doc should dump every UML construct, to be checked.

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

8

0 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 08 Oct 2021 Draft an example Wiki page that capture an discussion item

Proposal wiki page from Bernd for capturing discussion items:

IISOMI Discussions

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

9

0 min

Guideline/Tooling wiki page(s) for listing the tasks

Andrea Mazzini

Andrea Mazzini shows Guidelines and Tooling Discussion Items

Martin Skorupski adds two columns, Reporter and Rough Effort Estimation.
Scott Mansfield until there is no investment, there will be no progress.

2022-01-28

No update.

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

10

0 min

Feature/condition

Andrea Mazzini

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

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

11

0 min

Convention of UML property names in document/comment/description

Hing-Kam Lam

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

Bernd will upload the draft (IISOMI Deliverables)
- Bernd Zeuner 14 Jan 2022 Upload latest mapping guidelines to IISOMI Deliverables
  → Done: IISOMI 531 UML to YANG Mapping Guidelines (new editor Karthik)

2022-01-28

No update.

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

12

0 min

Papyrus-Model2Doc feature

Scott Mansfield

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:

(model2doc 2019 version 0.7.0): https://download.eclipse.org/modeling/mdt/papyrus/components/model2doc/releases/0.7.0/
(model2doc 2021 version 0.8.0): https://download.eclipse.org/modeling/mdt/papyrus/components/model2doc/2021-12/
(model2doc 2022 bleeding edge): https://download.eclipse.org/modeling/mdt/papyrus/components/model2doc/releases/0.8.0/p2/
(model2doc 2022 last successful build): https://ci.eclipse.org/papyrus/job/Papyrus-Model2Doc/lastSuccessfulBuild/artifact/repository/

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

13

0 min

Private GitHub

Scott Mansfield

Prior discussion: IISOMI 2021-09-24 Meeting Minutes #9 and 2021-10-01 IISOMI Meeting Minutes #8

2022-01-28

No update.

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

14

0 min

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

Scott Mansfield

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

2022-01-28

No update.

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

15

0 min

GenDoc Issues

All
Hing-Kam Lam

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

16

0 min

Modular and decoupled modeling process

Hing-Kam Lam Nigel Davis

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:

https://wiki.opennetworking.org/download/attachments/266141701/ONF_T64_DddAggregates.pptx?api=v2

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

No update.

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

17

Agenda of next call

All

Administrative
- Call plan (schedule, leader)
- Review IISOMI Action Items
Coding of Target Path
UML modeling guidelines questions from ITU-T Q14/15
- Cardinality for conditionally mandatory associations: should it be 1 or 0..1?
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
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

Space shortcuts

Child pages

Date

Attendees

Apology

Agenda

Discussion items

Action items

Space shortcuts

Child pages

Pages … OIMT IISOMI IISOMI Minutes 2022 IISOMI Minutes 2022-05-13 IISOMI Meeting Minutes

Date

Attendees

Apology

Agenda

Discussion items

Action items

Pages
…

OIMT
IISOMI
IISOMI Minutes
2022 IISOMI Minutes

2022-05-13 IISOMI Meeting Minutes