Subject: [netmod] Mail regarding draft-mansfield-netmod-uml-to-yang

From: Ari Sodhi <[email-masked]>
Date: Wed, 29 Jul 2015 16:43:36 +0000

There are some interesting ideas proposed. Here are some initial questions and somewhat random comments based on a quick read of draft-mansfield-netmod-uml-to-yang-00.

General questions on draft-mansfield-netmod-uml-to-yang:

  1.  Is the proposed mapping supposed to be bi-directional in nature? In other words, is the intent to support a mapping between UML and YANG that enables IM UML -> DM YANG -> IM UML in a round trip manner.  The text in this section uses the term predictable. Should it not be deterministic?
  2.  Does there need to be a set of UML usages defined – similar to what ONF did? Some of the UML concepts such as aggregation usually need definition as even the OMG UML 2.5 spec says aggregation is open to some interpretation. This is touched on in section 5.5 of draft-mansfield-netmod-uml-to-yang but it seems ambiguous as both composition and aggregation map to container. The examples are not so clear – the first seems more like composition to me as there is a lifecycle implication between instances of ClassA and ClassB. The second example – the list could also be a set of leafref to the ClassD key.
  3.  Did the authors consider the use of UML stereotypes/annotations to help support the mapping between UML and YANG? This may help remove potential ambiguity in the mapping.

comments on draft-mansfield-netmod-uml-to-yang:

  1.  Section 3 - What about UML packages and module/submodule relationship. Modules can be a root package with submodules being sub-packages.Need to enforce the semantics of include/import per RFC 6020. Any value in considering relating YANG features to packages – ie. Represent yang Feature statements
  2.  Section 5.2 - UML abstract is stated to map to a container. Containers either represent containment for organization reasons or with presence the container itself is configuration data. I do not get the mapping of abstract to this. Can you explain?
  3.  Section 5.2 – both support and condition map to “if-feature” statement in yang. This seems ambiguous. How does one distinguish in YANG which is which?
  4.  Section 5.2 - “must” statement – could this not map to OCL?
  5.  Section 5.2 – wrt objectCreationNotfication/objectDeletionNotification – in UML how are these represented -seems to rely on ONF OpenModelCass if I understand the source correctly? It seems like there are some assumptions wrt to the Object Class. In YANG can these map to notification statements. Is there some notification hierarchy in YANG/UML where these notifications (objectCreationNotificaiton/objectDeletionNotification) exist? More current drafts of RFC 6020 (I.e. draft-ietf-netmod–rfc6020bis–06) propose notifications to be top level of a module or associated with data nodes (container or list data nodes).   This notion could be leveraged as the source of the notification in YANG – xpath to its source in containment model.
  6.  Section 5.4.4 – a complex data type does not always map to grouping IMO except if the grouping has a singular top level container. A grouping is a reusable construct that gets "flattened out" in the context they are used within. Groupings can also be refined/augmented to tailor their usage contextually.
  7.   Section 5.5 –The mapping is ambiguous as stated above.  composition is a stronger type of association then aggregation and infers ownership of lifecycle of the contained items. That is when the composing instance is destroyed, the contained items are also destroyed. Its a is a part of relationship. Aggregation can be used to mean a point of control for manipulating the contained.  It does not infer lifecycle control.
  8.  Section 5.5 - Its not clear how cleanly augment maps to inheritance. Augment can apply to many things in YANG - container, list, leaf-list, uses, choice …. I can kind of see augment of a container mapping to inheritance. Augments can also specify conditions as to when they apply - i.e. If if type == ethernetCsmacd
  9.  Section 5.6 – I don’t see how UML interface maps to a container. A UML interface represents a contract. A container either represents containment for organization reasons or with presence the container itself is configuration data. This may need more discussion – or at least more explanation.
  10. Section 5.11 – what does package map to? Is it module/submodule? Could a conditional package not also map to module/submodule with if-feature as a top-level entity?

