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

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