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

From: Ing-Wher Chen <[email-masked]>
Date: Wed, 16 Aug 2017 18:09:27 +0000

Hello YANG doctors,

We wish to define a YANG model with several counters.  The counters that we wish to model are the union of all the counters supported by our sample of vendors.  This means that the model will define some counters supported by both vendor_1 and vendor_2 (or more), but some counters will be supported only by one of the vendors.  We would like the model to allow each vendor to indicate the counters it supports.

We can think of 3 approaches below, and would like your feedback regarding which approach we should choose.  We're also open to suggestions of other approaches.

Option 1: Define an optional feature (if-feature) for each counter.

Sample:
  container queuing-statistics-opt-1 {
    config false;
    description
      "queue related statistics ";
    leaf output-pkts {
      if-feature "output-pkts";
      type uint64;
      description
        "Number of packets transmitted from queue ";
    }
    leaf output-bytes {
      if-feature "output-bytes";
      type uint64;
      description
        "Number of bytes transmitted from queue ";
    }
    leaf queue-size-pkts {
      if-feature "queue-size-pkts";
      type uint64;
      description
      "Number of packets currently buffered ";
    }
    /* etc. */
  }

Advantage: This is the standard approach built into the language to make a statement conditional.

Disadvantage: There are many counters, and each counter will be an optional feature, resulting in many optional features in the model.

Option 2: Define a leaf of the type bits, where each bit indicates that a particular counter is supported.

Example:
  container queuing-statistics-opt-2 {
    config false;
    description
      "queue related statistics ";
    leaf supported-counters {
      type bits {
        bit queue-output-pkts;
        bit queue-output-bytes;
        bit queue-size-pkts;
      }
    }
    leaf output-pkts {
      type uint64;
      description
        "Number of packets transmitted from queue ";
    }
    leaf output-bytes {
      type uint64;
      description
        "Number of bytes transmitted from queue ";
    }
    leaf queue-size-pkts {
      type uint64;
      description
      "Number of packets currently buffered ";
    }
    /* etc. */
  }

Advantage: This reduces the number of optional features in the model.

Disadvantage: The output that indicates which counters are supported might be too verbose to be user friendly.  This is not YANG's standard approach to make a statement conditional.

Option 3: Define a leaf of the type integer, where each bit in the integer indicates that a particular counter is supported.

