Subject: [netmod] Comments on draft-mansfield-uml-to-yang-00

From: Italo Busi <[email-masked]>
Date: Fri, 10 Jul 2015 14:54:34 +0000

Dear authors of draft-mansfield-uml-to-yang,

I think this draft is very useful in assisting translation between UML IMs and Yang DMs. Since many UML IMs have been already defined, this I-D would help in simplifying development and/or gap analysis of new Yang DMs.

It also complements the work on the suite of translation drafts developed or under development in the NETMOD WG (e.g., RFC 6643 and draft-ietf-netmod-yang-json).

I have started to read the draft and have got an initial set of comments I would like to share (further comments may follow while I continue reviewing the draft).

Appendix A is very helpful to see how the different mapping rules work. It would be worth enhancing it with some further detailed descriptions also referencing the YANG Module and not only the YANG tree of draft-dharini-netmod-g-698-2-yang-04.

It seems that section 5 of this I-D is describing the mapping between the UML artifacts defined in section 5 of TR-514. It would be worth adding some text to clarify this point.

It seems that section 5.1 of this I-D is describing how the Object Class UML artifact described in section 5.1 of TR-514 is mapped into YANG statements.

In particular, an Object Class UML artifact can be mapped either to a "list" or to a "container" YANG statement. The I-D does not describe when (i.e., under which condition) a "list" or a "container" statement should be used. Are both approaches equivalent or is there a criteria for using one or other approach depending on some characteristics of the Object Class?

Looking YANG module in the appendix A example (draft-dharini-netmod-g-698-2-yang-04), it seems that the superclass property of an Object Class artifact is not explicitly defined but it is inferred from the structure of the "augment" and "container" statements:

         augment "/if:interfaces/if:interface" {
           description "Parameters for an optical interface";
           container optIfOChRsSs {
              description "RsSs path configuration for an interface";
         <...>
         }

Looking at this example, it is also worth noting that the documentation property of the optIfOChRsSs Object Class maps to the "description" substatement below the "container optIfOChRsSs" statement (i.e., description "RsSs path configuration for an interface";). The other description statement (i.e., description "Parameters for an optical interface";) is mapping the documentation property of the inheritance relationship.

It would be worth updating Section 5.4 to describe how the properties of the Association UML artifacts maps into substatements of the YANG statements as well as updating appendix A to describe the example above.

Is it possible to map into YANG an UML Object Class that inherits from more than one superclass?

Just a nit: I think that reference [7] is not an OMG document

Thanks, Italo

---

From: "Varma, Eve L (Eve)" <[email-masked]>
Date: Mon, 13 Jul 2015 18:24:51 +0000

Hi Italo,

Thank you for your very helpful comments!

Just a quick note - the subsection numbers you commented on seems off by one. For example, object class mapping is in Section 5.2, not 5.1; association mapping is in section 5.5, not 5.4.

Best regards,
Eve

-----Original Message-----
From: netmod [mailto:[email-masked]] On Behalf Of Italo Busi
Sent: Friday, July 10, 2015 10:55 AM
To: [email-masked]
Subject: [netmod] Comments on draft-mansfield-uml-to-yang-00

Thanks, Italo

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

---

From: Italo Busi <[email-masked]>
Date: Tue, 14 Jul 2015 13:21:36 +0000

Ops, you are right

Thanks for catching it

Italo

> From: Varma, Eve L (Eve) [mailto:[email-masked]]
> Sent: lunedì 13 luglio 2015 20:25
> To: Italo Busi; [email-masked]
> Subject: RE: Comments on draft-mansfield-uml-to-yang-00
> 
> Hi Italo,
> 
> Just a quick note - the subsection numbers you commented on seems off by one.
> For example, object class mapping is in Section 5.2, not 5.1; association
> mapping is in section 5.5, not 5.4.
> 
> Best regards,
> Eve
> 
> I think this draft is very useful in assisting translation between UML IMs
> and Yang DMs. Since many UML IMs have been already defined, this I-D would
> help in simplifying development and/or gap analysis of new Yang DMs.
> 
> It also complements the work on the suite of translation drafts developed or
> under development in the NETMOD WG (e.g., RFC 6643 and draft-ietf-netmod-
> yang-json).
> 
> I have started to read the draft and have got an initial set of comments I
> would like to share (further comments may follow while I continue reviewing
> the draft).
> 
> Appendix A is very helpful to see how the different mapping rules work. It
> would be worth enhancing it with some further detailed descriptions also
> referencing the YANG Module and not only the YANG tree of draft-dharini-
> netmod-g-698-2-yang-04.
> 
> It seems that section 5 of this I-D is describing the mapping between the
> UML artifacts defined in section 5 of TR-514. It would be worth adding some
> text to clarify this point.
> 
> It seems that section 5.1 of this I-D is describing how the Object Class UML
> artifact described in section 5.1 of TR-514 is mapped into YANG statements.
> 
> In particular, an Object Class UML artifact can be mapped either to a "list"
> or to a "container" YANG statement. The I-D does not describe when (i.e.,
> under which condition) a "list" or a "container" statement should be used.
> Are both approaches equivalent or is there a criteria for using one or other
> approach depending on some characteristics of the Object Class?
> 
> Looking YANG module in the appendix A example (draft-dharini-netmod-g-698-2-
> yang-04), it seems that the superclass property of an Object Class artifact
> is not explicitly defined but it is inferred from the structure of the
> "augment" and "container" statements:
> 
> Looking at this example, it is also worth noting that the documentation
> property of the optIfOChRsSs Object Class maps to the "description"
> substatement below the "container optIfOChRsSs" statement (i.e., description
> "RsSs path configuration for an interface";). The other description
> statement (i.e., description "Parameters for an optical interface";) is
> mapping the documentation property of the inheritance relationship.
> 
> It would be worth updating Section 5.4 to describe how the properties of the
> Association UML artifacts maps into substatements of the YANG statements as
> well as updating appendix A to describe the example above.
>