Ari Mark Sodhi
System Engineer and Architect II
T 707.766.3413
M 707.775.1379
E [email-masked]

Calix
1035 N. McDowell Boulevard
Petaluma, CA 94954
T 707.766.3000
F 707.283.3100

---

From: <[email-masked]>
Date: Thu, 30 Jul 2015 16:44:26 +0200

Hallo,

Thanks for sharing your questions and comments; some initial responses are provided below in line.
Note that we have made some further progress that we plan to reflect in an update of this draft which of course will take into account the netmod discussions and input including  this e-mail thread.

Regards
Bernd
Deutsche Telekom AG
Europe & Technology
Standardization Services
Bernd Zeuner
Heinrich-Hertz-Str. 3-7, 64295 Darmstadt, Germany
+49 6151 58-12086 (phone)
E-Mail: [email-masked]<mailto:[email-masked]>
www.telekom.com<http://www.telekom.com>
Life is for sharing.
Deutsche Telekom AG
Supervisory Board: Prof. Dr. Ulrich Lehner (Chairman)
Board of Management: Timotheus Höttges (Chairman),
Reinhard Clemens, Niek Jan van Damme,
Thomas Dannenfeldt, Dr. Thomas Kremer, Claudia Nemat
Commercial register: Amtsgericht Bonn HRB 6794
Registered office: Bonn, Germany
VAT identification no. DE 123475223
Big changes start small - conserve resources by not printing every e-mail.
From: netmod [mailto:[email-masked]] On Behalf Of Ari Sodhi
Sent: Wednesday, July 29, 2015 6:44 PM
To: [email-masked]
Subject: [netmod] Mail regarding draft-mansfield-netmod-uml-to-yang

 1.  Is the proposed mapping supposed to be bi-directional in nature? In other words, is the intent to support a mapping between UML and YANG that enables IM UML -> DM YANG -> IM UML in a round trip manner.  [Bernd] The intent was UML -> YANG; but YANG -> UML is also possible. The text in this section uses the term predictable. Should it not be deterministic?[Bernd] Yes, agreed.
 2.  Does there need to be a set of UML usages defined - similar to what ONF did? Some of the UML concepts such as aggregation usually need definition as even the OMG UML 2.5 spec says aggregation is open to some interpretation. This is touched on in section 5.5 of draft-mansfield-netmod-uml-to-yang but it seems ambiguous as both composition and aggregation map to container. The examples are not so clear - the first seems more like composition to me as there is a lifecycle implication between instances of ClassA and ClassB. The second example - the list could also be a set of leafref to the ClassD key.
[Bernd] You are right. Some statements (to be verified):

·         UML composition association is mapped to container/list within a container/list; the reference is "passed by value"

·         UML aggregation association is mapped to a leafref within a container/list; the reference is "passed by reference".

 1.  Did the authors consider the use of UML stereotypes/annotations to help support the mapping between UML and YANG? This may help remove potential ambiguity in the mapping. [Bernd] We did not add YANG specific UML stereotypes because the intent was that the UML be agnostic to any data schema (DM).

 1.  Section 3 - What about UML packages and module/submodule relationship. Modules can be a root package with submodules being sub-packages.Need to enforce the semantics of include/import per RFC 6020. Any value in considering relating YANG features to packages - ie. Represent yang Feature statements
[Bernd] The mapping of UML packages to YANG modules/submodules is an identified open issue which is under discussion. You raise some good points to consider.

 1.  Section 5.2 - UML abstract is stated to map to a container. Containers either represent containment for organization reasons or with presence the container itself is configuration data. I do not get the mapping of abstract to this. Can you explain?
[Bernd] The current thinking is to map abstract superclasses to "grouping" statements. This allows also to map multiple inheritance. Note: This is also the mapping that we have used for the Link object class in draft-lam-teas-usage-info-model-net-topology-01.

 1.  Section 5.2 - both support and condition map to "if-feature" statement in yang. This seems ambiguous. How does one distinguish in YANG which is which?