Example:
  container queuing-statistics-opt-3 {
    config false;
    description
      "queue related statistics ";
    leaf supported-counters {
      type uint32;
      description
        "Bit 0 indicates whether output-pkts counter is supported
         Bit 1 indicates whether output-bytes counter is supported
         Bit 2 indicates whether queue-size-pkts counter is supported";
    }
    leaf output-pkts {
      type uint64;
      description
        "Number of packets transmitted from queue ";
    }
    leaf output-bytes {
      type uint64;
      description
        "Number of bytes transmitted from queue ";
    }
    leaf queue-size-pkts {
      type uint64;
      description
      "Number of packets currently buffered ";
    }

Advantage: The output, in the form of a single integer, that indicates which counters are supported is compact.

Disadvantage: The model is vague/implicit---the meaning of each bit in supported-counters is embedded in the description, rather than modeled explicitly.  This is also not YANG's standard approach to make a statement conditional.

Thanks,

Helen

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 17 Aug 2017 07:06:48 +0200

> Option 3: Define a leaf of the type integer, where each bit in the integer indicates that a particular counter is supported.

Let me add:

Option 4: Vendors publish deviations that document how they deviate from
the standard.

Advantage: This is the standard approach built into the language to document
how an implementation deviates from a standard.

Disadvantage: Vendors do not like to document deviations, hence they
like to see every little counter as a feature.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Jan Lindblad <[email-masked]>
Date: Thu, 17 Aug 2017 10:07:44 +0200

> like to see every little counter as a feature.

Disadvantage (fundamental) with deviations: Application developers who are adopting standard YANG models (yay!) as their southbound interface have no way of knowing which deviations vendors will release on their devices. So their applications will typically fail when things they count on isn't supported or is supported differently. When standard YANG models have if-feature statements, reasonably prudent application developers will build applications prepared for the case that some information might not be there. 

Conclusion: deviations are very bad (ambush) for the uptake of standard YANG models.

Option 5: Let each implementation return the data it supports without any content declaration

Since this is optional operational data, it's formally up to the application to simply return any collected data it has and skip any other leafs.

Advantage: Dead simple to understand for server and client alike, and zero complication on the YANG level. IMO cleaner and clearer than options 2, 3, 4. Even if any of the options 2-4 were implemented, the client would still have to be prepared to not receive any particular leaf since they are all optional. If I implemented the client, I probably wouldn't even bother to read that bit mask/whatever.

Disadvantage: Application developers will have no way of knowing a priori which data may arrive from a particular server. If this is important, option 1 would clearly be better.

/jan

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 17 Aug 2017 10:15:38 +0200 (CEST)

Jan Lindblad <[email-masked]> wrote:
> Since this is optional operational data, it's formally up to the
> application to simply return any collected data it has and skip any
> other leafs.

I was just going to suggest this as well.  I think the description
statement can make it clear that if the implementation doesn't have a
value for the counter, the node is not instantiated.  (note that this
is slightly different from saying that the node is not implemented;
the instrumentation code would know the names of all counters, but
not instantiate all of them, rather than just know the names of the
ones it "supports".)

/martin

> Advantage: Dead simple to understand for server and client alike, and
> zero complication on the YANG level. IMO cleaner and clearer than
> options 2, 3, 4. Even if any of the options 2-4 were implemented, the
> client would still have to be prepared to not receive any particular
> leaf since they are all optional. If I implemented the client, I
> probably wouldn't even bother to read that bit mask/whatever.
> 
> Disadvantage: Application developers will have no way of knowing a
> priori which data may arrive from a particular server. If this is
> important, option 1 would clearly be better.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 17 Aug 2017 10:37:39 +0200

> Disadvantage: Application developers will have no way of knowing a priori which data may arrive from a particular server. If this is important, option 1 would clearly be better.

I fail to see why #5 is any better than #4.

I believe a feature for every counter is a misuse of YANG feature
statements, it will get horribly ugly. I recently observe an increase
of feature statement usage in order to accomodate server
implementations and the ultimate solution is a feature statement for
every leaf, list, rpc, action, notification and perhaps even certain
value sets. This is ridiculous, but a feature for every counter is
getting damn close to it.

/js

---

From: Jan Lindblad <[email-masked]>
Date: Thu, 17 Aug 2017 13:02:44 +0200

> getting damn close to it.

Agreed, but "a feature for every counter" is option #1. There are no if-features in option #5, there's only reliance on leafs being optional and abstention from inventing local protocols based on the description field.

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.

/jan

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 17 Aug 2017 14:04:51 +0200

> 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…

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.

/js

---

From: Jan Lindblad <[email-masked]>
Date: Thu, 17 Aug 2017 14:40:51 +0200

> upfront whether a server implements a model 'complete enough' for the

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.

/jan

---

From: Andy Bierman <[email-masked]>
Date: Thu, 17 Aug 2017 08:32:17 -0700

On Thu, Aug 17, 2017 at 5:40 AM, Jan Lindblad <[email-masked]> 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 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/yang-doctors
>

---

From: Jan Lindblad <[email-masked]>
Date: Thu, 17 Aug 2017 17:49:58 +0200

> Doesn't your client build a session-specific schema tree based on the advertised modules?
> 
> They tell the client that the missing counters are not implemented as opposed
> Deviations are known at session startup time but they can also be known in advance.
> 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.

/jan

---

From: "Giles Heron (giheron)" <[email-masked]>
Date: Thu, 17 Aug 2017 15:56:02 +0000

On 17 Aug 2017, at 16:49, Jan Lindblad <[email-masked]<mailto:[email-masked]>> wrote:

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.

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.

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

---

From: Andy Bierman <[email-masked]>
Date: Thu, 17 Aug 2017 09:06:17 -0700

On Thu, Aug 17, 2017 at 8:56 AM, Giles Heron (giheron) <[email-masked]>
wrote:

> On 17 Aug 2017, at 16:49, Jan Lindblad <[email-masked]> wrote:
>
>
> 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?
>
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.

Andy

---

From: "Giles Heron (giheron)" <[email-masked]>
Date: Thu, 17 Aug 2017 16:13:12 +0000

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

On Thu, Aug 17, 2017 at 8:56 AM, Giles Heron (giheron) <[email-masked]<mailto:[email-masked]>> wrote:
On 17 Aug 2017, at 16:49, Jan Lindblad <[email-masked]<mailto:[email-masked]>> wrote:

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.

A2) because it counts the FIZZBANG protocol, and that protocol is not used on every device

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

---

