Re: [netmod] two options for removing /foo-state trees?

[Acee Lindem (acee)]

Hi Xufeng, 

I’m hoping all our references to “interface-state-ref” will be in schema
nodes that are themselves being deprecated. Yingzhen is investigating.

Thanks,
Acee 

On 9/8/17, 4:12 PM, "Xufeng Liu"  wrote:

>A consequence of this discussion, I have a question about writing a model
>to augment RFC8022bis or RFC7223bis:
>
>The new augmentation model is NMDA compliant, but also requires immediate
>support for "in use" and "system created" information, as described in
>Sec 1.3 of the guidelines
>(https://tools.ietf.org/html/draft-dsdt-nmda-guidelines-01).
>
>In such a case, the relevant suggestions in the guidelines are:
>
>(b) Write a non-NMDA module that mirror the NMDA module.
>-- This cannot be done because we are augmenting RFC8022bis or
>RFC7233bis, which do not have the non-NMDA modules.
>
>(d) It is RECOMMENDED to augment only the "/foo" hierarchy of the base
>model. Where this recommendation cannot be followed, then any new "state"
>elements SHOULD be included in their own module.
>
>The question is about the (d) above. We seem have to augment the
>deprecated "/foo-state" branch, right? We would also have to use the
>deprecated “interface-state-ref”?
>
>Thanks,
>- Xufeng
>
>> -Original Message-
>> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Kent Watsen
>> Sent: Thursday, September 7, 2017 7:28 PM
>> To: Acee Lindem (acee) ; Lou Berger ;
>> Martin Bjorklund 
>> Cc: netmod@ietf.org
>> Subject: Re: [netmod] two options for removing /foo-state trees?
>> 
>> 
>> >>Does this mean you're okay reposting your ID similar to Martin's?
>> >>I ask as a chair interested in starting the adoption process on these
>> >>nmda-update drafts.
>> >
>> > I would hope this is not a prerequisite? We are evaluating how bad
>> > this will be. I’d ask how many implementations there are of
>>ietf-routing?
>> 
>> Yes, please provide this info when you have it.
>> 
>> 
>> >>> However, what about secondary and tertiary implications of moving to
>> >>> NDMA? If we change a path from “interface-state-ref” to
>>“interface-ref”
>> >>> to reference an interface, I’d hope no one would expect the old
>> >>> statement to be kept around…
>> >>
>> >>But the old statement would be kept around, in its deprecated form.
>> >>Of course, the nmda-guidelines should cause those downstream modules
>> >>to be updated to NMDA as well, so hopefully just a short-lived issue.
>> >
>> > This could be really ugly and cascade if we are just using a different
>> > path for a reference. Hopefully, all the old references are in
>> > deprecated trees. Otherwise, I guess the new data leaf would need a
>>unique
>> name.
>> 
>> Indeed.  Let's see what the analysis reveals.
>> 
>> Kent
>> 
>> 
>> 
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] two options for removing /foo-state trees?

[Xufeng Liu]

A consequence of this discussion, I have a question about writing a model to 
augment RFC8022bis or RFC7223bis:

