Re: [netmod] RFC 2119 language [was Re: WG Last Call: draft-ietf-netmod-revised-datastores-04 updates]

[Lou Berger]

Juergen,

Thanks for the "interesting" discussion.  I really do appreciate the authors 
adding the 2119 language even though they are unconvinced of it's value.  

Lou

On 9/27/2017 6:03 PM, Juergen Schoenwaelder wrote:
> Lou,
>
> I do not have statistics, just some RFC text:
>
> - RFC 8174 section 2 first bullet in the === NEW === text says "These
>   words can be used as defined here, but using them is not required.
>   Specifically, normative text does not require the use of these key
>   words.  They are used for clarity and consistency when that is
>   what's wanted, but a lot of normative text does not use them and is
>   still normative."
>
> - I can also point to RFC 2119 section 6 which says "they MUST only be
>   used where it is actually required for interoperation or to limit
>   behavior which has potential for causing harm (e.g., limiting
>   retransmisssions)".
>
> /js
>
> On Wed, Sep 27, 2017 at 05:50:30PM -0400, Lou Berger wrote:
>> Juergen,
>>
>> I guess our experiences at the IETF differ.  Certainly RFCs I authored
>> prior to 2219 (being published) were loose in their use of
>> capitalization and, frankly, sometimes open to interpretation as to what
>> was normative and what was informative.  But soon very soon after, most
>> of us switched over to citing RFC2119 and using its language to
>> distinguish between the two -- and I think this truly helped readers and
>> implementers know what they had to do to conform with and what they
>> didn't to ensure interoperable implementations. I'm really not sure  how
>> 20 years later, the use of RFC2119 to identify normative language can be
>> considered anything but the norm, let alone a proposed 'new norm'.
>>
>> FWIW of the 3198 RFCs with a 'standards'  category published after
>> RFC2119, 1995 reference RFC2119.  In the last 5 years the numbers are
>> 961 and 892 respectively.
>>
>> Lou
>>
>>
>> On 9/27/2017 4:41 PM, Juergen Schoenwaelder wrote:
>>> Lou,
>>>
>>> text is normative without RFC 2119 language. There clearly is no such
>>> 'norm' unless people try to make it a new norm and I am strictly
>>> opposed to that. If the reason to add RFC 2119 language is to comply
>>> to a new norm being created, I have to object. If you want such a norm
>>> to be created, write an I-D and run it through the process.
>>>
>>> /js
>>>
>>> PS: Sorry co-authors I promised to be silent but somehow I can't let
>>> this reasoning go without seriously questioning it.
>>>
>>> On Wed, Sep 27, 2017 at 01:20:13PM -0400, Lou Berger wrote:
 I think this goes to if this, or any, draft is a proposed standard or
 not. In other words, if it specifies any behavior that for which
 interoperability between independent implementations is the objective. 
 My general view is that in a Proposed Standard RFC, if it impacts
 interoperability, the text should be normative and an RFC should use
 2119 language to identify such normative text.  I accept that this is
 not strictly required by IETF process, but it has become the norm for PS
 track RFCs produced today  -- and I see no reason to not follow IETF norm.

 In the context of this draft , as I read it, at least section 5.1 and
 some portions of 4.

 Lou

 On 9/27/2017 12:28 PM, Robert Wilton wrote:
> The authors discussed this, and we will close this issue
> (https://github.com/netmod-wg/datastore-dt/issues/14 - title: Does the
> NMDA architecture need to use RFC 2119 language?) by adding RFC 2119
> text to the document, which will probably be best illustrated with an
> updated draft revision.
>
> For the record, the majority of the authors had the view that RFC 2119
> language does not particularly aid readability in this architecture
> document.
>
> Thanks,
> Rob
>
>
> On 16/09/2017 10:56, Andy Bierman wrote:
>> On Sat, Sep 16, 2017 at 12:24 AM, Juergen Schoenwaelder
>> > > wrote:
>>
>> On Fri, Sep 15, 2017 at 02:07:58PM -0700, Andy Bierman wrote:
>> > Hi,
>> >
>> > I strongly agree with Tom that the current draft is an update
>> to RFC 7950.
>> > I also strongly disagree with the decision to omit RFC 2119 in
>> a standards
>> > track document. IMO RFC 2119 terms need to be used in normative
>> text,
>> > especially when dealing with XPath and YANG compiler behavior.
>> >
>>
>> RFC 8174:
>>
>>    o  These words can be used as defined here, but using them is not
>>       required.  Specifically, normative text does not require
>> the use
>>       of these key words.  They are used for clarity and consistency
>>       when that is what's wanted, but a lot of normative text
>> does not
>>       use them and is still normative.
>>
>>
>> 

Re: [netmod] RFC 2119 language [was Re: WG Last Call: draft-ietf-netmod-revised-datastores-04 updates]

[Juergen Schoenwaelder]

Lou,

I do not have statistics, just some RFC text:

- RFC 8174 section 2 first bullet in the === NEW === text says "These
  words can be used as defined here, but using them is not required.
  Specifically, normative text does not require the use of these key
  words.  They are used for clarity and consistency when that is
  what's wanted, but a lot of normative text does not use them and is
  still normative."

- I can also point to RFC 2119 section 6 which says "they MUST only be
  used where it is actually required for interoperation or to limit
  behavior which has potential for causing harm (e.g., limiting
  retransmisssions)".

/js

