Subject: Re: [netmod] Augmentable Groupings

From: <[email-masked]>
Date: Wed, 13 Aug 2008 16:28:50 +0300

Hi, 

Andy Bierman [email-masked] wrote:
> Actually groupings are not in the same namespace as objects,
> so this Xpath is broken.
> 
> 
>     grouping foo;
> 
>     container foo;
> 
> Both of these are legal YANG.

That is not in line what is stated in section 7.11 of the
YANG specification:
" If the grouping is defined at the top level of a YANG module or
   submodule, the grouping's identifier MUST be unique within the
   module."
Name "foo" is not unqiue within the module.

> 
> If I nest the groupings, then what happens to the augment:
> 
> module C {
> 
>    grouping new-concepts {
>       uses concepts;
>    }
> 
> Does new-concepts contain the augmentations from concepts?
> 

Yes.

> How is somebody reading 'uses C:new-concepts;' in module D
> know if this is augmented or not?
> 

The person or system reading 'uses C:new-concepts;' has
also to read module B (as this was advertized).
You anyway have to do that since in module B there could
be also an augment statement that is adding something else
to the place where 'uses C:new-concepts;' appears - which
has to be known as well.

> What if I want to use the 'concept' grouping with the augment and
> sometimes without it in the same system?  Advertising module B
> means that every use of concepts is now augmented.
> What if some existing 'uses concepts;' statements
> do not support the new nodes?
> 

Then augmenting the grouping should not be done.

> There are also conformance issues, depending on what the WG
> does about 'if-feature' and capabilities documentation.
> 
Augmenting a grouping should not be treated differently 
with respect to 'if-feature' than any other YANG modeling feature.

Assuming that the augmentaion of a group is inside an 'if-feature'
scope, then the augmentation would only become effective if the
referred feature is supported.

> How is a YANG compiler supposed to know that M of N modules
> will be augmenting groupings in other modules, which changes
> the uses expansion in all the modules.  Do you think the
> compiler is going to 'redo' N-1 modules, as it processes
> the Nth module?

Yes - as it could anyway happen that in module N an
augmentation to a node in modules 1..N-1 could have been done.

> 
> Have you implemented this feature in a complete NETCONF system?
> I am not convinced it is even implementable, let alone deployable.

I don't see that augmentable groupings make things more complicated
than they are already. As modules could already augment nodes in other
modules, the "effective node tree" must be build up incrementally.

In general, augmentable groupings extend the YANG augmentation 
feature as it is. So augmentable groupings have all benefits 
but also possible obstacles of augmentations.

BR,
Bernd

> 
> IMO, this approach has more unintended consequences than benefits.
> 
> 
> Andy
> 
> > In particular that would mean:
> > 
> > - A groupings can be the target (node) of an
> >   augment statement.
> > - Augmentation of a grouping becomes only effective
> >   in case the module containing the augment statement
> >   is advertized.
> > - The nodes added to the grouping are therefore
> >   implicitly added to all places the grouping is used
> >   in the set of modules supported by an agent.
> > - The augmented nodes are in the XML namespace
> >   of the module of the augment statement.
> > 
> > 
> > For example assume a module for providing a reusable
> > definition of network interface parameters
> > 
> > module Interfaces {
> >   grouping NetworkInterface {
> > 
> >     leaf ifName {type string;}
> >     leaf ifDescription {type DisplayString;}
> >     leaf ifMtu {type int32;}
> >     // . . .
> >     leaf ifSpeed {type Gauge;}
> >     leaf ifInOctets {type Counter;}
> >     // . . .
> >  }
> >  
> > which is then used to define one or more interface
> > lists (tables).
> > If now high capacity support should be added
> > consistently, this could be done by augmenting
> > this group with HC attributes:
> > 
> > module HCSupport {
> >   import NetworkInterfaces {prefix if; }
> >   augment /if:NetworkInterface {
> >     leaf ifHCInOctets {type Counter64;}
> >     leaf ifHCOutOctets {type Counter64;}
> >     // . .
> >    }
> > }
> > 
> > Of course, the module HCSupport should only
> > be used and advertized if HC support
> > is available for all interfaces controlled
> > by the advertizing agent.
> > 
> > There are different benefits of augmentable
> > groupings:
> > 
> > - Supports consistent and YANG-like extension
> >   of a grouping by using an existing language
> >   construct, i.e. it provides additional capabilities
> >   without introducing new keywords.
> > 
> > - Augmentable groupings maximize re-use of
> >   model code. In that sense augmentable
> >   groupings introduce a modeling mechanism,
> >   which is based on "true re-use" and is
> >   technically better compared to the existing
> >   grouping concept, which requires copying
> >   and pasting augmentation many times.
> > 
> > - When combined with the when statement,
> >   augmentable groupings even allow selective,
> >   content based augmentation in a consistent
> >   manner.
> > 
> > - Augmentable groupings adopt every benefit
> >   but also obstacle of augmentations in the YANG
> >   language. As it already has been suggested by
> >   Martin B., we would like propose that an augment
> >   MUST NOT add any mandatory nodes (i.e.
> >   mandatory leaf, list or leaf-list w/ min-elements > 0
> >   etc). An augment must not break a client that
> >   doesn't understand the augmentation.
> > 
> > - Augmenting all places where a grouping is used
> >   is error-prone and causes unnecessary development
> >   costs.
> >   The problem is actually worse than this.
> >   When someone writes an extension module,
> >   he/she might not know all places where the
> >   grouping must be augmented.
> > 
> > BR,
> > Bernd
> > 
> > 
> > 
> --------------------------------------------------------------
> ----------
> > 
> > _______________________________________________
> > netmod mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/netmod

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

---

From: Andy Bierman <[email-masked]>
Date: Wed, 13 Aug 2008 08:18:10 -0700

> Name "foo" is not unqiue within the module.

Here is the text from the draft:

6.2.1.  Identifiers and their namespaces

    Each identifier is valid in a namespace which depends on the type of
    the YANG item being defined:

    o  All module and submodule names share the same global module
       identifier namespace.

    o  All extension names defined in a module and its submodules share
       the same extension identifier namespace.

    o  All derived type names defined within a parent node or at the top-
       level of the module or its submodules share the same type
       identifier namespace.  This namespace is scoped to the parent node
       or module.

    o  All groupings defined within a parent node or at the top-level of
       the module or its submodules share the same grouping identifier
       namespace.  This namespace is scoped to the parent node or module.

    o  All leafs, leaf-lists, lists, containers, choices, rpcs, and
       notifications defined within a parent node or at the top-level of
       the module or its submodules share the same identifier namespace.
       This namespace is scoped to the parent node or module, unless the
       parent node is a case node.  In that case, the namespace is scoped
       to the parent node of the case node's parent choice node.

    o  All cases within a choice share the same case identifier
       namespace.  This namespace is scoped to the parent choice node.

    All identifiers defined in a namespace MUST be unique.

>  > Does new-concepts contain the augmentations from concepts?

Yes, well this makes it an NP-complete problem to resolve all the
uses statements in all the modules.

Even if that did not matter (just implementation!), the NETCONF
vendors have to deal with a pool of modules for which
they have no change control whatsoever.  And what about their own
modules already out there in shipping code?

This 'write once, and it shows up everywhere' feature is not
actually usable in the operational environment that YANG must address.

Andy

>  > > _https://www.ietf.org/mailman/listinfo/netmod_
>

---

From: <[email-masked]>
Date: Fri, 15 Aug 2008 18:43:29 +0300

Hi,

Andy Bierman [email-masked] wrote:
> -----Original Message-----
> From: ext Andy Bierman [mailto:[email-masked]] 
> Sent: 13 August, 2008 17:18
> To: Linowski Bernd (EXT-Other - DE/Dusseldorf)
> Cc: [email-masked]
> Subject: Re: [netmod] Augmentable Groupings
> 
> ....
> ....

I agree, there could be an ambiguity as there is a separate grouping 
identifier namespace. 

Let me reconsider the options how to address this.

BR,
Bernd

---

From: Andy Bierman <[email-masked]>
Date: Fri, 15 Aug 2008 09:03:34 -0700

> Let me reconsider the options how to address this.

This is a minor issue, easily fixed by collapsing the grouping
namespace into the object namespace.

The major issue is the ripple effect through all the uses,
what Phil calls the 'drive-by augment'.

If I create a derived class FooPrime from Foo,
all the instances of the Foo class are unchanged.
I actually have to change the code everywhere I
want to have an instance of FooPrime instead of Foo.
If I want to affect all instances of Foo, I
have to edit the Foo class itself (or its ancestors).

This is correct.  This is how it should work.
This is how grouping/uses does work.  You must
create a new grouping FooPrime (that uses Foo)
and change the exact uses statements where the
new version should be applied.

Andy