Re: [yang-doctors] question regarding conditional/optional statements

[Juergen Schoenwaelder <[e-mail]>]

On Thu, Aug 17, 2017 at 10:07:44AM +0200, Jan Lindblad wrote:
> >> Hello YANG doctors,
> >> 
> >> We wish to define a YANG model with several counters.  The counters that we wish to model are the union of all the counters supported by our sample of vendors.  This means that the model will define some counters supported by both vendor_1 and vendor_2 (or more), but some counters will be supported only by one of the vendors.  We would like the model to allow each vendor to indicate the counters it supports.
> >> 
> >> We can think of 3 approaches below, and would like your feedback regarding which approach we should choose.  We're also open to suggestions of other approaches.
> >> 
> >> Option 1: Define an optional feature (if-feature) for each counter.
> >> 
> >> Option 2: Define a leaf of the type bits, where each bit indicates that a particular counter is supported.
> >> 
> >> Option 3: Define a leaf of the type integer, where each bit in the integer indicates that a particular counter is supported.
> >> 
> > 
> > Let me add:
> > 
> > Option 4: Vendors publish deviations that document how they deviate from
> > the standard.
> > 
> > Advantage: This is the standard approach built into the language to document
> > how an implementation deviates from a standard.
> > 
> > Disadvantage: Vendors do not like to document deviations, hence they
> > like to see every little counter as a feature.
> 
> Disadvantage (fundamental) with deviations: Application developers who are adopting standard YANG models (yay!) as their southbound interface have no way of knowing which deviations vendors will release on their devices. So their applications will typically fail when things they count on isn't supported or is supported differently. When standard YANG models have if-feature statements, reasonably prudent application developers will build applications prepared for the case that some information might not be there. 
> 
> Conclusion: deviations are very bad (ambush) for the uptake of standard YANG models.
> 
> 
> Option 5: Let each implementation return the data it supports without any content declaration
> 
> Since this is optional operational data, it's formally up to the application to simply return any collected data it has and skip any other leafs.
> 
> Advantage: Dead simple to understand for server and client alike, and zero complication on the YANG level. IMO cleaner and clearer than options 2, 3, 4. Even if any of the options 2-4 were implemented, the client would still have to be prepared to not receive any particular leaf since they are all optional. If I implemented the client, I probably wouldn't even bother to read that bit mask/whatever.
> 
> Disadvantage: Application developers will have no way of knowing a priori which data may arrive from a particular server. If this is important, option 1 would clearly be better.
>

I fail to see why #5 is any better than #4.

I believe a feature for every counter is a misuse of YANG feature
statements, it will get horribly ugly. I recently observe an increase
of feature statement usage in order to accomodate server
implementations and the ultimate solution is a feature statement for
every leaf, list, rpc, action, notification and perhaps even certain
value sets. This is ridiculous, but a feature for every counter is
getting damn close to it.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <http://www.jacobs-university.de/>