Subject: [netmod] FW: Review of draft-linowski-netmod-yang-abstract-03.txt

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 16 Sep 2010 04:41:48 +0200

Hi Martin,

Thank you for your thorough review.

Some of your comments are more or less easy to change
and others need some clarification. See below.

Mehmet

[. . .]

> ------------------------------------------------------------
> 
> s 1.5.1.  yang module udmcore
> 
> Is this module supposed to be an example?  If so, the namespace should
> probably be something like http://example.com/udmcore.
> 
> Same comment applies to modules "hardware-entities" and "hw".

The modules in the document are all non-standard examples.
 
[. . .]
 
> ------------------------------------------------------------
> 
> s 2.4.
> 
>    Common YANG statements may
>    be used as substatements of the "element" statement.
> 
> What is the "element" statement?
> 
> The term "element" is used in other places as well, e.g.:
> 
>    In case the instance list represents configuration data, the used
>    complex type of an element MUST have an element key.
> 
> I suggest you go through the document and change this to the
> appropriate term.

To be correct this should be "instance statement" ("element" 
was the old name of the statement).
 
[. . .]

> ------------------------------------------------------------
> 
> s 2.8.
> 
> It seems the type encoding rules impose a strict order among the
> XML elements.  Note that YANG does not impose such a strict order, so
> I suggest you clearly state that these rules change the rules defined
> by YANG.
> 
> Also, what happens if class B derives from class A, and class B
> defines the keys?  In YANG, the keys are always encoded first, but
> this text says that class A's leafs are encoded before class B's
> leafs.  This must be clarified.
> 
> Will the meta-data "cti:type" element be encoded before the keys?
> This must be clarified.

This needs indeed some clarification. We actually do not change 
any (original) YANG rules. As this is a new feature it might become 
interesting to do the type encoding in a specific order.

We will reconsider the encoding of complex types. 

[. . .]
 
> ------------------------------------------------------------
> 
> s 2.9.
> 
> Why do you define the "complex-type" feature?  Why is this feature
> important to a client?  How will the client adapt depending on if this
> feature is present or not?
> 
> IMO, it is not needed at all.  If the server advertises support for a
> module that uses complex-types, it obvioulsy implements complex-types.

This might look a bit redundant. However, having the feature allows 
to use the if-feature mechanism with a commonly defined tag.
 
[. . .]

> ------------------------------------------------------------
> 
> s 2.13.2
> 
> Is it correct that if one uses recursive complex types, then the
> resulting hiearchy cannot be augmented?  Isn't this a pretty severe
> restriction?  If nothing else, I think this restriction should be
> noted when recursive complex types are defined.

Our aim is to avoid any side-effect and to reduce modeling complexity,
which I think is valuable.
 
[. . .]

> ------------------------------------------------------------
> 
> s 3.1
> 
>    Typed instance identifier relationships are an addition to the
>    relationship types already defined in YANG, where the leafref
>    relationship is location dependent, and the instance-identifier is
>    not type-safe.
> 
> Please explain what you mean with "type-safe".
> 
> It is true that there is no formal way of specificying what an i-i can
> point to in YANG, but it can be defined in the description statement.

A type error can be caused by a discrepancy between differing data
types.
In general Type-safety is a tool to prevent type errors in an automatic 
manner. 
We think that the description statement shouldn't be used as part of the

language and want to avoid writing any rules into the description
statement.

[. . .]

> ------------------------------------------------------------
> 
> Appendix C.1
> 
> Second bullet says:
> 
>    o  All associations between the concepts (which are not
containment)
>       are represented with typed identifiers.  That avoids having to
>       refer to a particular location in the tree, which is not
mandated
>       by the original model.
> 
> To be fair; the original model doesn't say that the reference is
> supposed to be to any place in the tree either.
> 
> In general, I have a hard time appreciating this (location independent
> reference) as a feature.  I think it introduces more problems than it
> solves, and there are other ways to solve the underlying problem.

We don't think location independent references introduce new problems.
It is indeed something new, hence a bit different than other references.
There are always other possible solutions to the underlying problem. 
 