The new augmentation model is NMDA compliant, but also requires immediate 
support for "in use" and "system created" information, as described in Sec 1.3 
of the guidelines (https://tools.ietf.org/html/draft-dsdt-nmda-guidelines-01). 

In such a case, the relevant suggestions in the guidelines are:

(b) Write a non-NMDA module that mirror the NMDA module. 
-- This cannot be done because we are augmenting RFC8022bis or RFC7233bis, 
which do not have the non-NMDA modules.

(d) It is RECOMMENDED to augment only the "/foo" hierarchy of the base model. 
Where this recommendation cannot be followed, then any new "state" elements 
SHOULD be included in their own module.

The question is about the (d) above. We seem have to augment the deprecated 
"/foo-state" branch, right? We would also have to use the deprecated 
“interface-state-ref”? 

Thanks,
- Xufeng

> -Original Message-
> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Kent Watsen
> Sent: Thursday, September 7, 2017 7:28 PM
> To: Acee Lindem (acee) ; Lou Berger ;
> Martin Bjorklund 
> Cc: netmod@ietf.org
> Subject: Re: [netmod] two options for removing /foo-state trees?
> 
> 
> >>Does this mean you're okay reposting your ID similar to Martin's?
> >>I ask as a chair interested in starting the adoption process on these
> >>nmda-update drafts.
> >
> > I would hope this is not a prerequisite? We are evaluating how bad
> > this will be. I’d ask how many implementations there are of ietf-routing?
> 
> Yes, please provide this info when you have it.
> 
> 
> >>> However, what about secondary and tertiary implications of moving to
> >>> NDMA? If we change a path from “interface-state-ref” to “interface-ref”
> >>> to reference an interface, I’d hope no one would expect the old
> >>> statement to be kept around…
> >>
> >>But the old statement would be kept around, in its deprecated form.
> >>Of course, the nmda-guidelines should cause those downstream modules
> >>to be updated to NMDA as well, so hopefully just a short-lived issue.
> >
> > This could be really ugly and cascade if we are just using a different
> > path for a reference. Hopefully, all the old references are in
> > deprecated trees. Otherwise, I guess the new data leaf would need a unique
> name.
> 
> Indeed.  Let's see what the analysis reveals.
> 
> Kent
> 
> 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] I-D Action: draft-ietf-netmod-syslog-model-17.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Modeling WG of the IETF.

Title   : A YANG Data Model for Syslog Configuration
Authors : Clyde Wildes
  Kiran Koushik
Filename: draft-ietf-netmod-syslog-model-17.txt
Pages   : 33
Date: 2017-09-08

Abstract:
   This document defines a YANG data model for the configuration of a
   syslog process.  It is intended this model be used by vendors who
   implement syslog in their systems.

Editorial Note (To be removed by RFC Editor)

   This draft contains many placeholder values that need to be replaced
   with finalized values at the time of publication.  This note
   summarizes all of the substitutions that are needed.  No other RFC
   Editor instructions are specified elsewhere in this document.

   Artwork in this document contains shorthand references to drafts in
   progress.  Please apply the following replacements:

   o  "" --> the assigned RFC value for draft-ietf-netconf-keystore


   o  "" --> the assigned RFC value for draft-ietf-netconf-tls-
  client-server


   o  "" --> the assigned RFC value for this draft



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-17
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-syslog-model-17

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-syslog-model-17


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] I-D Action: draft-ietf-netmod-rfc6087bis-14.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Modeling WG of the IETF.

Title   : Guidelines for Authors and Reviewers of YANG Data 
Model Documents
Author  : Andy Bierman
Filename: draft-ietf-netmod-rfc6087bis-14.txt
Pages   : 70
Date: 2017-09-08

Abstract:
   This memo provides guidelines for authors and reviewers of Standards
   Track specifications containing YANG data model modules.  Applicable
   portions may be used as a basis for reviews of other YANG data model
   documents.  Recommendations and procedures are defined, which are
   intended to increase interoperability and usability of Network
   Configuration Protocol (NETCONF) and RESTCONF protocol
   implementations that utilize YANG data model modules.  This document
   obsoletes RFC 6087.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6087bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-14
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc6087bis-14

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6087bis-14


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] upcoming adoptions

[Andy Bierman]

Hi,

There are many YANG guidelines that are for promoting a consistent structure
for all IETF modules.  YANG is just more source code.  Each organization
can have
different coding guidelines, yet they can all use the same compiler.

I should explain the use-case for identifying NMDA vs. NMDA-transition
modules.
I do not want to present both types (for a given module) to the user.
So the tools need to know in "NMDA mode" which modules are duplicates
for NMDA-transition purpose only, so those modules can be hidden from the
user.
In "legacy mode" the NMDA modules would be hidden and the transition modules
would be exposed to the user instead.

Guessing which is which will only cause unhappy customers so we will force
vendors to tag the modules with our own YANG extensions to tell them apart.

Andy


On Fri, Sep 8, 2017 at 6:41 AM, 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.]
>
> 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.
>
> 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
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] upcoming adoptions

[Robert Wilton]

Pulling out this particular question to see if others have an opinion on 
this.


