Subject: Re: [netmod] Augmentable Groupings

From: <[email-masked]>
Date: Wed, 13 Aug 2008 17:01:55 +0300

Hi,

Phil Shafer [email-masked] wrote:
> The reverse is also true, and I think this is the problem
> with this proposal.  When you augment a grouping, you have
> no idea who has used it and what havoc you are wrecking on
> those other users.
> 
> Imagine the case where I have taken your NetworkInterface
> grouping and used it in a list of low speed interfaces:
> 
>     list slow-dudes {
>         use NetworkInterface;
>         leaf how-slow {
>             type enumeration {
>                 enum very-slow { ... }
>                 enum horribly-slow { ... }
>                 enum 2g { ... }
>             }
>         }
>     }
> 
> When you augment NetworkInterface in your module, I suddenly get
> your ifHCIn/OutOctets leafs, which are completely inappropriate.

But in this case you should not augment the NetworkInterface grouping
but rather augment HC features to the place where HC support is needed.

Another option is to use a 'when' statement in the augmentation:

 augment NetworkInterface { 
    when "if:ifSpeed > 100000000";
    leaf ifHCInOctets {type Counter64;} 
    leaf ifHCOutOctets {type Counter64;} 
    // . . 
   } 

This kind of "selective augmentations" would be anyway
recommended in case the augmented contents makes only
sense under certain circumstances.

> I can't turn them off and I can't tell nm apps "hey he didn't
> mean my list".  Sure, I can choose not to implement/announce
> your module, but if both slow-dudes and HCSupport are IETF
> standards, I'm stuck.
> 
Of course, in this case only one of the two IETF standards can
be implemented. But this happens if standard body B extends
something from standard body A without aligning their models.
To avoid such a problem standard body A should extend the module 
in a consistent manner - based on input of standard body B.

> I see the attraction of "say it once and it happens everywhere",
> but the down side far overways the benefit.

Augmentable groupings also solve another problem you would 
have when an existing standard should be enhanced with a standard
addition (Martin B. made us aware of this scenario):

Assuming that grouping 'NetworkInterface' is used
in two modules that you also don't control by yourself
  module X {
     import NetworkInterfaces {prefix if; } 
     list interfaces {
        uses if:NetworkInterface
     }
  }
  module Y {
     import NetworkInterfaces {prefix if; } 
     list interfaces {
        uses if:NetworkInterface
     }
  }

In case you want to add a HC support standard extension without
augmentable groupings, what could be done is to define a grouping

module NetworkInterfacesExt {
 grouping HCInterfaceExtensions { 
    when "if:ifSpeed > 100000000";
    leaf ifHCInOctets {type Counter64;} 
    leaf ifHCOutOctets {type Counter64;} 
    // . . 
   }  

and augment this grouping in every place "NetworkInterface" is used:

  module VENDOR_SPECIFIC {
     import X {prefix x;}
     import Y {prefix y;}   
     import NetworkInterfacesExt {prefix ifex;}

     augment x:interfaces {
        uses ifex:HCInterfaceExtensions;
     }    
     augment y:interfaces {
        uses ifex:HCInterfaceExtensions;
     }  
 
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.

Contrast this with putting the augmentation of the
grouping NetworkInterfaces in the module NetworkInterfacesExt.
In this case the HC-counters appear in the "correct"
namespace - so a client that knows only modules
NetworkInterface and NetworkInterfaceExt" has no
problem of understanding them.
Not to mention that the explicit augment statements
are not needed.

BR,
Bernd

> Thanks,
>  Phil

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

---

From: Phil Shafer <[email-masked]>
Date: Wed, 13 Aug 2008 10:58:40 -0400

>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.

>be implemented.

This would be an unacceptable outcome.

>To avoid such a problem standard body A should extend the module=20

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.

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.

>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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 18 Aug 2008 14:36:05 +0200

> what a module gets when they say use a grouping.

I share Phil's concerns.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod