Subject: Re: [netmod] Augmentable Groupings

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 30 Sep 2008 15:28:42 +0200

Hi All,

looking at the discussion around the proposal of the 
augmentable grouping feature, I think that there is no 
rough consensus to integrate this feature into YANG.

I think the main motivation that lead to this proposal 
was in particular being able to extend commonly used 
groupings in an effective manner by augmenting them 
with additional nodes. I see a value in this feature for 
the seamless distribution of grouping extensions.

However, the question "Is it a bug or feature?" is not 
easy to answer.

Martin Bjorklund wrote on September 24, 2008 9:50 PM
> "Randy Presuhn" <[email-masked]> wrote:
>> (1) to provide a means of implementing something functionally
equivalent
>> to subclassing, in which either all or none of the instances of the
superclass
>> in a given system will also be instances of the subclass.
>
> This is what augmentable groupings try to solve.

As I understand this proposal was not meant to be an 
OO feature. Augmentable Groupings are functionally 
not equivalent to subclassing or inheritance. IMO OO 
features should be prepared based on complex types 
as an extension of the YANG type system (i.e. typed 
objects) which is far beyond of what augmentable 
groupings is proposing.

Balazs Lengyel <[email-masked]> wrote:
>> Hello,
>> When I am defining my data models in some specific situations I
already know
>> that I intend a part to be augmented/extended.
>> 
>> I also don't see why this is such a dangerous feature because:
>> - you face most of the same problems with augmenting a lists or
containers

I also was thinking that this is not a dangerous feature 
but ....

Martin Bjorklund wrote on September 24, 2008 3:19 PM:
>There is one main problem with this proposal.  It is summarized in one
>of the first emails on this topic:
>http://www.ietf.org/mail-archive/web/netmod/current/msg00784.html
>
>You do NOT have this problem with normal augment.
>Adding an 'augementable' flag does not solve this problem.

... this is the point where I start yielding. The current 
proposal for augmentable groupings so far does not 
provide a solution for the issue addressed by Phil.

Therefor I would like to suggest not to spend additional 
discussion bandwith for this topic and resume later if 
we have some written text and a better understanding 
of language abstractions for YANG.

Cheers, 
Mehmet

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of ext Andy Bierman
> Sent: Sunday, September 28, 2008 3:37 PM
> To: Randy Presuhn
> Cc: [email-masked]
> Subject: Re: [netmod] Augmentable Groupings
> 
> Randy Presuhn wrote:
> > Hi -
> > 
> >> From: "Martin Bjorklund" <[email-masked]>
> >> To: <[email-masked]>
> >> Cc: <[email-masked]>
> >> Sent: Wednesday, September 24, 2008 7:10 AM
> >> Subject: Re: [netmod] Augmentable Groupings
> > ...
> >> Because that's how augment of a grouping would work - if someone
> >> augments a grouping, it affects all other users of that 
> grouping (in a
> >> device which implements the augmenting module).
> > ...
> > 
> > Maybe it would be helpful to step back and consider what the reasons
> > for wanting to do "augmentation" are.  I've seen three in 
> the SNMP world.
> > Forgive the O-O terminology.
> > 
> > (1) to provide a means of implementing something 
> functionally equivalent
> > to subclassing, in which either all or none of the 
> instances of the superclass
> > in a given system will also be instances of the subclass.
> > 
> 
> Is this how OO works?  I think not.
> If you want to modify all instances of a class, don't
> you have to modify that class definition, or 1 of its ancestors?
> 
> Ignoring all the implementation details for augmentable
> groupings, this does not seem to be a data modeling practice
> that is currently in use.  It seems better suited to the
> IRTF than the IETF at this time.
> 
> We have lots of experience with vendors augmenting specific
> objects in SNMP, and it is quite reasonable to support
> that same sort of functionality in NETCONF and YANG.
> We have no experience with augmenting arbitrary abstractions,
> which in turn can use other groupings as well as augment
> other groupings.  If one really thought about all the
> new complexity due to the nature of the data-def-stmt,
> this feature may not seem so great after all.
> 
> 
> > (2) to provide a means of formally requiring that instances 
> of two classes
> > within a system exist in a 1:1 relationship.
> > 
> > (3)  To allow standards devlopers to get agreement on a basic subset
> > capability, providing a hook for other standards (or vendors) to add
> > additional capabilities subject to the same constraints as 
> in (1) above.
> > 
> > If we separate (2) out as really being a different kind of 
> "beast", this problem
> > reduces to the one of what netmod's basic metamodel is, and 
> how module
> > / definition revision and refinement ares handled.  Until 
> this gets hammered
> > out, these same arguments will just keep coming up again and again.
> > 
> > Randy
> > 
> 
> 
> Andy
> 
> _______________________________________________
> 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: "Linowski, Bernd (EXT-Other - DE/Dusseldorf)" <[email-masked]>
Date: Tue, 30 Sep 2008 18:24:13 +0300