Should we change 6087bis to reduce it reliance on RFC 2119 language?

The reasoning for proposing this change is to avoid accidentally 
creating future CLRs, because tool implementations might regard the RFC 
2119 language in 6087bis as defining rules rather than just offering 
guidance.


An example change:

Before:

   Prefix values SHOULD be short, but also likely to be unique.  Prefix
   values SHOULD NOT conflict with known modules that have been
   previously published.

After:

   Prefix values should be short, but also likely to be unique.  Prefix
   values SHOULD NOT conflict with known modules that have been
   previously published.


Thanks,
Rob


On 08/09/2017 15:23, Ladislav Lhotka wrote:

Robert Wilton píše v Pá 08. 09. 2017 v 14:41 +0100:


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



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines

[Lou Berger]

Kent and I discussed this.  We (as chairs) don't think there is
currently WG consensus on RegEx guidelines.  We do think there is
sufficient interest to continue the discussion, and would like to do so
both on list and in our next meeting in Singapore.

Thank you,

Lou and Kent

On 9/6/2017 1:01 PM, Lou Berger wrote:
> Thanks Rob.  I'll get with Kent and  then one of us will get back to the wg 
> on next steps.
>
> Lou
>
>
> On September 6, 2017 3:53:33 AM Robert Wilton  wrote:
>
>> Hi Lou,
>>
>> This is the addition to 6087bis that I propose.   Note, this is the same
>> text in my email on the 31st of August.
>>
>> I propose adding the following 2 paragraphs to 6087bis section on
>> pattern and ranges:
>>
>> NEW:
>> To ensure patterns are easy to read and implement, authors SHOULD
>> restrict themselves to the parts of the XML schema regular expression
>> language that are common across most regular expression languages.  In
>> particular, pattern statements SHOULD avoid using 'character class
>> subtraction' (e.g. '[a-z-[aeiou]]').  They SHOULD avoid matching
>> unicode properties and blocks (e.g. '\p{L} or \p{IsBasic_Latin}').
>> They MAY use the '\d', '\w', '\s' character class shorthands and their
>> negated versions, where appropriate, but SHOULD avoid other character
>> class shorthands.  To match ASCII digits 0-9 the character class
>> '[0-9]' MUST be used instead of the '\d' character class shorthand
>> that matches Unicode digits in all scripts.
>>
>> Pattern statements do not have to strictly restrict numerical values,
>> and a simple less specific pattern may be preferable over a more
>> complex and precise pattern, e.g. as illustrated in the
>> 'ipv4-address-no-zone' example pattern below.
>>
>>
>> Or, put in context of the existing text 6087bis text:
>>
>> *** Patterns and Ranges
>>
>> For string data types, if a machine-readable pattern
>> can be defined for the desired semantics, then
>> one or more pattern statements SHOULD be present.
>> A single quoted string SHOULD be used to specify the pattern,
>> since a double-quoted string can modify the content.
>>
>> To ensure patterns are easy to read and implement, authors SHOULD
>> restrict themselves to the parts of the XML schema regular expression
>> language that are common across most regular expression languages.  In
>> particular, pattern statements SHOULD avoid using 'character class
>> subtraction' (e.g. '[a-z-[aeiou]]').  They SHOULD avoid matching
>> unicode properties and blocks (e.g. '\p{L} or \p{IsBasic_Latin}').
>> They MAY use the '\d', '\w', '\s' character class shorthands and their
>> negated versions, where appropriate, but SHOULD avoid other character
>> class shorthands.  To match ASCII digits 0-9 the character class
>> '[0-9]' MUST be used instead of the '\d' character class shorthand
>> that also matches Unicode digits in all scripts.
>>
>> Pattern statements do not have to strictly restrict numerical values,
>> and a simple less specific pattern may be preferable over a more
>> complex and precise pattern, e.g. as illustrated in the
>> 'ipv4-address-no-zone' example pattern below.
>>
>> The following typedef from ^RFC6991^ demonstrates the proper
>> use of the "pattern" statement:
>>
>>      typedef ipv4-address-no-zone {
>>    type inet:ipv4-address {
>>      pattern '[0-9\.]*';
>>    }
>>    ...
>>      }
>>
>> For string data types, if the length of the string
>> is required to be bounded in all implementations,
>> then a length statement MUST be present.
>>
>> The following typedef from ^RFC6991^ demonstrates the proper
>> use of the "length" statement:
>>
>>      typedef yang-identifier {
>>    type string {
>>      length "1..max";
>>      pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*';
>>      pattern '.|..|[^xX].*|.[^mM].*|..[^lL].*';
>>    }
>>    ...
>>      }
>>
>> For numeric data types, if the values allowed
>> by the intended semantics are different than
>> those allowed by the unbounded intrinsic data
>> type (e.g., 'int32'), then a range statement SHOULD be present.
>>
>> The following typedef from ^RFC6991^ demonstrates the proper
>> use of the "range" statement:
>>
>>      typedef dscp {
>>    type uint8 {
>>   range "0..63";
>>    }
>>    ...
>>      }
>>
>> Thanks,
>> Rob
>>
>>
>> On 05/09/2017 22:37, Lou Berger wrote:
>>> Rob,
>>>
>>> (as chair)
>>> On 9/5/2017 1:17 PM, Robert Wilton wrote:
 However, I have thrown in the towel on my regex crusade.