From: Norm Strahle <[email-masked]>
Date: Thu, 17 Aug 2017 16:15:40 +0000

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:[email-masked]]
Sent: Thursday, August 17, 2017 12:06 PM
To: Giles Heron (giheron) <[email-masked]>
Cc: Jan Lindblad <[email-masked]>; [email-masked]; Ing-Wher Chen <[email-masked]>; Norm Strahle <[email-masked]>; Aseem Choudhary (asechoud) <[email-masked]>
Subject: Re: [yang-doctors] question regarding conditional/optional statements

Giles

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 17 Aug 2017 10:21:13 -0700

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 <[email-masked]> 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:[email-masked]]
> *Sent:* Thursday, August 17, 2017 12:06 PM
> *To:* Giles Heron (giheron) <[email-masked]>
> *Cc:* Jan Lindblad <[email-masked]>; [email-masked]; Ing-Wher
> Chen <[email-masked]>; Norm Strahle <[email-masked]>;
> Aseem Choudhary (asechoud) <[email-masked]>
> *Subject:* Re: [yang-doctors] question regarding conditional/optional
> statements
>
>
>
>
>
>
>

---

From: Kent Watsen <[email-masked]>
Date: Thu, 17 Aug 2017 18:17:08 +0000

> getting damn close to it.

This is a programmatic API.  I appreciate the concern for a bloat of
bits on the wire, but recall that features are listed in yang-library,
a very special module that has a built-in ETag-like hashing mechanism
to allow for efficient comparisons.  I don't see the bloat issue here.

Having feature statements everywhere may be ridiculous, but not illegal.
Implementations need to be able to handle it already, right?

Kent

---

From: Andy Bierman <[email-masked]>
Date: Thu, 17 Aug 2017 12:02:56 -0700

> Implementations need to be able to handle it already, right?
good points.
They all apply equally to deviations and features.

I think the way you used features in the client-server set of modules is a
good example
for solving this sort of problem.  The if-feature-stmts are on containers,
not
individual leafs.

I don't think special objects that return which other objects are
implemented
is good because it is not a generalized solution.  A better approach would
be
to enhance the protocols so "not-implemented" and "temp-unavailable"
exceptions
can be returned on request (ala with-defaults)

Andy

---

From: Norm Strahle <[email-masked]>
Date: Fri, 18 Aug 2017 12:59:10 +0000

Hey folks, Appreciate all the feedback.  We discussed yesterday among diffserv-ietf modelers yesterday and had a couple comments:

·       We liked explicit statements (deviations, features, flag-bits) rather than implicit – i.e. option 5 – of vendors leaving unsupported leaves out of containers

·       We think if-features or the “bit” flag mechanism are better than deviations, as it at least allows clients to anticipate up front that some items may not be supported.

·       One advantage of using the “bit” flag mechanism – i.e. option 2 - over features is that this allows a vendor to specify per-interface what is supported.  What features a vendor supports for diffserv is very hardware dependent and may vary from interface to interface within a single device. A device may have multiple types and generations of line cards, and thus, the types of stats supported will be different. The bit-flag mechanism allows a device to reflect that to the client explicitly.

Thoughts on all the above are much appreciated.
Thanks,
Norm

From: Andy Bierman [mailto:[email-masked]]
Sent: Thursday, August 17, 2017 3:03 PM
To: Kent Watsen <[email-masked]>
Cc: Juergen Schoenwaelder <[email-masked]>; Jan Lindblad <[email-masked]>; [email-masked]; Ing-Wher Chen <[email-masked]>; Norm Strahle <[email-masked]>; Aseem Choudhary (asechoud) <[email-masked]>
Subject: Re: [yang-doctors] question regarding conditional/optional statements

good points.

I think the way you used features in the client-server set of modules is a good example
for solving this sort of problem.  The if-feature-stmts are on containers, not
individual leafs.

I don't think special objects that return which other objects are implemented
is good because it is not a generalized solution.  A better approach would be
to enhance the protocols so "not-implemented" and "temp-unavailable" exceptions
can be returned on request (ala with-defaults)

Kent

Andy

_______________________________________________
yang-doctors mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/yang-doctors

---

From: Kent Watsen <[email-masked]>
Date: Mon, 21 Aug 2017 14:46:09 +0000

If being able to specify per-interface is critical, then clearly features won't work.

Too bad, a static/metadata based approach would be better, but it would require us defining something like a hardware-catalog whereby each hardware component comes with a metadata file describing it.  I've done this before, but we have nothing like it in the IETF.