On Wed, Sep 27, 2017 at 05:50:30PM -0400, Lou Berger wrote:
> Juergen,
> 
> I guess our experiences at the IETF differ.  Certainly RFCs I authored
> prior to 2219 (being published) were loose in their use of
> capitalization and, frankly, sometimes open to interpretation as to what
> was normative and what was informative.  But soon very soon after, most
> of us switched over to citing RFC2119 and using its language to
> distinguish between the two -- and I think this truly helped readers and
> implementers know what they had to do to conform with and what they
> didn't to ensure interoperable implementations. I'm really not sure  how
> 20 years later, the use of RFC2119 to identify normative language can be
> considered anything but the norm, let alone a proposed 'new norm'.
> 
> FWIW of the 3198 RFCs with a 'standards'  category published after
> RFC2119, 1995 reference RFC2119.  In the last 5 years the numbers are
> 961 and 892 respectively.
> 
> Lou
> 
> 
> On 9/27/2017 4:41 PM, Juergen Schoenwaelder wrote:
> > Lou,
> >
> > text is normative without RFC 2119 language. There clearly is no such
> > 'norm' unless people try to make it a new norm and I am strictly
> > opposed to that. If the reason to add RFC 2119 language is to comply
> > to a new norm being created, I have to object. If you want such a norm
> > to be created, write an I-D and run it through the process.
> >
> > /js
> >
> > PS: Sorry co-authors I promised to be silent but somehow I can't let
> > this reasoning go without seriously questioning it.
> >
> > On Wed, Sep 27, 2017 at 01:20:13PM -0400, Lou Berger wrote:
> >> I think this goes to if this, or any, draft is a proposed standard or
> >> not. In other words, if it specifies any behavior that for which
> >> interoperability between independent implementations is the objective. 
> >> My general view is that in a Proposed Standard RFC, if it impacts
> >> interoperability, the text should be normative and an RFC should use
> >> 2119 language to identify such normative text.  I accept that this is
> >> not strictly required by IETF process, but it has become the norm for PS
> >> track RFCs produced today  -- and I see no reason to not follow IETF norm.
> >>
> >> In the context of this draft , as I read it, at least section 5.1 and
> >> some portions of 4.
> >>
> >> Lou
> >>
> >> On 9/27/2017 12:28 PM, Robert Wilton wrote:
> >>> The authors discussed this, and we will close this issue
> >>> (https://github.com/netmod-wg/datastore-dt/issues/14 - title: Does the
> >>> NMDA architecture need to use RFC 2119 language?) by adding RFC 2119
> >>> text to the document, which will probably be best illustrated with an
> >>> updated draft revision.
> >>>
> >>> For the record, the majority of the authors had the view that RFC 2119
> >>> language does not particularly aid readability in this architecture
> >>> document.
> >>>
> >>> Thanks,
> >>> Rob
> >>>
> >>>
> >>> On 16/09/2017 10:56, Andy Bierman wrote:
> 
>  On Sat, Sep 16, 2017 at 12:24 AM, Juergen Schoenwaelder
>    > wrote:
> 
>  On Fri, Sep 15, 2017 at 02:07:58PM -0700, Andy Bierman wrote:
>  > Hi,
>  >
>  > I strongly agree with Tom that the current draft is an update
>  to RFC 7950.
>  > I also strongly disagree with the decision to omit RFC 2119 in
>  a standards
>  > track document. IMO RFC 2119 terms need to be used in normative
>  text,
>  > especially when dealing with XPath and YANG compiler behavior.
>  >
> 
>  RFC 8174:
> 
>     o  These words can be used as defined here, but using them is not
>        required.  Specifically, normative text does not require
>  the use
>        of these key words.  They are used for clarity and consistency
>        when that is what's wanted, but a lot of normative text
>  does not
>        use them and is still normative.
> 
> 
>  So what?
>  Existing YANG specifications use RFC 2119 terms.
>  This draft uses those terms, just with lower-case.
>  Either way, the new YANG rules seem half-baked and not ready
>  for standardization.
> 
>   
> 
>  /js
> 

Re: [netmod] RFC 2119 language [was Re: WG Last Call: draft-ietf-netmod-revised-datastores-04 updates]

[Lou Berger]

Juergen,

I guess our experiences at the IETF differ.  Certainly RFCs I authored
prior to 2219 (being published) were loose in their use of
capitalization and, frankly, sometimes open to interpretation as to what
was normative and what was informative.  But soon very soon after, most
of us switched over to citing RFC2119 and using its language to
distinguish between the two -- and I think this truly helped readers and
implementers know what they had to do to conform with and what they
didn't to ensure interoperable implementations. I'm really not sure  how
20 years later, the use of RFC2119 to identify normative language can be
considered anything but the norm, let alone a proposed 'new norm'.

FWIW of the 3198 RFCs with a 'standards'  category published after
RFC2119, 1995 reference RFC2119.  In the last 5 years the numbers are
961 and 892 respectively.

Lou


On 9/27/2017 4:41 PM, Juergen Schoenwaelder wrote:
> Lou,
>
> text is normative without RFC 2119 language. There clearly is no such
> 'norm' unless people try to make it a new norm and I am strictly
> opposed to that. If the reason to add RFC 2119 language is to comply
> to a new norm being created, I have to object. If you want such a norm
> to be created, write an I-D and run it through the process.
>
> /js
>
> PS: Sorry co-authors I promised to be silent but somehow I can't let
> this reasoning go without seriously questioning it.
>
> On Wed, Sep 27, 2017 at 01:20:13PM -0400, Lou Berger wrote:
>> I think this goes to if this, or any, draft is a proposed standard or
>> not. In other words, if it specifies any behavior that for which
>> interoperability between independent implementations is the objective. 
>> My general view is that in a Proposed Standard RFC, if it impacts
>> interoperability, the text should be normative and an RFC should use
>> 2119 language to identify such normative text.  I accept that this is
>> not strictly required by IETF process, but it has become the norm for PS
>> track RFCs produced today  -- and I see no reason to not follow IETF norm.
>>
>> In the context of this draft , as I read it, at least section 5.1 and
>> some portions of 4.
>>
>> Lou
>>
>> On 9/27/2017 12:28 PM, Robert Wilton wrote:
>>> The authors discussed this, and we will close this issue
>>> (https://github.com/netmod-wg/datastore-dt/issues/14 - title: Does the
>>> NMDA architecture need to use RFC 2119 language?) by adding RFC 2119
>>> text to the document, which will probably be best illustrated with an
>>> updated draft revision.
>>>
>>> For the record, the majority of the authors had the view that RFC 2119
>>> language does not particularly aid readability in this architecture
>>> document.
>>>
>>> Thanks,
>>> Rob
>>>
>>>
>>> On 16/09/2017 10:56, Andy Bierman wrote:

 On Sat, Sep 16, 2017 at 12:24 AM, Juergen Schoenwaelder
 > wrote:

 On Fri, Sep 15, 2017 at 02:07:58PM -0700, Andy Bierman wrote:
 > Hi,
 >
 > I strongly agree with Tom that the current draft is an update
 to RFC 7950.
 > I also strongly disagree with the decision to omit RFC 2119 in
 a standards
 > track document. IMO RFC 2119 terms need to be used in normative
 text,
 > especially when dealing with XPath and YANG compiler behavior.
 >

 RFC 8174:

    o  These words can be used as defined here, but using them is not
       required.  Specifically, normative text does not require
 the use
       of these key words.  They are used for clarity and consistency
       when that is what's wanted, but a lot of normative text
 does not
       use them and is still normative.


 So what?
 Existing YANG specifications use RFC 2119 terms.
 This draft uses those terms, just with lower-case.
 Either way, the new YANG rules seem half-baked and not ready
 for standardization.

  

 /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

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

Re: [netmod] RFC 2119 language [was Re: WG Last Call: draft-ietf-netmod-revised-datastores-04 updates]

[Andy Bierman]

Hi,

I do not want to generate more process so I will drop the issue,
but the fact that this draft updates RFC 7950 instead of RFC 6244
indicates the problems with it are way beyond using capital letters for a
few words.


Andy


