Subject: Re: [netmod] YANG augmentation question

From: Xufeng Liu <[email-masked]>
Date: Tue, 17 Mar 2015 12:29:28 +0000

Hi Juergen and Andy,
Tnanks for your valuable comments. Agree with what you said.

Best,
- Xufeng

-------- Original message --------
From: Andy Bierman <[email-masked]>
Date:03/13/2015 12:57 PM (GMT-05:00)
To: Juergen Schoenwaelder <[email-masked]>,Xufeng Liu <[email-masked]>,[email-masked]
Cc:
Subject: Re: [netmod] YANG augmentation question

On Fri, Mar 13, 2015 at 9:36 AM, Juergen Schoenwaelder
<[email-masked]> wrote:
> On Fri, Mar 13, 2015 at 04:09:07PM +0000, Xufeng Liu wrote:
>> During the discussion of YANG TE models, the following question was raised:
>>
>> Let's say that there are three protocols: A, B, and C. A is the base protocol; B and C are extensions based on A.  If we describe them from inheritance perspective, A is the base class, while B and C are derived classes. In this case, B is pretty much the same as A, with only ONE additional attribute.
>>
>> When we model the 3 classes in YANG, the approaches can be:
>>
>> 1)      Model A as a base module, containing all attributes of class A. Model B and C as separate modules. A doubt was brought up because B has only one attribute. Does it make sense to build a module for it?
>>
>> 2)      Alternatively, we can create a module A-B, containing all attributes of class A, plus the one attribute in class B. When we build module C, we need to suppress the one attribute of class B, and augment with C's attributes. To do the suppression, do we have better ways other than "deviation" statement?
>> Your preference and comments are appreciated.
>>
>
> If you were doing 2), you would make the B extension a feature. A box
> implementing A and C would then not announce this feature.
>
> It might also be worthwhile to look at the extended future of the
> protocols. Could it be that B only has one attribute but perhaps many
> more in the future? Or, alternatively, could it be that B is dying out
> because everybody loves C? This might also impact the decision how you
> group things together.
>
> Note that a separate module is not a bit thing, just one more
> namespace. If RFC processes are the concern, you can have modules A
> and B in one RFC (but they might have different lifes in the future).
>
> I would suggest to avoid a design that uses deviations. Deviations are
> meant to document implementation specific deviations, they are not
> meant to indicate that some object in another data model conflicts and
> is thus eliminated via deviation. Features should be used instead to
> make portions of a data model optional.
>

Agreed.

YANG conformance is directly coupled to the YANG module structure you select.
(Not that I am a fan of this approach).  You need to think
about the conformance requirements carefully when you
create YANG modules.

> /js

Andy

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