> ------------------------------------------------------------
> 
> If complex-types are used, some of the flexibility of YANG is lost.
> For example, in your equipment example, suppose vendor X wants to add
> its own proprietary attributes to all "ManagedHardware".  This will
> not be possible unless all classes derived from ManagedHardware at
> some point are tracked down, and all ct:instance statements for these
> classes are augmented with the new attributes.

Actually it depends on the pov. and the way you are modeling. In 
our opinion complex-types introduce a powerful language feature for 
top-down modeling and enables additional flexibility for the aimed 
purpose, e.g. with inheritance. The new feature makes YANG models 
easier mapable to other models like SID. 

You can always extend a base class to affect inheriting classes or 
inherit from a class and add new attributes on the new class level.

> 
> ------------------------------------------------------------
> 
> I have checked the main module, "complex-types", and the example
> modules using pyang.
> 
> The module ipfix-psamp has a couple of errors:
> 
>   -  The type autonomous-system-number is not found (it is called
>      as-number).
> 
>   -  It uses the statement "type" instead of ct:instance-type.
> 
>   -  There is a syntax error:
>       type instance-identifier {ct :instance-type PhysicalEntity; }
>                                 ^^^^^^

This is a leftover. We will update the module.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 16 Sep 2010 11:44:04 +0200

This goes to Revised I-D needed as I understand, following the expert
review. 

Regards,

Dan

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Ersue, Mehmet 
> (NSN - DE/Munich)
> Sent: Thursday, September 16, 2010 4:42 AM
> To: ext Martin Bjorklund; [email-masked]
> Subject: [netmod] FW: Review of 
> draft-linowski-netmod-yang-abstract-03.txt
> 
> Hi Martin,
> 
> Some of your comments are more or less easy to change and 
> others need some clarification. See below.
> 
> Mehmet
> 
> [. . .]
> 
> > It seems the type encoding rules impose a strict order 
> among the XML 
> > elements.  Note that YANG does not impose such a strict order, so I 
> > suggest you clearly state that these rules change the rules 
> defined by 
> > YANG.
> > 
> This needs indeed some clarification. We actually do not 
> change any (original) YANG rules. As this is a new feature it 
> might become interesting to do the type encoding in a specific order.
> 
> This might look a bit redundant. However, having the feature 
> allows to use the if-feature mechanism with a commonly defined tag.
>  
> [. . .]
> 
> Our aim is to avoid any side-effect and to reduce modeling 
> complexity, which I think is valuable.
>  
> [. . .]
> 
> A type error can be caused by a discrepancy between differing 
> data types.
> In general Type-safety is a tool to prevent type errors in an 
> automatic manner. 
> language and want to avoid writing any rules into the 
> description statement.
> 
> [. . .]
> 
> Actually it depends on the pov. and the way you are modeling. 
> In our opinion complex-types introduce a powerful language 
> feature for top-down modeling and enables additional 
> flexibility for the aimed purpose, e.g. with inheritance. The 
> new feature makes YANG models easier mapable to other models 
> like SID. 
> 
> You can always extend a base class to affect inheriting 
> classes or inherit from a class and add new attributes on the 
> new class level.
> 
> > 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 16 Sep 2010 13:05:47 +0200 (CEST)

Hi Mehmet,

> to use the if-feature mechanism with a commonly defined tag.

Can you give an example of a use case where this would be useful?

> which I think is valuable.

Sure, but in this case you give up flexibility.  Maybe it is worth the
trade off.  I just think this should be noted when recursive
complex types are defined.

> In general Type-safety is a tool to prevent type errors in an automatic 

I understand this, but I think it should be reflected in the text.
Currently it just says "[...] the instance-identifier is not
type-safe."  It is not clear from the text what this means.

> You can always extend a base class to affect inheriting classes

Can you show how this would be done in the example I gave above?

> or 

But this doesn't solve the problem in the example above.  Vendor X
cannot change all classes in the inheritance chain, if these classes
are defined in published standard modules.

/martin