On Wed, Sep 27, 2017 at 1:41 PM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> Lou,
>
> text is normative without RFC 2119 language. There clearly is no such
> 'norm' unless people try to make it a new norm and I am strictly
> opposed to that. If the reason to add RFC 2119 language is to comply
> to a new norm being created, I have to object. If you want such a norm
> to be created, write an I-D and run it through the process.
>
> /js
>
> PS: Sorry co-authors I promised to be silent but somehow I can't let
> this reasoning go without seriously questioning it.
>
> On Wed, Sep 27, 2017 at 01:20:13PM -0400, Lou Berger wrote:
> > I think this goes to if this, or any, draft is a proposed standard or
> > not. In other words, if it specifies any behavior that for which
> > interoperability between independent implementations is the objective.
> > My general view is that in a Proposed Standard RFC, if it impacts
> > interoperability, the text should be normative and an RFC should use
> > 2119 language to identify such normative text.  I accept that this is
> > not strictly required by IETF process, but it has become the norm for PS
> > track RFCs produced today  -- and I see no reason to not follow IETF
> norm.
> >
> > In the context of this draft , as I read it, at least section 5.1 and
> > some portions of 4.
> >
> > Lou
> >
> > On 9/27/2017 12:28 PM, Robert Wilton wrote:
> > >
> > > The authors discussed this, and we will close this issue
> > > (https://github.com/netmod-wg/datastore-dt/issues/14 - title: Does the
> > > NMDA architecture need to use RFC 2119 language?) by adding RFC 2119
> > > text to the document, which will probably be best illustrated with an
> > > updated draft revision.
> > >
> > > For the record, the majority of the authors had the view that RFC 2119
> > > language does not particularly aid readability in this architecture
> > > document.
> > >
> > > Thanks,
> > > Rob
> > >
> > >
> > > On 16/09/2017 10:56, Andy Bierman wrote:
> > >>
> > >>
> > >> On Sat, Sep 16, 2017 at 12:24 AM, Juergen Schoenwaelder
> > >>  > >> > wrote:
> > >>
> > >> On Fri, Sep 15, 2017 at 02:07:58PM -0700, Andy Bierman wrote:
> > >> > Hi,
> > >> >
> > >> > I strongly agree with Tom that the current draft is an update
> > >> to RFC 7950.
> > >> > I also strongly disagree with the decision to omit RFC 2119 in
> > >> a standards
> > >> > track document. IMO RFC 2119 terms need to be used in normative
> > >> text,
> > >> > especially when dealing with XPath and YANG compiler behavior.
> > >> >
> > >>
> > >> RFC 8174:
> > >>
> > >>o  These words can be used as defined here, but using them is
> not
> > >>   required.  Specifically, normative text does not require
> > >> the use
> > >>   of these key words.  They are used for clarity and
> consistency
> > >>   when that is what's wanted, but a lot of normative text
> > >> does not
> > >>   use them and is still normative.
> > >>
> > >>
> > >> So what?
> > >> Existing YANG specifications use RFC 2119 terms.
> > >> This draft uses those terms, just with lower-case.
> > >> Either way, the new YANG rules seem half-baked and not ready
> > >> for standardization.
> > >>
> > >>
> > >>
> > >> /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
> >
>
> --
> 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
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] RFC 2119 language [was Re: WG Last Call: draft-ietf-netmod-revised-datastores-04 updates]

[Juergen Schoenwaelder]

On Wed, Sep 27, 2017 at 01:56:10PM -0700, Andy Bierman wrote:
> Hi,
> 
> 
> 
> On Wed, Sep 27, 2017 at 1:41 PM, Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
> 
> > Lou,
> >
> > text is normative without RFC 2119 language. There clearly is no such
> > 'norm' unless people try to make it a new norm and I am strictly
> > opposed to that. If the reason to add RFC 2119 language is to comply
> > to a new norm being created, I have to object. If you want such a norm
> > to be created, write an I-D and run it through the process.
> 
> It is quite common for Standards Track documents to use RFC 2119 terms.
> The only new norm being set here is that the RD draft mixes architecture and
> normative YANG/protocol behavior together.

The idea that normative text requires RFC 2119 words is wrong.
 
> If this was an Informational RFC that just discussed architecture,
> then I would agree the RFC 2119 terms are not needed.

If the only reason to add RFC 2119 language is to comply to an
unwritten norm, then I am questioning adding RFC 2119 language. There
needs to be a bit more logic and reasoning for each decision whether a
must or MUST or a should or a SHOULD is appropriate.

/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] RFC 2119 language [was Re: WG Last Call: draft-ietf-netmod-revised-datastores-04 updates]

[Andy Bierman]

Hi,



On Wed, Sep 27, 2017 at 1:41 PM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> Lou,
>
> text is normative without RFC 2119 language. There clearly is no such
> 'norm' unless people try to make it a new norm and I am strictly
> opposed to that. If the reason to add RFC 2119 language is to comply
> to a new norm being created, I have to object. If you want such a norm
> to be created, write an I-D and run it through the process.
>
>

It is quite common for Standards Track documents to use RFC 2119 terms.
The only new norm being set here is that the RD draft mixes architecture and
normative YANG/protocol behavior together.

If this was an Informational RFC that just discussed architecture,
then I would agree the RFC 2119 terms are not needed.



> /js
>
>
Andy



> PS: Sorry co-authors I promised to be silent but somehow I can't let
> this reasoning go without seriously questioning it.
>
> On Wed, Sep 27, 2017 at 01:20:13PM -0400, Lou Berger wrote:
> > I think this goes to if this, or any, draft is a proposed standard or
> > not. In other words, if it specifies any behavior that for which
> > interoperability between independent implementations is the objective.
> > My general view is that in a Proposed Standard RFC, if it impacts
> > interoperability, the text should be normative and an RFC should use
> > 2119 language to identify such normative text.  I accept that this is
> > not strictly required by IETF process, but it has become the norm for PS
> > track RFCs produced today  -- and I see no reason to not follow IETF
> norm.
> >
> > In the context of this draft , as I read it, at least section 5.1 and
> > some portions of 4.
> >
> > Lou
> >
> > On 9/27/2017 12:28 PM, Robert Wilton wrote:
> > >
> > > The authors discussed this, and we will close this issue
> > > (https://github.com/netmod-wg/datastore-dt/issues/14 - title: Does the
> > > NMDA architecture need to use RFC 2119 language?) by adding RFC 2119
> > > text to the document, which will probably be best illustrated with an
> > > updated draft revision.
> > >
> > > For the record, the majority of the authors had the view that RFC 2119
> > > language does not particularly aid readability in this architecture
> > > document.
> > >
> > > Thanks,
> > > Rob
> > >
> > >
> > > On 16/09/2017 10:56, Andy Bierman wrote:
> > >>
> > >>
> > >> On Sat, Sep 16, 2017 at 12:24 AM, Juergen Schoenwaelder
> > >>  > >> > wrote:
> > >>
> > >> On Fri, Sep 15, 2017 at 02:07:58PM -0700, Andy Bierman wrote:
> > >> > Hi,
> > >> >
> > >> > I strongly agree with Tom that the current draft is an update
> > >> to RFC 7950.
> > >> > I also strongly disagree with the decision to omit RFC 2119 in
> > >> a standards
> > >> > track document. IMO RFC 2119 terms need to be used in normative
> > >> text,
> > >> > especially when dealing with XPath and YANG compiler behavior.
> > >> >
> > >>
> > >> RFC 8174:
> > >>
> > >>o  These words can be used as defined here, but using them is
> not
> > >>   required.  Specifically, normative text does not require
> > >> the use
> > >>   of these key words.  They are used for clarity and
> consistency
> > >>   when that is what's wanted, but a lot of normative text
> > >> does not
> > >>   use them and is still normative.
> > >>
> > >>
> > >> So what?
> > >> Existing YANG specifications use RFC 2119 terms.
> > >> This draft uses those terms, just with lower-case.
> > >> Either way, the new YANG rules seem half-baked and not ready
> > >> for standardization.
> > >>
> > >>
> > >>
> > >> /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
> >
>
> --
> 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
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] RFC 2119 language [was Re: WG Last Call: draft-ietf-netmod-revised-datastores-04 updates]

