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

[Jan Lindblad <[e-mail]>]

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

Agreed, but "a feature for every counter" is option #1. There are no if-features in option #5, there's only reliance on leafs being optional and abstention from inventing local protocols based on the description field.

The problem with #4 is that many clients faithfully implementing applications based on the advertised, standard model will break. To fix the breakage requires after the fact programmer intervention. Not very software-defined. The long term effect is that application developers ignore standard models since custom adaptation to each device's implementation is required anyway, if deviations are used more than very occasionally.

/jan