[Bernd] Support and condition belong together. If the "support" is conditional, then the "condition" explains the conditions under which the class has to be supported.

 1.  Section 5.2 - "must" statement - could this not map to OCL?
[Bernd] Good idea; we are still discussing this point as a general place for mapping UML constraints. YANG seems to have here constraints between attribute values in mind.

 1.  Section 5.2 - wrt objectCreationNotfication/objectDeletionNotification - in UML how are these represented -seems to rely on ONF OpenModelCass if I understand the source correctly? [Bernd] Yes, you are right. This is an additional class property defined in the OpenModel profile. It defines that a notification has to be sent when an instance of this class is instantiated or deleted. It seems like there are some assumptions wrt to the Object Class. In YANG can these map to notification statements. [Bernd] Meanwhile we have mapped this to the "notification" statement which goes beyond the simple "a notification has to be sent". Is there some notification hierarchy in YANG/UML where these notifications (objectCreationNotificaiton/objectDeletionNotification) exist? [Bernd] Not now; but will be in the future. More current drafts of RFC 6020 (I.e. draft-ietf-netmod-rfc6020bis-06) propose notifications to be top level of a module or associated with data nodes (container or list data nodes).   This notion could be leveraged as the source of the notification in YANG - xpath to its source in containment model.
 2.  Section 5.4.4 - a complex data type does not always map to grouping IMO except if the grouping has a singular top level container. A grouping is a reusable construct that gets "flattened out" in the context they are used within. Groupings can also be refined/augmented to tailor their usage contextually.
[Bernd] We define complex data types in a separate UML package (TypeDefinitions). They can always be reused as the type of class attributes or operation parameters.

 1.   Section 5.5 -The mapping is ambiguous as stated above.  composition is a stronger type of association then aggregation and infers ownership of lifecycle of the contained items. That is when the composing instance is destroyed, the contained items are also destroyed. Its a is a part of relationship. Aggregation can be used to mean a point of control for manipulating the contained.  It does not infer lifecycle control.
[Bernd] That's completely true. See our answer to General::2.

 1.  Section 5.5 - Its not clear how cleanly augment maps to inheritance. Augment can apply to many things in YANG - container, list, leaf-list, uses, choice .... I can kind of see augment of a container mapping to inheritance. Augments can also specify conditions as to when they apply - i.e. If if type == ethernetCsmacd
[Bernd] True. In recent discussions we concluded that augment is more appropriate for mapping to conditional composition then inheritance. We see the "grouping" statement as the main mapping for inheritance. The "extension" statement is no longer used here.

 1.  Section 5.6 - I don't see how UML interface maps to a container. A UML interface represents a contract. A container either represents containment for organization reasons or with presence the container itself is configuration data. This may need more discussion - or at least more explanation.
[Bernd] We use the UML Interface artifact as a grouping of operations. A container can be used to group actions.

 1.  Section 5.11 - what does package map to? Is it module/submodule? [Bernd] Regarding the mapping of packages see our answer to Comments::1 above. Could a conditional package not also map to module/submodule with if-feature as a top-level entity?[Bernd] That's possible but we see the conditional Pacs closer to the object class. They provide the attributes for an object class on a conditional basis. This pattern is used e.g., to enhance a technology agnostic object class with technology specific attributes.

Ari Mark Sodhi
System Engineer and Architect II
T 707.766.3413
M 707.775.1379
E [email-masked]<mailto:[email-masked]>

Calix

---

From: "Lam, Hing-Kam (Kam)" <[email-masked]>
Date: Thu, 30 Jul 2015 15:26:53 +0000

Hi,

Additional responses inline below.

Regards,
Kam