[Juergen Schoenwaelder]

Lou,

text is normative without RFC 2119 language. There clearly is no such
'norm' unless people try to make it a new norm and I am strictly
opposed to that. If the reason to add RFC 2119 language is to comply
to a new norm being created, I have to object. If you want such a norm
to be created, write an I-D and run it through the process.

/js

PS: Sorry co-authors I promised to be silent but somehow I can't let
this reasoning go without seriously questioning it.

On Wed, Sep 27, 2017 at 01:20:13PM -0400, Lou Berger wrote:
> I think this goes to if this, or any, draft is a proposed standard or
> not. In other words, if it specifies any behavior that for which
> interoperability between independent implementations is the objective. 
> My general view is that in a Proposed Standard RFC, if it impacts
> interoperability, the text should be normative and an RFC should use
> 2119 language to identify such normative text.  I accept that this is
> not strictly required by IETF process, but it has become the norm for PS
> track RFCs produced today  -- and I see no reason to not follow IETF norm.
> 
> In the context of this draft , as I read it, at least section 5.1 and
> some portions of 4.
> 
> Lou
> 
> On 9/27/2017 12:28 PM, Robert Wilton wrote:
> >
> > The authors discussed this, and we will close this issue
> > (https://github.com/netmod-wg/datastore-dt/issues/14 - title: Does the
> > NMDA architecture need to use RFC 2119 language?) by adding RFC 2119
> > text to the document, which will probably be best illustrated with an
> > updated draft revision.
> >
> > For the record, the majority of the authors had the view that RFC 2119
> > language does not particularly aid readability in this architecture
> > document.
> >
> > Thanks,
> > Rob
> >
> >
> > On 16/09/2017 10:56, Andy Bierman wrote:
> >>
> >>
> >> On Sat, Sep 16, 2017 at 12:24 AM, Juergen Schoenwaelder
> >>  >> > wrote:
> >>
> >> On Fri, Sep 15, 2017 at 02:07:58PM -0700, Andy Bierman wrote:
> >> > Hi,
> >> >
> >> > I strongly agree with Tom that the current draft is an update
> >> to RFC 7950.
> >> > I also strongly disagree with the decision to omit RFC 2119 in
> >> a standards
> >> > track document. IMO RFC 2119 terms need to be used in normative
> >> text,
> >> > especially when dealing with XPath and YANG compiler behavior.
> >> >
> >>
> >> RFC 8174:
> >>
> >>    o  These words can be used as defined here, but using them is not
> >>       required.  Specifically, normative text does not require
> >> the use
> >>       of these key words.  They are used for clarity and consistency
> >>       when that is what's wanted, but a lot of normative text
> >> does not
> >>       use them and is still normative.
> >>
> >>
> >> So what?
> >> Existing YANG specifications use RFC 2119 terms.
> >> This draft uses those terms, just with lower-case.
> >> Either way, the new YANG rules seem half-baked and not ready
> >> for standardization.
> >>
> >>  
> >>
> >> /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
> 

-- 
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] I-D Action: draft-ietf-netmod-schema-mount-07.txt

[Martin Bjorklund]

Lou Berger  wrote:
> Hi Martin,
> 
> See below
> 
> On 9/27/2017 6:55 AM, Martin Bjorklund wrote:
> > Hi,
> >
> > This version fixes the XPath context for parent-reference.
> >
> >
> > However, there is one more thing to discuss, which is the term "mount
> > point".  
> >
> > The current text says:
> >
> >- mount point: container or list node whose definition contains
> >  the "mount-point" extension statement. The argument of the
> >  "mount-point" statement defines the name of the mount point.
> >
> >
> > So if we have:
> > 
> >   container top {
> > container root {
> >   yangmnt:mount-point ni;
> > }
> >   }
> > 
> > There is one mount point, the node /top/root, with the name "ni".
> in the NI draft [1] we solve this by keeping the names the same:
> 
>     container vrf-root {
>   description
>     "Container for mount point.";
>   yangmnt:mount-point "vrf-root" {
>     description
>   "Root for L3VPN type models. This will typically
>    not be an inline type mount point.";
>   }
>     }
> 
> [1] https://tools.ietf.org/html/draft-ietf-rtgwg-ni-model-04
> > Pretty confusing...   Does anyone have any comments around this?
> >
> When the NE authors discussed this, we (a) discussed it's not a
> significant impediment or issue worth discussing, and (b) one author
> noted that the flexibility may even be useful down the road.

Yes, I don't want to change any functionality, but perhaps change the
terminology to make it less confusion.

Maybe change the extension to:

  extension mount-point {
argument id; // instead of 'name'
...
  }

So the container "vrf-root" would be a mount point, with id "ni".



/martin




> 
> Thanks,
> Lou
> (As contributor)
>  
> >
> > /martin
> >
> >
> >
> >
> >
> > internet-dra...@ietf.org wrote:
> >> 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   : YANG Schema Mount
> >> Authors : Martin Bjorklund
> >>   Ladislav Lhotka
> >>Filename: draft-ietf-netmod-schema-mount-07.txt
> >>Pages   : 27
> >>Date: 2017-09-27
> >>
> >> Abstract:
> >>This document defines a mechanism to combine YANG modules into the
> >>schema defined in other YANG modules.
> >>
> >>
> >> The IETF datatracker status page for this draft is:
> >> https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/
> >>
> >> There are also htmlized versions available at:
> >> https://tools.ietf.org/html/draft-ietf-netmod-schema-mount-07
> >> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-schema-mount-07
> >>
> >> A diff from the previous version is available at:
> >> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-schema-mount-07
> >>
> >>
> >> 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 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] I-D Action: draft-ietf-netmod-schema-mount-07.txt

[Lou Berger]

Hi Martin,

See below

On 9/27/2017 6:55 AM, Martin Bjorklund wrote:
> Hi,
>
> This version fixes the XPath context for parent-reference.
>
>
> However, there is one more thing to discuss, which is the term "mount
> point".  
>
> The current text says:
>
>- mount point: container or list node whose definition contains
>  the "mount-point" extension statement. The argument of the
>  "mount-point" statement defines the name of the mount point.
>
>
> So if we have:
> 
>   container top {
> container root {
>   yangmnt:mount-point ni;
> }
>   }
> 
> There is one mount point, the node /top/root, with the name "ni".
in the NI draft [1] we solve this by keeping the names the same:

    container vrf-root {
  description
    "Container for mount point.";
  yangmnt:mount-point "vrf-root" {
    description
  "Root for L3VPN type models. This will typically
   not be an inline type mount point.";
  }
    }

[1] https://tools.ietf.org/html/draft-ietf-rtgwg-ni-model-04
> Pretty confusing...   Does anyone have any comments around this?
>
When the NE authors discussed this, we (a) discussed it's not a
significant impediment or issue worth discussing, and (b) one author
noted that the flexibility may even be useful down the road.

Thanks,
Lou
(As contributor)
 
