1. Pages
2. …
3. OIMT
4. IISOMI
5. IISOMI Minutes

2022-03-04 IISOMI Meeting Minutes

Admin: IISOMI Action Items status

• Scott Mansfield  11 Mar 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

• Scott Mansfield 11 Mar 2022 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

•  Scott Mansfield 11 Mar 2022 To investigate why none of the <<cond>> is retrieved from the model (confirm with Andrea Mazzini 

• • 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 11 Mar 2022 To investigate how to get client and server values for an abstraction association for gendoc.

• • From 2021-12-03 IISOMI Meeting Minutes

Add values to an existing core-model enumeration

UML modeling guidelines questions from ITU-T Q14/15

• 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;
    }
  }
}

UML Modeling Guidelines

Proposals for capturing discussion items 

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

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

Convention of UML property names in document/comment/description

2022-01-28

No update.

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

Private GitHub

2022-01-28

No update.

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

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

GenDoc Issues

• Administrative
  • Call plan (schedule, leader)
  • Review IISOMI Action Items
• 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