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

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" <nstrahle@juniper.net<mailto:nstrahle@juniper.net>> 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.

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

From: Andy Bierman [mailto:andy@yumaworks.com]
Sent: Thursday, August 17, 2017 3:03 PM
To: Kent Watsen <kwatsen@juniper.net>
Cc: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>; Jan Lindblad <janl@tail-f.com>; yang-doctors@ietf.org; Ing-Wher Chen <Ing-Wher_Chen@jabil.com>; Norm Strahle <nstrahle@juniper.net>; Aseem Choudhary (asechoud) <asechoud@cisco.com>
Subject: Re: [yang-doctors] question regarding conditional/optional statements

On Thu, Aug 17, 2017 at 11:17 AM, Kent Watsen <kwatsen@juniper.net<mailto:kwatsen@juniper.net>> wrote:

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

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?

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)

Kent

Andy

_______________________________________________
yang-doctors mailing list
yang-doctors@ietf.org<mailto:yang-doctors@ietf.org>
https://www.ietf.org/mailman/listinfo/yang-doctors