>
> /martin
>
>
>
>
>
> internet-dra...@ietf.org wrote:
>> 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   : YANG Schema Mount
>> Authors : Martin Bjorklund
>>   Ladislav Lhotka
>>  Filename: draft-ietf-netmod-schema-mount-07.txt
>>  Pages   : 27
>>  Date: 2017-09-27
>>
>> Abstract:
>>This document defines a mechanism to combine YANG modules into the
>>schema defined in other YANG modules.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-netmod-schema-mount-07
>> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-schema-mount-07
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-schema-mount-07
>>
>>
>> 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 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] RFC 2119 language

[Martin Bjorklund]

Lou Berger  wrote:
> I think this goes to if this, or any, draft is a proposed standard or
> not. In other words, if it specifies any behavior that for which
> interoperability between independent implementations is the objective. 
> My general view is that in a Proposed Standard RFC, if it impacts
> interoperability, the text should be normative and an RFC should use
> 2119 language to identify such normative text.  I accept that this is
> not strictly required by IETF process, but it has become the norm for PS
> track RFCs produced today  -- and I see no reason to not follow IETF norm.

As Rob wrote, we will add 2119 language to the draft, since that's
seems to be WG consensus.


/martin


> 
> In the context of this draft , as I read it, at least section 5.1 and
> some portions of 4.
> 
> Lou
> 
> On 9/27/2017 12:28 PM, Robert Wilton wrote:
> >
> > The authors discussed this, and we will close this issue
> > (https://github.com/netmod-wg/datastore-dt/issues/14 - title: Does the
> > NMDA architecture need to use RFC 2119 language?) by adding RFC 2119
> > text to the document, which will probably be best illustrated with an
> > updated draft revision.
> >
> > For the record, the majority of the authors had the view that RFC 2119
> > language does not particularly aid readability in this architecture
> > document.
> >
> > Thanks,
> > Rob
> >
> >
> > On 16/09/2017 10:56, Andy Bierman wrote:
> >>
> >>
> >> On Sat, Sep 16, 2017 at 12:24 AM, Juergen Schoenwaelder
> >>  >> > wrote:
> >>
> >> On Fri, Sep 15, 2017 at 02:07:58PM -0700, Andy Bierman wrote:
> >> > Hi,
> >> >
> >> > I strongly agree with Tom that the current draft is an update
> >> to RFC 7950.
> >> > I also strongly disagree with the decision to omit RFC 2119 in
> >> a standards
> >> > track document. IMO RFC 2119 terms need to be used in normative
> >> text,
> >> > especially when dealing with XPath and YANG compiler behavior.
> >> >
> >>
> >> RFC 8174:
> >>
> >>    o  These words can be used as defined here, but using them is not
> >>       required.  Specifically, normative text does not require
> >> the use
> >>       of these key words.  They are used for clarity and consistency
> >>       when that is what's wanted, but a lot of normative text
> >> does not
> >>       use them and is still normative.
> >>
> >>
> >> So what?
> >> Existing YANG specifications use RFC 2119 terms.
> >> This draft uses those terms, just with lower-case.
> >> Either way, the new YANG rules seem half-baked and not ready
> >> for standardization.
> >>
> >>  
> >>
> >> /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
> 
> ___
> 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] syslog-model-17 shepherd writeup issues -references

[Clyde Wildes (cwildes)]

Benoit,

There were approximately 24 changes requested from you, Kent, Robert Wilton, 
and Tom Petch. I have made approximately half of them and will try to finish 
another revision of the draft by Friday.

Thanks,

Clyde

On 9/27/17, 3:24 AM, "Benoit Claise (bclaise)"  wrote:

Clyde,

Do you know your next step to progress this document?

Regards, Benoit
> I meant to say something about the .1 vs .2 difference.  My comment
> assumes that it's supposed to be .1, but we of course should use
> whatever is correct.
>
> I also don't know much about that standards body.
>
> K.
>
>
>
> - Original Message -
> From: "Kent Watsen" 
> Sent: Wednesday, September 13, 2017 6:08 PM
>
>> Hi Tom,
>>
>> Thanks.  The fix I'm looking for is for the 'pattern-match' leaf
>> to have a 'reference' statement to Std-1003.1-2008, and for S4.1
>> to also list Std-1003.1-2008 as a draft-level reference.
> and I am unfamiliar with that standards body so am looking for a little
> more.
>
> Is STD- always Posix or do we need to say Posix 1003 or Posix
> Std-1003 or is Std-1003 completely unrelated to Posix 1003?
>
> Is there a difference between Std-1003.1-2008 and Posix 1003.2 ie is the
> .1 or .2 significant?  You want Std-1003.1; the description contains
> Posix 1003.2; the normative Reference is to Std-1003.1-2008.
>
> You pointed out that the Normative Reference is not used; well if we can
> sort out what the standard is and get the right label in Normative
> References then we can - must - include this in Section 4.1 which will
> resolve that comment of yours.
>
> The discussions last July had Clyde saying he wants Posix 1003.2 so if
> Std-1003 and Posix 1003 are the same but .1 and.2 are different, then
> you are asking for a semantic change against Clyde's wishes.
>
> I hope my confusion is sufficiently clear, at least to Clyde!
>
> Tom Petch
>
>> I was going to point out the typo "the the" as well, but figured
>> that the RFC Editor would get it.
>>
>> K. // shepherd
>>
>>
>> --
>>
>> Kent
>>
>> You flag Std-1003.1-2008 as listed as a normative reference but not
> used
>> anywhere in the document.  In the Descriptions, but not in the s.4.1
>> references, I see
>>
>> This leaf describes a Posix 1003.2 regular expression ...
>>
>> twice, which may, or may not, relate to this issue.
>>
>> Back in July, clyde said
>> "I will insert a normative reference to POSIX 1003.2 in the next
>> revision of the draft."
>>
>> In a similar vein, RFC6991 appears in a reference statement but
> nowhere
>> else.
>>
>> As you point out, RFC6021 is referenced but is obsoleted by RFC6991 so
>> should not be.
>>
>> And in a slightly different vein,
>>
>> registry [RFC7895]/>.  Following the format in [RFC7950]/>, the the
>>
>> looks odd for plain text and for the repetition of 'the'..
>>
>> Tom Petch
>>
>> - Original Message -
>> From: "Kent Watsen" 
>> To: 
>> Cc: 
>> Sent: Tuesday, September 12, 2017 10:50 PM
>> Subject: [netmod] syslog-model-17 shepherd writeup issues
>>
>>
>>> Clyde, all,
>>>
>>> In reviewing the draft for Shepherd writeup, I found the following
>> issues that I think need to be addressed before the document can be
> sent
>> to Benoit for AD review:
>>>
>>> 1. Idnits found the following:
>>>
>>>Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment
>> (--).
>>>  ** There are 2 instances of too long lines in the document, the
>> longest one
>>>   being 3 characters in excess of 72.
>>>
>>>  ** Obsolete normative reference: RFC 6021 (Obsoleted by RFC
> 6991)
>>>  ** Downref: Normative reference to an Historic RFC: RFC 6587
>>>
>>>  == Missing Reference: 'RFC5425' is mentioned on line 359, but
> not
>> defined
>>>   '[RFC5425], [RFC5426], [RFC6587], and [RFC5848]'
>>>
>>>   == Unused Reference: 'RFC7895' is defined on line 1406, but no
>> explicit
>>>reference was found in the text
>>>'[RFC7895]  Bierman, A., Bjorklund, M., and K. Watsen,
> "YANG
>> Module L...'
>>>   == Unused Reference: 'RFC6242' is defined on line 1435, but no
>> explicit
>>>reference was found in the text
>>>'[RFC6242]  Wasserman, M., "Using the NETCONF Protocol
> over
>> Secure Sh...'
>>>
>>> 2. `rfcstrip` extracted "ietf-syslog.yang",  which is missing
>> "@-mm-dd" in its name
>>> 3.  neither 

