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

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 19 Oct 2010 16:58:19 +0200

Hi Martin,

sorry for late response. See below.

> Hi Mehmet,
> 
> "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]> wrote:
> > > ------------------------------------------------------------
> > >
> > > 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.
> 
> Can you give an example of a use case where this would be useful?

E.g. it allows to expose NE configuration/state data with CTs as an
alternate representation. The CT feature enables then to wrap this
alternate representation into a if-feature statement.

[...] 

> > > 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
> 
> Can you show how this would be done in the example I gave above?

In such a case vendor X would probably derive one or more vendor 
specific extensions from ancestors of ManagedHardware (something 
like "XChassis" and "XBackplane").

But again, as stated in section 2.13.2., we want to keep the 
modeling with complex types simple and propose the augmentation 
of complex type instances without recursion.

> > or
> > inherit from a class and add new attributes on the new class level.
> 
> 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.

It is true that you cannot augment complex types with recursion and 
in that respect they behave like groupings.
 
The approach we propose for the example above is to create sub-classes 
of the classes defined in the standard module and to enhance them with 
vendor specific data elements. This is the classical and straightforward

approach for modeling with inheritance.

> /martin

Cheers,
Mehmet