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

[Andy Bierman <[e-mail]>]

On Thu, Aug 17, 2017 at 5:40 AM, Jan Lindblad <[e-mail]> wrote:

> >> 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.
> >
> > I again fail to see the difference here between #4 and #5. Simple
> > clients will fail in the same way. Option #4 allows smarter clients
> > that are able to determine upfront that they won't work with a certain
> > server.
> >
> > Perhaps your logic is that a smarter client will still have to expect
> > that a server is not entirely implementing a model (i.e., doing #5)
> > with out documenting this, and hence since the smarter client has to
> > expect some servers to be 'incomplete' anyway you can equally well
> > expect all of them to be 'incomplete' and skip the effort to decide
> > upfront whether a server implements a model 'complete enough' for the
> > client to work.
>
> I think we're mostly in agreement. In this case where we only talk about
> optional config false leafs, the client will have to cope with any/all of
> them being absent in any case. Bit masks, if-feature or deviation
> not-supoprted statements are not going to change that. In that case #5 is
> the leanest solution.
>
> I don't look at client applications the same way as you do, however. You
> think a simple client is one that would fail if the YANG is randomly
> deviated, while a smarter one would cope. In my experience, it's the other
> way around. The really simple clients are just browsers that print whatever
> they get. They don't care if something is missing, or if a leaf is of a
> different type than stated in the standard YANG. It's the smart clients
> that actually understand and use the returned information for complex
> decisions that will fail when things deviate.
>
> 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.




>
> /jan
>


Andy


>
> _______________________________________________
> yang-doctors mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/yang-doctors
>