Re: [netmod] RFC 2119 language [was Re: WG Last Call: draft-ietf-netmod-revised-datastores-04 updates]

[Lou Berger]

I think this goes to if this, or any, draft is a proposed standard or
not. In other words, if it specifies any behavior that for which
interoperability between independent implementations is the objective. 
My general view is that in a Proposed Standard RFC, if it impacts
interoperability, the text should be normative and an RFC should use
2119 language to identify such normative text.  I accept that this is
not strictly required by IETF process, but it has become the norm for PS
track RFCs produced today  -- and I see no reason to not follow IETF norm.

In the context of this draft , as I read it, at least section 5.1 and
some portions of 4.

Lou

On 9/27/2017 12:28 PM, Robert Wilton wrote:
>
> The authors discussed this, and we will close this issue
> (https://github.com/netmod-wg/datastore-dt/issues/14 - title: Does the
> NMDA architecture need to use RFC 2119 language?) by adding RFC 2119
> text to the document, which will probably be best illustrated with an
> updated draft revision.
>
> For the record, the majority of the authors had the view that RFC 2119
> language does not particularly aid readability in this architecture
> document.
>
> Thanks,
> Rob
>
>
> On 16/09/2017 10:56, Andy Bierman wrote:
>>
>>
>> On Sat, Sep 16, 2017 at 12:24 AM, Juergen Schoenwaelder
>> > > wrote:
>>
>> On Fri, Sep 15, 2017 at 02:07:58PM -0700, Andy Bierman wrote:
>> > Hi,
>> >
>> > I strongly agree with Tom that the current draft is an update
>> to RFC 7950.
>> > I also strongly disagree with the decision to omit RFC 2119 in
>> a standards
>> > track document. IMO RFC 2119 terms need to be used in normative
>> text,
>> > especially when dealing with XPath and YANG compiler behavior.
>> >
>>
>> RFC 8174:
>>
>>    o  These words can be used as defined here, but using them is not
>>       required.  Specifically, normative text does not require
>> the use
>>       of these key words.  They are used for clarity and consistency
>>       when that is what's wanted, but a lot of normative text
>> does not
>>       use them and is still normative.
>>
>>
>> So what?
>> Existing YANG specifications use RFC 2119 terms.
>> This draft uses those terms, just with lower-case.
>> Either way, the new YANG rules seem half-baked and not ready
>> for standardization.
>>
>>  
>>
>> /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

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

[netmod] RFC 2119 language [was Re: WG Last Call: draft-ietf-netmod-revised-datastores-04 updates]

[Robert Wilton]

The authors discussed this, and we will close this issue 
(https://github.com/netmod-wg/datastore-dt/issues/14 - title: Does the 
NMDA architecture need to use RFC 2119 language?) by adding RFC 2119 
text to the document, which will probably be best illustrated with an 
updated draft revision.


For the record, the majority of the authors had the view that RFC 2119 
language does not particularly aid readability in this architecture 
document.


Thanks,
Rob


On 16/09/2017 10:56, Andy Bierman wrote:



On Sat, Sep 16, 2017 at 12:24 AM, Juergen Schoenwaelder 
> wrote:


On Fri, Sep 15, 2017 at 02:07:58PM -0700, Andy Bierman wrote:
> Hi,
>
> I strongly agree with Tom that the current draft is an update to
RFC 7950.
> I also strongly disagree with the decision to omit RFC 2119 in a
standards
> track document. IMO RFC 2119 terms need to be used in normative
text,
> especially when dealing with XPath and YANG compiler behavior.
>

RFC 8174:

   o  These words can be used as defined here, but using them is not
      required.  Specifically, normative text does not require the use
      of these key words.  They are used for clarity and consistency
      when that is what's wanted, but a lot of normative text does not
      use them and is still normative.


So what?
Existing YANG specifications use RFC 2119 terms.
This draft uses those terms, just with lower-case.
Either way, the new YANG rules seem half-baked and not ready
for standardization.

/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] vs

[Robert Wilton]

We want to close on some of the NMDA document comments.  I'll send a 
separate summary for all the issues later, possible tomorrow.


In the absence of seeing any comments to the contrary, and with the 
change supported by the other authors, I will apply the proposed update 
to the  description below.


This should resolve two issues:
https://github.com/netmod-wg/datastore-dt/issues/9
 - Title: "Make it clear that validation of intended includes default 
values"


https://github.com/netmod-wg/datastore-dt/issues/3
- Title: "Enhance description of intended datastore"

Thanks,
Rob




3) I think that it would be useful to further refine my previous 
proposed text for intended, particularly rewriting the text on 
validation.  This should hopefully also address Balazs' concern about 
default values be included in validation.




4.4.  The Intended Configuration Datastore ()

   The intended configuration datastore () is a read-only
   configuration datastore.  It is tightly coupled to .  When
   data is written to , the data that is to be validated is
   also conceptually written to . Validation is performed on
   the contents of .

   For simple implementations,  and  are identical.

    does not persist across reboots; its relationship with
    makes that unnecessary.

   Currently there are no standard mechanisms defined that affect
    so that it would have different contents than ,
   but this architecture allows for such mechanisms to be defined.

   One example of such a mechanism is support for marking nodes as
   inactive in .  Inactive nodes are not copied to ,
   and are thus not taken into account when validating the
   configuration.

   Another example is support for templates.  Templates are expanded
   when copied into , and the expanded result is validated.




4.1.4.  The Intended Configuration Datastore ()

   The intended configuration datastore () is a read-only
   configuration datastore.  It represents the configuration after all
   configuration transformations to  are performed (e.g.
   template expansion, removal of inactive configuration), and is the
   configuration that the system attempts to apply.

    is tightly coupled to . Whenever data is written
   to , then  is also immediately updated by
   performing all necessary transformations to the contents of 
   and then  is validated.

    may also be updated independently of  (e.g., if
   one of the configuration transformations is changed), but 
   must always be a 'valid configuration data tree' as defined in
   Section 8.1 of [RFC7950].

   For simple implementations,  and  are identical.

   The contents of  is also related to the 'config true'
   subset of , and hence a client can determine to what
   extent the intended configuration is currently in use by checking
   whether the contents of  also appears in .

    does not persist across reboots; its relationship with
    makes that unnecessary.

   Currently there are no standard mechanisms defined that affect
    so that it would have different contents than ,
   but this architecture allows for such mechanisms to be defined.

   One example of such a mechanism is support for marking nodes as
   inactive in .  Inactive nodes are not copied to .
   A second example is support for templates, which can perform
   transformations on the configuration from  to the
   configuration written to .



Thanks,
Rob





/martin
.



.



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

[netmod] Backward Compatibility Question

[JOEY BOYD]

