Re: [netmod] upcoming adoptions

[Ladislav Lhotka <[e-mail]>]

Robert Wilton píše v Pá 08. 09. 2017 v 14:41 +0100:
> 
> 
> 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.

In fact, 6087bis has a different text:

   The 'preceding-sibling' and 'following-sibling' axes SHOULD NOT used,
   however they MAY be used if document order is not relevant to the
   outcome of the expression.

The 'preceding-sibling' and 'following-sibling' axes do have their uses,
certainly in user-ordered but also in system-ordered lists.

In contrast, 'preceding' and 'following' are really useless in YANG context. 

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

I think it was a good decision to rely on an existing well-known standard
without making YANG-specific modifications. Tool authors can make certain
assumptions - for example, in my Yangson library 'preceding' and 'following'
axes aren't supported and raise an exception. 

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

Ex1:
 Identifiers SHOULD follow a consistent naming pattern throughout the
   module.  Only lower-case letters, numbers, and dashes SHOULD be used
   in identifier names.

Ex2:
 Definitions for future use SHOULD NOT be specified in a module.

Ex3:
   The signed numeric data types (i.e., 'int8', 'int16', 'int32', and
   'int64') SHOULD NOT be used unless negative values are allowed for
   the desired semantics.


This is very different from guidelines how things should be named that
do not have a real technical reason. In SMIv2 land, we had this weird
rule that names of counters should end with a plural 's' and tools
started to implement this and to complain if there was no plural s.
(Actually, tools checked whether the last character is an s, which of
course does not mean there is a plural form.) And of course, there are
irregular nouns in English wrt. plural forms.
 As per ex1 above, perhaps YANG tools will start to assume that identifiers
cannot contain uppercase characters.

> It might be better if a lot of the guidance in 6087bis is changed to avoid
> using RFC 2119 language precisely so that it can't be subsequently interpreted
> as a formal rule.

I very much agree with this, the use of 2119 keywords sometimes makes things
confusing.

Lada

> 
But I still see guidance on how to consistently name counters and list
elements is good way of helping achieve consistency, and make the models read
better.  This doesn't mean that tools should interpret these as rules.


I do not want rules that say '-state' should not be used. There may
be valid reasons to use '-state'.
 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.  Warning them of the potential problems now so that they make
an informed decision seems generally helpful to humanity.  This does not mean
that it needs to be a rule, or is even allowed to be interpreted as such.

Thanks,
Rob

/js

 
_______________________________________________
netmod mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67