Isn’t this 2015? *)
—Tom
> On Jul 30, 2015:11:54 AM, at 11:54 AM, Juergen Schoenwaelder
> <[email protected]> wrote:
>
> 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
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
