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

[Andy Bierman <[e-mail]>]

Hi,

I guess it depends on what kind of functionality is being provided to the
client.
In this case it looks like there is no expectation of consistency or
requirement
for specific functionality. Features and deviations are both probably
overkill.

SMIv2 has the concept of GROUP and MANDATORY-GROUP.
In some ways SMIv2 conformance is much better than YANG,
except SNMP never got the capability discovery right.

Usually the groups have descriptions to say when a server should implement
the group.
If the criteria is "who knows, just implement it if you want" then the
module should make
that clear.


Andy


On Thu, Aug 17, 2017 at 9:15 AM, Norm Strahle <[e-mail]> wrote:

> In our particular case, queue counters, there are several counters and
> rates associated with a given queue (packets, bytes, transmitted, dropped,
> queued, tail drop, current depth, peak, average, max, transmit rate, drop
> rate, etc.)  It is easy to see where most manufactures support most, but
> likely not all.  So, likely all vendors would need to indicate which it is
> not supporting.  To me it would seem that a feature at least gives the
> client developer the hint up-front that this item is not required to be
> supported and to handle the case.  There is no clue from a model that a
> deviation is likely, so no way to anticipate. So, wouldn’t a feature be
> better in this case than a deviation?
>
>
>
> *From:* Andy Bierman [mailto:[e-mail]]
> *Sent:* Thursday, August 17, 2017 12:06 PM
> *To:* Giles Heron (giheron) <[e-mail]>
> *Cc:* Jan Lindblad <[e-mail]>; [e-mail]; Ing-Wher
> Chen <[e-mail]>; Norm Strahle <[e-mail]>;
> Aseem Choudhary (asechoud) <[e-mail]>
> *Subject:* Re: [yang-doctors] question regarding conditional/optional
> statements
>
>
>
>
>
>
>
> On Thu, Aug 17, 2017 at 8:56 AM, Giles Heron (giheron) <[e-mail]>
> wrote:
>
> On 17 Aug 2017, at 16:49, Jan Lindblad <[e-mail]> wrote:
>
>
>
> Have you ever seen a smart client that can cope with randomly deviated
> YANG models, unless a programmer has intervened and created special code
> for handing that particular deviating device type? I have not.
>
>
>
>
>
> Doesn't your client build a session-specific schema tree based on the
> advertised modules?
>
>
>
> Deviations are clearly better than just not returning anything.
>
> They tell the client that the missing counters are not implemented as
> opposed
>
> to possibly a temporary, recoverable condition.
>
>
>
> Deviations are known at session startup time but they can also be known in
> advance.
>
> Vendors use naming conventions to specify the platform-specific deviations.
>
> Tools like yangcatalog.org can make this process automated and de-facto
> standardized.
>
>
>
> NSO itself will be just fine, but I'm worried about the people building
> applications on top of NSO, e.g. an L3VPN application. Let's say a
> deviation comes up at session start, what's the application supposed to do
> then? I can't think of much that doesn't involve a programmer.
>
>
>
> Declared deviations are clearly better than deviating and not telling. But
> they are only really worth anything if they are known to the application
> programmer before he finishes his code. Yangcatalog.org
> <http://yangcatalog.org/> helps, but not all modules will be there and
> there's also a time dimension. Deviations found at session start are
> probably not worth anything other than as triggers for that special code
> someone wrote to handle the situation.
>
>
>
> I feel deviations should not be recommended lightly. In the particular
> case that started this discussion, they'd bring little value.
>
>
>
> right - isn’t deviation supposed to be for the case where you don’t
> support something that implementations are generally expected to support?
>
>
>
> for what Helen wants features seem to be a better fit - at least to me.
>
>
>
>
>
> Features are intended to convey that the functionality is optional.
>
> Presumably the data model is attempting to deliver some functionality to
> the client developer.
>
> Features correspond well to optional protocol capabilities.
>
> Generally a single counter is not considered to be high-level
> functionality.
>
>
>
> Ask the question "Why is counter FOO missing?"
>
>
>
> A1) because device XYZ does not support it
>
>
>
> A2) because it counts the FIZZBANG protocol, and that protocol is not used
> on every device
>
>
>
>
>
> If A1 then use deviations. If A2 then use features.
>
>
>
>
>
>
>
> Giles
>
>
>
>
>
>
>
> Andy
>
>
>