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

[Benoit Claise <[e-mail]>]

Ing-Wher,

Reviewing the email thread now, do you have your conclusions?

Regards, B.
> 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] 
> <mailto:[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]
>     <mailto:[e-mail]>]
>     *Sent:* Thursday, August 17, 2017 12:06 PM
>     *To:* Giles Heron (giheron) <[e-mail]
>     <mailto:[e-mail]>>
>     *Cc:* Jan Lindblad <[e-mail] <mailto:[e-mail]>>;
>     [e-mail] <mailto:[e-mail]>; Ing-Wher
>     Chen <[e-mail] <mailto:[e-mail]>>;
>     Norm Strahle <[e-mail] <mailto:[e-mail]>>;
>     Aseem Choudhary (asechoud) <[e-mail]
>     <mailto:[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 likeyangcatalog.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
>
>
>
>
> _______________________________________________
> yang-doctors mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/yang-doctors