From: netmod [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, July 30, 2015 10:44 AM
To: [email-masked]
Subject: Re: [netmod] Mail regarding draft-mansfield-netmod-uml-to-yang

Hallo,

Regards
Bernd
Deutsche Telekom AG
Europe & Technology
Standardization Services
Bernd Zeuner
To: [email-masked]<mailto:[email-masked]>

  1.  Is the proposed mapping supposed to be bi-directional in nature? In other words, is the intent to support a mapping between UML and YANG that enables IM UML -> DM YANG -> IM UML in a round trip manner.  [Bernd] The intent was UML -> YANG; but YANG -> UML is also possible. <Kam> The rationale of UML --> YANG being the intent is that we start with protocol-neutral modeling using UML first. The I-D draft-betts-netmod-framework-data-schema-uml contains more details of this approach. Now given so many YANG drafts have been created, in some cases it might be helpful to revert (YANG --> UML) engineer the YANG drafts to UML so that comparison/analysis can be made.  </Kam> The text in this section uses the term predictable. Should it not be deterministic?[Bernd] Yes, agreed.
  2.  Does there need to be a set of UML usages defined - similar to what ONF did? <Kam> The referenced ONF TR-514 UML guidelines, which is publicly available, described the usages. </Kam> Some of the UML concepts such as aggregation usually need definition as even the OMG UML 2.5 spec says aggregation is open to some interpretation. This is touched on in section 5.5 of draft-mansfield-netmod-uml-to-yang but it seems ambiguous as both composition and aggregation map to container. The examples are not so clear - the first seems more like composition to me as there is a lifecycle implication between instances of ClassA and ClassB. The second example - the list could also be a set of leafref to the ClassD key.
[Bernd] You are right. Some statements (to be verified):

  1.  Did the authors consider the use of UML stereotypes/annotations to help support the mapping between UML and YANG? This may help remove potential ambiguity in the mapping. [Bernd] We did not add YANG specific UML stereotypes because the intent was that the UML be agnostic to any data schema (DM). <Kam> Hi Ari, I am not sure I understand your question correctly? Do you mean applying the lifecycle stereotypes  to qualify the status of the mapping rules? I.e., some of the mapping rules may be preliminary at the moment, etc.?. </Kam>

Ari Mark Sodhi

Calix

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 30 Jul 2015 17:54:36 +0200

Hi all,

is it possible to use/configure an email quoting style that works with
text-only email readers? I know, it is old fashioned, but I do read
all my email in a terminal window...

Thanks,

/js

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Nadeau Thomas <[email-masked]>
Date: Thu, 30 Jul 2015 13:06:06 -0400

Isn’t this 2015? *)

	—Tom

> On Jul 30, 2015:11:54 AM, at 11:54 AM, Juergen Schoenwaelder <[email-masked]> wrote:
> 
> Hi all,
>

---

From: "Lam, Hing-Kam (Kam)" <[email-masked]>
Date: Thu, 30 Jul 2015 17:21:25 +0000

Okay. Reformatted into plain text only, including the original emails from Ari and Bernd. See below. Better? :-)

Regards,
Kam

From: Lam, Hing-Kam (Kam) 
Sent: Thursday, July 30, 2015 11:27 AM
To: [email-masked]; [email-masked]
Subject: RE: Mail regarding draft-mansfield-netmod-uml-to-yang

Hi,

Regards,
Kam

Hallo,

Regards
Bernd
Deutsche Telekom AG
Europe & Technology
Standardization Services
Bernd Zeuner
E-Mail: [email-masked]
www.telekom.com
Big changes start small – conserve resources by not printing every e-mail.

1. Is the proposed mapping supposed to be bi-directional in nature? In other words, is the intent to support a mapping between UML and YANG that enables IM UML -> DM YANG -> IM UML in a round trip manner. 
 
[Bernd] The intent was UML -> YANG; but YANG -> UML is also possible. 

<Kam> The rationale of UML → YANG being the intent is that we start with protocol-neutral modeling using UML first. The I-D draft-betts-netmod-framework-data-schema-uml contains more details of this approach. Now given so many YANG drafts have been created, in some cases it might be helpful to revert (YANG → UML) engineer the YANG drafts to UML so that comparison/analysis can be made.  </Kam> 