Hi all,

Suppose I had a published YANG model with the following leaf.


  leaf thing1 {
type uint8;
description
  "Thing 1.";
  }

Later, I realize that I wish I had modeled this in a choice as I now have a 
mutually exclusive option to 'thing1' which I want to add to the model.

  leaf thing2 {
type empty;
description
  "Thing 2.";
  }

This is a very simplified example but should be sufficient to demonstrate the 
problem. 

If I look at the XML representation of 'thing1', it looks like this.

123

If I were to move 'thing1' into a choice with a single case, it would look like 
this.

choice things {
  case thing1 {
leaf thing1 {
  type uint8;
  description
"Thing 1.";
}
  }
}

Looking to the XML representation, it looks the same as before.

123

To me, this means that taking a single node or set of nodes and moving them 
under a case within a new choice statement is a backward compatible change. 
This assumes, of course, any mandatory or default behavior is preserved. I now 
can add 'thing2' to the existing model as an option to 'thing1'.

choice things {
  case thing1 {
leaf thing1 {
  type uint8;
  description
"Thing 1.";
}
  }
  case thing2 {
leaf thing2 {
  type empty;
  description
"Thing 2.";
}
  }
}

Do you agree with this analysis or am I missing something?

Best regards,
Joey

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

Re: [netmod] I-D Action: draft-ietf-netmod-schema-mount-07.txt

[Xufeng Liu]

Alternatively we can use "/top/root" as the name of the mount-point, then
there won't be case for 
  'A module MAY contain multiple "mount-point" statements having the same
argument.'
The "mount-point" extension statement won't take an argument, which will be
cleaner, and make the extension statement look more like a property
specifier than a node declaration.

Thanks,
- Xufeng

> -Original Message-
> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Martin
> Bjorklund
> Sent: Wednesday, September 27, 2017 6:56 AM
> To: netmod@ietf.org
> Subject: Re: [netmod] I-D Action: draft-ietf-netmod-schema-mount-07.txt
> 
> Hi,
> 
> This version fixes the XPath context for parent-reference.
> 
> 
> However, there is one more thing to discuss, which is the term "mount
point".
> 
> The current text says:
> 
>- mount point: container or list node whose definition contains
>  the "mount-point" extension statement. The argument of the
>  "mount-point" statement defines the name of the mount point.
> 
> 
> So if we have:
> 
>   container top {
> container root {
>   yangmnt:mount-point ni;
> }
>   }
> 
> There is one mount point, the node /top/root, with the name "ni".
> 
> Pretty confusing...   Does anyone have any comments around this?
> 
> 
> 
> /martin
> 
> 
> 
> 
> 
> internet-dra...@ietf.org wrote:
> >
> > 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   : YANG Schema Mount
> > Authors : Martin Bjorklund
> >   Ladislav Lhotka
> > Filename: draft-ietf-netmod-schema-mount-07.txt
> > Pages   : 27
> > Date: 2017-09-27
> >
> > Abstract:
> >This document defines a mechanism to combine YANG modules into the
> >schema defined in other YANG modules.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/
> >
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-ietf-netmod-schema-mount-07
> > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-schema-mount-0
> > 7
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-schema-mount-07
> >
> >
> > 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 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] Proposal to enhance the YANG tree output

[Xufeng Liu]

> -Original Message-
> From: Martin Bjorklund [mailto:m...@tail-f.com]
> Sent: Tuesday, September 26, 2017 2:37 AM
> To: xufeng.liu.i...@gmail.com
> Cc: a...@cisco.com; netmod@ietf.org
> Subject: Re: [netmod] Proposal to enhance the YANG tree output
> 
> "Xufeng Liu"  wrote:
> > To a user of the schema-mount, it is important to be able to visualize
> > all key elements of the mounting mechanism: mount-point, mounted
> > schema module, and parent-reference. The details can be worked out,
> > but if any of these elements were not useful in the presentation, it
> > would be questionable whether it had well-specified in the schema
> > mount draft.
> 
> We agreed that we probably don't want to list all enums in the tree.
> Does that imply that enumerations are not well-specified in YANG?
> 
> > > -Original Message-
> > > From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Martin
> > > Bjorklund
> > > Sent: Monday, September 25, 2017 1:39 PM
> > > To: a...@cisco.com
> > > Cc: netmod@ietf.org
> > > Subject: Re: [netmod] Proposal to enhance the YANG tree output
> > >
> > > "Acee Lindem (acee)"  wrote:
> > > > Martin, Lada, et al,
> > > >
> > > > While I don’t think we need additional annotations that Joe had
> > > > prototyped (at least not as the default), I strongly believe we
> > > > need to keep the ‘@‘ and ‘/‘ in the tree output for schema mount.
> > >
> > > Can you explain what information "/" gives the reader?  Compare
> > > these two
> > > trees:
> > >
> > >   +--mp vrf-root
> > >  +--rw rt:routing/
> > > +--rw rt:router-id
> > >
> > > and
> > >
> > >   +--mp vrf-root
> > >  +--rw rt:routing
> > > +--rw rt:router-id
> > >
> > > What did the "/" in the first tree tell me that I don't see in the
> > > second tree?
> >
> > [Xufeng] Because the schema mount draft allows an augmenting module
> > not to be listed in the mounted schema list. The following two
> > examples show two different configurations:
> >
> >   +--mp root
> >  +--rw rt:routing/
> >  |  +--rw router-id? yang:dotted-quad
> >  |  +--rw control-plane-protocols
> >  | +--rw control-plane-protocol* [type name]
> >  |+--rw ospf:ospf/
> >
> > where ospf augments rt, and has been listed in the mounting schema
> > list.
> >
> >   +--mp root
> >  +--rw rt:routing/
> >  |  +--rw router-id? yang:dotted-quad
> >  |  +--rw control-plane-protocols
> >  | +--rw control-plane-protocol* [type name]
> >  |+--rw ospf:ospf
> >
> > where ospf augments rt, and has not been listed in the mounting schema
> > list.
> 
> If the ospf module is NOT listed in the yang library data for the mount point,

[Xufeng] I think that draft-ietf-netmod-schema-mount has the distinction 
between yang library data and schema-mounts/schema list. Do you mean the latter?

> then it will not be present in the tree.  So in this case the tree will be:
> 
>+--mp root
>   +--rw rt:routing
>   |  +--rw router-id? yang:dotted-quad
>   |  +--rw control-plane-protocols
>   | +--rw control-plane-protocol* [type name]
>  // no ospf here
> 
> [Think about it the other way around; if we were to show all nodes from all
> modules that are NOT mounted, our tree would be inifinitely big...]
> 
> If the ospf module *is* listed in the yang library data for the mount point, 
> then
> the tree can be:
> 
>+--mp root
>   +--rw rt:routing
>   |  +--rw router-id? yang:dotted-quad
>   |  +--rw control-plane-protocols
>   | +--rw control-plane-protocol* [type name]
>   |+--rw ospf:ospf
> 
> No need for a '/'.
> 
[Xufeng] What if the user does want to see all nodes in the system, whether 
they are mounted or un-mounted, is it possible?