Hi,

> rough consensus to integrate this feature into YANG.

This is also my impression.

> objects) which is far beyond of what augmentable 

I agree. The idea was to strengthen the applicability of groupings
to represent basic concepts that may be extended in a uniform manner
and to do this with already existing YANG language features.

> provide a solution for the issue addressed by Phil.

Yes. So an alternative is to define basic concepts as well
as extensions in own groupings and augment all the places 
one by one where an extension makes sense.

 module B {
    grouping NetworkInterface {
      // ...
    }
    // ...
 }
  module X {
  grouping HighCapacityInterfaceExtension {
      list HighCapacityInterface {
           // ...
      } 
    }
   augment "B:/controller/interfaces" {
     use HighCapacityInterfaceExtension;
   }
   augment "B:/transceiver/interfaces" 
     use HighCapacityInterfaceExtension;
   }
   // ....
}

As discussed with Balazs in Dublin, using a list 
as base element in the grouping could help
to identify extensions and avoid name clashes.

BR,
Bernd

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 30 Sep 2008 17:45:22 +0200

>      use HighCapacityInterfaceExtension;

Yes, this makes it decidable for tools where the extension applies and
where not. And with the when statement in place, you might even be
able to express further constraints when the extension makes sense.

> to identify extensions and avoid name clashes.

I do not see the name clash problem since the added XML elements exist
in the XML namespace associated with module X and not in the XML
namespace associated with module B. I am not sure why a list is
needed. Balazs, am I missing something?

/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

---

From: Andy Bierman <[email-masked]>
Date: Tue, 30 Sep 2008 13:04:50 -0700

Hi,

.....
> ....

The curly brace placement is important here.
Maybe I am missing too many details, but this
looks like normal augments -- what we have now.

The augment statements are outside the HighCap.. grouping.
Module X in this example has 3 top-level body-stmts.

I do not see how the NetworkInterface grouping relates
to the HighCapacityInterfaceExtension grouping.
There is no 'uses' for 'NetworkInterface'.

It would help to see a complete example and the fully
expanded results of all augments and uses.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 30 Sep 2008 22:17:08 +0200

> looks like normal augments -- what we have now.

Yes - I thought that this was his conclusion; we live with
augmentations as they are defined today (and they require to
be explicit about what is being augmented).

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 01 Oct 2008 08:37:07 +0200

> be explicit about what is being augmented).

I wonder - are there any use cases where this is not sufficient?

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 01 Oct 2008 10:22:28 +0200

> needed. Balazs, am I missing something?
I don't exactly remember the discussion.
I don't see any naming clashes either.

This solution allows you to check in the on-the-wire XML which basic grouping/list and which 
extension list/grouping is present, as the list itself carries the name of the grouping (only 
by a self-imposed naming convention).

Balazs

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 1 Oct 2008 10:39:23 +0200

On Wed, Oct 01, 2008 at 10:22:28AM +0200, Balazs Lengyel wrote:

> This solution allows you to check in the on-the-wire XML which basic 
> grouping/list and which extension list/grouping is present, as the list 
> itself carries the name of the grouping (only by a self-imposed naming 
> convention).

Why is this needed? There is a namespace, no? Since I know the modules
implemented on a device and their namespaces, I have everything I need
to identify the exact definition of something.

/js