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

[Norm Strahle <[e-mail]>]

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]<mailto:[e-mail]>> wrote:
On 17 Aug 2017, at 16:49, Jan Lindblad <[e-mail]<mailto:[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<http://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