>>> I'm sorry, I've lost the thread here a bit. in order to guage consensus
>>> on this topic, it would be helpful to send the latest text that you are
>>> proposing for inclusion in the the bis.  If you are willing to do these,
>>> we can poll to see if there is/is not support for inclusion of this
>>> text.  Are you willing, i.e., can you send the current proposed text change?
>>>
>>> Thank you,
>>> Lou
>>>
>>> .
>>>
>>

___
netmod mailing list
netmod@ietf.or

Re: [netmod] upcoming adoptions

[Juergen Schoenwaelder]

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: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] upcoming adoptions

[Ladislav Lhotka]

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
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] upcoming adoptions

[Robert Wilton]

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


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.


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
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] upcoming adoptions

[Juergen Schoenwaelder]

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.

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.

I do not want rules that say '-state' should not be used. There may
be valid reasons to use '-state'.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] upcoming adoptions

[Andy Bierman]

On Fri, Sep 8, 2017 at 3:56 AM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Fri, Sep 08, 2017 at 11:17:10AM +0100, Robert Wilton wrote:
> >
> >
> > On 07/09/2017 22:23, Juergen Schoenwaelder wrote:
> > > On Thu, Sep 07, 2017 at 10:51:54AM -0700, Andy Bierman wrote:
> > > > I suggested the naming guideline because the NMDA design team
> decided to
> > > > add semantics to certain naming patterns, so authors have to be
> warned.
> > > >
> > > > But this is a really bad idea (and slippery slope).
> > > I agree.
> > I think that there are really a few aspects to this:
> >
>
> [...]
>
> CLRs are always created with the best intention but then they become
> over time a problem. There is quite some experience with this.
>
>
yes -- naming conventions are fine but they cannot be used by automation
tools.
The YANG language says these strings have no meaning so tools cannot count
on them to have any meaning.

The issue here is whether there are standard extensions to tag YANG modules
or whether each tool vendor will have their own extensions instead.
It is not critical that the IETF provide these YANG extensions, but they
will get used one way or another.

CLRs always start out as clever little rules. They usually turn to
something else only
after some time.

/js
>
>
Andy


> --
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] upcoming adoptions

[Robert Wilton]

On 08/09/2017 11:56, Juergen Schoenwaelder wrote:

On Fri, Sep 08, 2017 at 11:17:10AM +0100, Robert Wilton wrote:


On 07/09/2017 22:23, Juergen Schoenwaelder wrote:

On Thu, Sep 07, 2017 at 10:51:54AM -0700, Andy Bierman wrote:

I suggested the naming guideline because the NMDA design team decided to
add semantics to certain naming patterns, so authors have to be warned.

But this is a really bad idea (and slippery slope).

I agree.

I think that there are really a few aspects to this:


[...]

CLRs are always created with the best intention but then they become
over time a problem. There is quite some experience with this.
In the same vane, I think that you could regard RFC 6087 and 6087bis as 
one long list of CLRs ...


