Subject: Re: [netmod] Augmentable Groupings

From: <[email-masked]>
Date: Thu, 14 Aug 2008 17:34:48 +0300

Hi,

Phil Shafer [email-masked] wrote: 
> [email-masked] writes: 
> >But in this case you should not augment the NetworkInterface grouping

> >but rather augment HC features to the place where HC support 
> is needed. 
> 
> The scenario remains. If anyone can augment a grouping, one module's 
> augmentation can interfere with the use of the grouping in another 
> module. If you allow augmenting of groupings, you lose control of 
> what a module gets when they say use a grouping. 

Yes - but due to the fact that augmentation already exists in YANG 
it always can happen that you get stuff into the data you wouldn't
expect there. 
The user needs to be aware of this fact in general because of
augmentations.

> 
> >Of course, in this case only one of the two IETF standards can 
> >be implemented. 
> 
> This would be an unacceptable outcome. 
> 
> >To avoid such a problem standard body A should extend the module 
> >in a consistent manner - based on input of standard body B. 
> 
> This may not be possible. If A's module is already published, 
> B simply cannot use that grouping. This would require that any 
> modeler that wants to use a grouping must understand all the other 
> module writers that have augmented that grouping and avoid groupings 
> that are augmented in unacceptable ways. This is unworkable. 

So what would be the alternative? 
Standard body A augments some places where a particular grouping is
used. 
Standard body B augments the same places where this grouping is used. 
Assuming the additions of A and B are incompatible 
the effect would also be that an agent can only 
implement A or B - but not both. 

The root cause is in my opinion that augmentations always
have the risk of creating broken data node trees in case
an agent wants to support different models specified by
bodies that do not coordinate their work. 

Paraphrasing your statement above, with augmentations as it is 
defined today, it requires that any modeler who wants to augment 
a data node must understand other modules that have augmented 
that data node and avoid augmentations which are incompatible. 

> 
> Worse, add a mixture of standard and proprietary modules. If 
> I'm a making a proprietary model and want to use a grouping 
> defined in a standard module, I cannot since I must be aware 
> of the possibility of another working group augmenting that 
> grouping in the future in ways that are incompatible with my 
> use of the grouping. 

IMO "augmentable grouping" feature gets blamed for the 
fact that it makes apparent that augmentation in general
could have undesired effects if not used correctly. 

BR, 
Bernd 

> 
> >The effect of that is that the HC-counters are in 
> >the namespace of the vendor specific module. So 
> >clients that only understand NetworkInterface and 
> >NetworkInterfaceExt don't understand the 
> >HC-counters as they are in a non-standard namespace. 
> 
> I would contend that this is a feature, since the bits you are 
> adding that are _not_ in the original module are unknown to 
> applications that only understand the original module and _should_ 
> be in a distinct namespace. 
> 
> Worse, if you put these augmented nodes in the original namespace, 
> you become ambiguous if the original module's author adds those 
> nodes to their module. 
> 
> Thanks, 
> Phil 
> 

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

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 14 Aug 2008 21:08:52 +0200 (CEST)

Hi,

> it always can happen that you get stuff into the data you wouldn't

But this is different.  Normal augment is explicit.  In your interface
example, when you do your explicit augmentations, you will not augment
the "slow-dudes" list with HC counters.  But you do get into this
problem if you augment a grouping.

So IMO, this is a problem with the proposed new feature.

> implement A or B - but not both. 

You don't have to go to augment to find this (theoretical?) problem.
What if std body A defines a module w/ some objects and std body B
another module wih some objects, and they are incomatible?  Then a
device cannot implement both A and B.

I don't think this is a problem for augment.

/martin