Re: [netmod] upcoming adoptions

[Juergen Schoenwaelder <[e-mail]>]

On Fri, Sep 08, 2017 at 02:41:43PM +0100, Robert Wilton wrote:
> 
> 
> On 08/09/2017 13:38, Juergen Schoenwaelder wrote:
> > On Fri, Sep 08, 2017 at 01:19:03PM +0100, Robert Wilton wrote:
> > > In the same vane, I think that you could regard RFC 6087 and 6087bis as one
> > > long list of CLRs ...
> > > 
> > No. There are guidelines that have a clear technical reason. An example:
> > 
> >     The 'preceding-sibling' and 'following-sibling' axes SHOULD NOT used.
> >     A server is only required to maintain the relative XML document order
> >     of all instances of a particular user-ordered list or leaf-list.
> Yes, but even this rule has problems.  Does this mean an implementation does
> not need to support "preceding-sibling and following-sibling"?  Given this
> is only a "SHOULD NOT", it means that there might be some modules may still
> use them.  Likewise for the rest of the XPath "SHOULD NOT" rules.  Will YANG
> implementations fragment on which subsets of Xpath they regard as sane and
> choose to implement?
> 
> [As an aside: I actually think that it would be better to restrict the usage
> of Xpath to a much smaller subset that makes sense, but that should be done
> in 7950bis rather than 6087bis.]

RFC 7950 allows full xpath, RFC 6087 says some constructs may be
surprising, so be careful. RFC 6087 does not change what RFC 7950
defines. You can be of the opinion that RFC 7950 should be changed but
then this is not something RFC 6087 can do.
 
> Besides, 6087bis has many softer rules as well, a few examples give below
> (I'm not even sure why the last one is a rule).  There don't obviously
> appear to be any technical reasons for any of these, but I don't object to
> any of these since they are provide sensible guidance, or try to encourage
> consistent modelling conventions in IETF YANG models.

[...]

I am not interested to discuss every rule there is. I am sure there are
rules that are debatable endlessly.

> Yes there might, but most likely when someone uses "-state" in the name of a
> container they will be doing the wrong thing, and it may cause them problems
> down the line.

Inferring from the name of an identifier that someone is most likely
doing something wrong scares be a lot. Perhaps I have more trust in
module authors than you do. (And module authors who do things wrong
will most likely not read your collection of CLRs either.)

I step out of this discussion.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <http://www.jacobs-university.de/>