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 On Thu, Jul 30, 2015 at 03:26:53PM +0000, Lam, Hing-Kam (Kam) wrote: > Hi, > > Additional responses inline below. > > Regards, > Kam > > From: netmod [mailto:[email protected]] On Behalf Of [email protected] > Sent: Thursday, July 30, 2015 10:44 AM > To: [email protected] > Subject: Re: [netmod] Mail regarding draft-mansfield-netmod-uml-to-yang > > 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]<mailto:[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. <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". > > 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> > > 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 -- 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/> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
