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 protected]<mailto:[email protected]> 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 protected]] On Behalf Of Ari Sodhi Sent: Wednesday, July 29, 2015 6:44 PM To: [email protected] Subject: [netmod] Mail regarding draft-mansfield-netmod-uml-to-yang 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. [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). 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 [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. [cid:[email protected]] 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 protected]<mailto:[email protected]> Calix 1035 N. McDowell Boulevard Petaluma, CA 94954 T 707.766.3000 F 707.283.3100
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
