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

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

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.

Giles