The text in this section uses the term predictable. Should it not be deterministic?

[Bernd] Yes, agreed.

2. Does there need to be a set of UML usages defined – similar to what ONF did? 

<Kam> The referenced ONF TR-514 UML guidelines, which is publicly available, described the usages. </Kam> 

Some of the UML concepts such as aggregation usually need definition as even the OMG UML 2.5 spec says aggregation is open to some interpretation. This is touched on in section 5.5 of draft-mansfield-netmod-uml-to-yang but it seems ambiguous as both composition and aggregation map to container. The examples are not so clear – the first seems more like composition to me as there is a lifecycle implication between instances of ClassA and ClassB. The second example – the list could also be a set of leafref to the ClassD key.

[Bernd] You are right. Some statements (to be verified):
• UML composition association is mapped to container/list within a container/list; the reference is “passed by value”
• UML aggregation association is mapped to a leafref within a container/list; the reference is “passed by reference”.

[Bernd] We did not add YANG specific UML stereotypes because the intent was that the UML be agnostic to any data schema (DM). 

<Kam> Hi Ari, I am not sure I understand your question correctly? Do you mean applying the lifecycle stereotypes  to qualify the status of the mapping rules? I.e., some of the mapping rules may be preliminary at the moment, etc.?. </Kam>

[Bernd] The current thinking is to map abstract superclasses to “grouping” statements. This allows also to map multiple inheritance. Note: This is also the mapping that we have used for the Link object class in draft-lam-teas-usage-info-model-net-topology-01.

[Bernd] Support and condition belong together. If the “support” is conditional, then the “condition” explains the conditions under which the class has to be supported. 

5. Section 5.2 – wrt objectCreationNotfication/objectDeletionNotification – in UML how are these represented -seems to rely on ONF OpenModelCass if I understand the source correctly? 

[Bernd] Yes, you are right. This is an additional class property defined in the OpenModel profile. It defines that a notification has to be sent when an instance of this class is instantiated or deleted. 

It seems like there are some assumptions wrt to the Object Class. In YANG can these map to notification statements. 

[Bernd] Meanwhile we have mapped this to the “notification” statement which goes beyond the simple “a notification has to be sent”. 

Is there some notification hierarchy in YANG/UML where these notifications (objectCreationNotificaiton/objectDeletionNotification) exist? 

[Bernd] Not now; but will be in the future. 

More current drafts of RFC 6020 (I.e. draft-ietf-netmod–rfc6020bis–06) propose notifications to be top level of a module or associated with data nodes (container or list data nodes).   This notion could be leveraged as the source of the notification in YANG – xpath to its source in containment model. 

[Bernd] That’s completely true. See our answer to General::2.

[Bernd] True. In recent discussions we concluded that augment is more appropriate for mapping to conditional composition then inheritance. We see the „grouping” statement as the main mapping for inheritance. The “extension” statement is no longer used here.

[Bernd] We use the UML Interface artifact as a grouping of operations. A container can be used to group actions.
+----------------------------------------+
|             <<Interface>>              |
|         <<openModelInterface>>         |
|            <Interface Name>            |
+----------------------------------------+
|                                        |
+----------------------------------------+
| * <<openModelOperation> + operation1() |
| * <<openModelOperation> + operation2() |
+----------------------------------------+

10. Section 5.11 – what does package map to? Is it module/submodule? 

[Bernd] Regarding the mapping of packages see our answer to Comments::1 above. 

Could a conditional package not also map to module/submodule with if-feature as a top-level entity?

[Bernd] That’s possible but we see the conditional Pacs closer to the object class. They provide the attributes for an object class on a conditional basis. This pattern is used e.g., to enhance a technology agnostic object class with technology specific attributes.

Ari Mark Sodhi
 
Calix