Also, there is another case: I think that draft-ietf-netmod-schema-mount does 
not prohibit the mount-point container from containing other sub-containers. 
How can we tell these sub-containers are not from mounted modules?

   +--mp root
  +--rw rt:routing
  |  +--rw router-id? yang:dotted-quad
  |  +--rw control-plane-protocols
  | +--rw control-plane-protocol* [type name]
  |+--rw ospf:ospf
  +--rw other:other-container  // augmented by module "other"
  |  +--rw other-leaf? int32

> 
> > > Then consider:
> > >
> > >   +--ro if:interfaces@
> > >
> > > and
> > >
> > >   +--ro if:interfaces
> > >  +-- if:interface@
> > >
> > > and
> > >
> > >   +--ro if:interfaces@
> > >  +-- if:interface@
> > >
> > >
> > > Which ones are legal, and what do they mean?
> > >
> > [Xufeng] The display shows the result of the XPath, right?
> 
> I don't know what it shows; I'm not proposing this notation.  Also note that 
> the
> result of the XPath is a node set of *instance data*, but the tree shows the
> *schema*, and mixing the two is 

Re: [netmod] I-D Action: draft-ietf-netmod-schema-mount-07.txt

[Martin Bjorklund]

Hi,

This version fixes the XPath context for parent-reference.


However, there is one more thing to discuss, which is the term "mount
point".  

The current text says:

   - mount point: container or list node whose definition contains
 the "mount-point" extension statement. The argument of the
 "mount-point" statement defines the name of the mount point.


So if we have:

  container top {
container root {
  yangmnt:mount-point ni;
}
  }

There is one mount point, the node /top/root, with the name "ni".

Pretty confusing...   Does anyone have any comments around this?



/martin





internet-dra...@ietf.org wrote:
> 
> 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   : YANG Schema Mount
> Authors : Martin Bjorklund
>   Ladislav Lhotka
>   Filename: draft-ietf-netmod-schema-mount-07.txt
>   Pages   : 27
>   Date: 2017-09-27
> 
> Abstract:
>This document defines a mechanism to combine YANG modules into the
>schema defined in other YANG modules.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-netmod-schema-mount-07
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-schema-mount-07
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-schema-mount-07
> 
> 
> 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 mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] I-D Action: draft-ietf-netmod-schema-mount-07.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   : YANG Schema Mount
Authors : Martin Bjorklund
  Ladislav Lhotka
Filename: draft-ietf-netmod-schema-mount-07.txt
Pages   : 27
Date: 2017-09-27

Abstract:
   This document defines a mechanism to combine YANG modules into the
   schema defined in other YANG modules.


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

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

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


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] syslog-model-17 shepherd writeup issues -references

[Benoit Claise]

Clyde,

Do you know your next step to progress this document?

Regards, Benoit

I meant to say something about the .1 vs .2 difference.  My comment
assumes that it's supposed to be .1, but we of course should use
whatever is correct.

I also don't know much about that standards body.

K.



- Original Message -
From: "Kent Watsen" 
Sent: Wednesday, September 13, 2017 6:08 PM


Hi Tom,

Thanks.  The fix I'm looking for is for the 'pattern-match' leaf
to have a 'reference' statement to Std-1003.1-2008, and for S4.1
to also list Std-1003.1-2008 as a draft-level reference.

and I am unfamiliar with that standards body so am looking for a little
more.

Is STD- always Posix or do we need to say Posix 1003 or Posix
Std-1003 or is Std-1003 completely unrelated to Posix 1003?

Is there a difference between Std-1003.1-2008 and Posix 1003.2 ie is the
.1 or .2 significant?  You want Std-1003.1; the description contains
Posix 1003.2; the normative Reference is to Std-1003.1-2008.

You pointed out that the Normative Reference is not used; well if we can
sort out what the standard is and get the right label in Normative
References then we can - must - include this in Section 4.1 which will
resolve that comment of yours.

The discussions last July had Clyde saying he wants Posix 1003.2 so if
Std-1003 and Posix 1003 are the same but .1 and.2 are different, then
you are asking for a semantic change against Clyde's wishes.

I hope my confusion is sufficiently clear, at least to Clyde!

Tom Petch


I was going to point out the typo "the the" as well, but figured
that the RFC Editor would get it.

K. // shepherd


--

Kent

You flag Std-1003.1-2008 as listed as a normative reference but not

used

anywhere in the document.  In the Descriptions, but not in the s.4.1
references, I see

This leaf describes a Posix 1003.2 regular expression ...

twice, which may, or may not, relate to this issue.

Back in July, clyde said
"I will insert a normative reference to POSIX 1003.2 in the next
revision of the draft."

In a similar vein, RFC6991 appears in a reference statement but

nowhere

else.

As you point out, RFC6021 is referenced but is obsoleted by RFC6991 so
should not be.

And in a slightly different vein,

registry [RFC7895]/>.  Following the format in [RFC7950]/>, the the

looks odd for plain text and for the repetition of 'the'..

Tom Petch

- Original Message -
From: "Kent Watsen" 
To: 
Cc: 
Sent: Tuesday, September 12, 2017 10:50 PM
Subject: [netmod] syslog-model-17 shepherd writeup issues



Clyde, all,

In reviewing the draft for Shepherd writeup, I found the following

issues that I think need to be addressed before the document can be

sent

to Benoit for AD review:


1. Idnits found the following:

   Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment

(--).

 ** There are 2 instances of too long lines in the document, the

longest one

  being 3 characters in excess of 72.

 ** Obsolete normative reference: RFC 6021 (Obsoleted by RFC

6991)

 ** Downref: Normative reference to an Historic RFC: RFC 6587

 == Missing Reference: 'RFC5425' is mentioned on line 359, but

not

defined

  '[RFC5425], [RFC5426], [RFC6587], and [RFC5848]'

  == Unused Reference: 'RFC7895' is defined on line 1406, but no

explicit

   reference was found in the text
   '[RFC7895]  Bierman, A., Bjorklund, M., and K. Watsen,

"YANG

Module L...'

  == Unused Reference: 'RFC6242' is defined on line 1435, but no

explicit

   reference was found in the text
   '[RFC6242]  Wasserman, M., "Using the NETCONF Protocol

over

Secure Sh...'


2. `rfcstrip` extracted "ietf-syslog.yang",  which is missing

"@-mm-dd" in its name

3.  neither `pyang` nor `yanglint` found any errors with

ietf-syslog.yang.pyang says

   for vendor-syslog-types-example: statement "identity" must

have

a "description"

   substatement.

4. testing the examples in the draft against yanglint:
   - for both examples: Missing element's "namespace". (/config)
   - just removing the "" element envelop resolves this

error.

5. the 2nd example uses IP address "2001:db8:a0b:12f0::1", but this

SHOULD be a

  domain name (e.g., foo.example.com)

6. in the YANG module, anywhere you have an RFC listed in a

'description' statement,

  there should be a 'reference' statement for that RFC.

7. in the tree diagram, the leafrefs no longer indicate what they

point at, they now all

  just say "leafref".  Did you do this on purpose, or are you

using

a different tree

  output generator from -15?

8. RFC6536 is listed as a normative reference, but it probably

should

be informative.

9. Std-1003.1-2008 is listed as a normative reference, but it is not

used anywhere in the document.

10. RFC6242 is listed as an informative reference, but