If you use the bit-mechanism, than you chould consider using the bit-is-set() XPath function in a 'when' expression to make the intention clearer, just technical documentation, not something that is expected to constrain the server.

Between the two choices, I'm more for just leaving fields out because it's simpler and, as a client, I'd rather:

            for each child in queuing-statistics-opt-2
                read child, determining which counter it is in the process

than

            for each bit set in 'supported-counters'
                  use switch/case or if/else to map the bit to a counter-leaf name
                      read counter-leaf value

Kent

On 8/18/17, 8:59 AM, "Norm Strahle" <[email-masked]<mailto:[email-masked]>> wrote:

good points.

Kent

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 21 Aug 2017 19:08:33 +0200

> Implementations need to be able to handle it already, right?

Perhaps not illegal, but a misuse of the intention of the concept. A
single leaf is not what we considered a feature.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 21 Aug 2017 19:21:28 +0200

> ·       We think if-features or the “bit” flag mechanism are better than deviations, as it at least allows clients to anticipate up front that some items may not be supported.

A decent implementation will expect deviations, deviations are always
possible. I think there is a circular argument here, which boils down
to "we do not want to use deviations because we do not want to process
deviations".
 
> ·       One advantage of using the “bit” flag mechanism – i.e. option 2 - over features is that this allows a vendor to specify per-interface what is supported.  What features a vendor supports for…

As long as we talk about non-mandatory counters, simply not reporting
counters that do not exist seems to be the most simple solution. If
you want to tell clients upfront that a counter will never exist, use
the deviation mechanism. This is why we have it.

/js

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 21 Aug 2017 17:33:33 +0000

On 8/21/17, 1:21 PM, "yang-doctors on behalf of Juergen Schoenwaelder"
<[email-masked] on behalf of
[email-masked]> wrote:

>> Hey folks, Appreciate all the feedback.  We discussed yesterday among
>>diffserv-ietf modelers yesterday and had a couple comments:
>> 
>> 
>> ·       We liked explicit statements (deviations, features, flag-bits)
>>rather than implicit – i.e. option 5 – of vendors leaving unsupported
>>leaves out of containers
>> 
>> ·       We think if-features or the “bit” flag mechanism are better
>>than deviations, as it at least allows clients to anticipate up front
>>that some items may not be supported.
>
>> ·       One advantage of using the “bit” flag mechanism – i.e. option 2
>>- over features is that this allows a vendor to specify per-interface
>>what is supported.  What features a vendor supports for diffserv is very
>>hardware dependent and may vary from interface to interface within a
>>single device. A device may have multiple types and generations of line
>>cards, and thus, the types of stats supported will be different. The
>>bit-flag mechanism allows a device to reflect that to the client
>>explicitly.
>>
>
>counters that do not exist seems to be the most simple solution.

This is exactly what we are doing in many Routing YANG models.

> If you want to tell clients upfront that a counter will never exist, use

I would think a client could ascertain that a counter is not supported if
it is not returned.

Thanks,
Acee

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 21 Aug 2017 22:06:17 +0200

> I would think a client could ascertain that a counter is not supported if

In practice yes, in theory not. (The counter might not be returned due
to a lack of permissions).

/js

---

From: Benoit Claise <[email-masked]>
Date: Wed, 30 Aug 2017 16:10:14 +0200

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.
> Usually the groups have descriptions to say when a server should 
> implement the group.
> On Thu, Aug 17, 2017 at 9:15 AM, Norm Strahle <[email-masked] 
> <mailto:[email-masked]>> 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:[email-masked]
>     <mailto:[email-masked]>]
>     *To:* Giles Heron (giheron) <[email-masked]
>     <mailto:[email-masked]>>
>     *Cc:* Jan Lindblad <[email-masked] <mailto:[email-masked]>>;
>     [email-masked] <mailto:[email-masked]>; Ing-Wher
>     Chen <[email-masked] <mailto:[email-masked]>>;
>     Norm Strahle <[email-masked] <mailto:[email-masked]>>;
>     Aseem Choudhary (asechoud) <[email-masked]
>     <mailto:[email-masked]>>
>     *Subject:* Re: [yang-doctors] question regarding
>     conditional/optional statements
>
>     On Thu, Aug 17, 2017 at 8:56 AM, Giles Heron (giheron)
>     <[email-masked] <mailto:[email-masked]>> 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
>                 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?
>