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

["Giles Heron (giheron)" <[e-mail]>]

On 17 Aug 2017, at 17:06, Andy Bierman <[e-mail]<mailto:[e-mail]>> wrote:



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.

sure - if most devices support most counters that’s the way I’d go.

but what if most devices don’t support most of the counters?  Seems like we’d have a lot of deviation going on…



Giles



Andy