But giving people sensible advice on how to use to produce good YANG 
models generally seems helpful to me.  But with the understanding that 
it is just advice, is not set in stone, and it could reasonably change 
over time.


I actually think that this sort of information (e.g. perhaps the bulk of 
6087 content) may be better on wiki pages, where it is less formal and 
can change in a more fluid way.  Oops! I've just created another CLR ;-)


Thanks,
Rob




/js



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] upcoming adoptions

[Juergen Schoenwaelder]

On Fri, Sep 08, 2017 at 11:17:10AM +0100, Robert Wilton wrote:
> 
> 
> On 07/09/2017 22:23, Juergen Schoenwaelder wrote:
> > On Thu, Sep 07, 2017 at 10:51:54AM -0700, Andy Bierman wrote:
> > > I suggested the naming guideline because the NMDA design team decided to
> > > add semantics to certain naming patterns, so authors have to be warned.
> > > 
> > > But this is a really bad idea (and slippery slope).
> > I agree.
> I think that there are really a few aspects to this:
>

[...]

CLRs are always created with the best intention but then they become
over time a problem. There is quite some experience with this.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] upcoming adoptions

[Robert Wilton]

On 07/09/2017 22:23, Juergen Schoenwaelder wrote:

On Thu, Sep 07, 2017 at 10:51:54AM -0700, Andy Bierman wrote:

I suggested the naming guideline because the NMDA design team decided to
add semantics to certain naming patterns, so authors have to be warned.

But this is a really bad idea (and slippery slope).

I agree.

I think that there are really a few aspects to this:

1)I think that it is a good goal to try and achieve a consistent style 
across the IETF YANG modules.  This helps both readers and 
implementors.  E.g. sticking child "config" and "state" containers in 
the tree in a similar style to OpenConfig may be in-congruent with how 
with how most IETF YANG modules are written.


2) I think that is also some common sense guidance here, which is to 
avoid using node names that may prevent a module for being sensibly 
updated in future.  Hence I think that names that related to the scope 
of the data (e.g. "state", "*-state", "config", and "*-config") should 
generally be avoided, because it is possible that the scope of that data 
may change.  Something that is only operational state in a standard 
model may become configurable by a future revision, or perhaps via 
vendor deviation.


3) The top level "*-state" containers seems to be an undocumented 
historical rule in the context of the pre NMDA IETF YANG modules. Hence, 
advising people not to create top level containers called "-state" also 
seems to help avoid a potential source of confusion.


I don't know if these are necessarily rules, or just common sense. I 
don't know whether this guidance needs to be documented in rfc6087bis.  
My view is that it would probably be helpful.


Thanks,
Rob




/js



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] why is the alarm YANG work being done in CCAMP?

[Kristian Larsson]

I agree, I think this belongs in NETMOD.

I'd also like to say that we, the TeraStream team of Deutsche
Telekom, are currently implementing support for the alarm module.
This work is happening in both our NMS (consisting partly of
Tail-F NCS as well as other components producing / consuming the
alarm module) and in devices, where our home grown lwAFTR will
probably be the first implementation. It's using open source
software in the form of Snabb (https://github.com/snabbco/snabb)
for dataplane and the NETCONF / YANG stack consists of netopeer2
and sysrepo (another open source project we're involved with).

Kind regards,
   Kristian.



On Mon, Jul 17, 2017 at 04:16:16PM +0200, Dan Romascanu wrote:
> Hi,
> 
> I am sorry if I am late to observing this. Please feel free to bash me and
> point to where this discussion already took place. I just heard in the NETMOD
> WG meeting that draft-vallin-netmod-alarm-module is going to be undertaken by
> the CCAMP WG. What is the reason? The problem space of Alarm management data
> model seems IMO pretty generic, and on the other side I cannot see what is
> CCAMP-ish or even RTG Area specific in this work.
> 
> Thanks and Regards,
> 
> Dan
> (one of the authors of RFC 3877)

> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


-- 
Kristian LarssonKLL-RIPE
+46 704 264511k...@spritelink.net

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod