Re: [netmod] upcoming adoptions - this appendix is normative

[Robert Wilton]

Hi Randy,


On 02/10/2017 17:37, Randy Presuhn wrote:

Hi -

On 10/2/2017 7:18 AM, Robert Wilton wrote:

This discussion may be conflating two issues:

(i) Does RFC text have to use RFC2119 terms to be normative?
RFC 8174 categorically states that text can still be normative 
without using RFC 2119 terms.


Thus it's clear that their usage is not necessarily necessary.


(ii) Should standards track documents use RFC 2119 terms?
If 93% of recently published standards track RFCs make use of RFC 
2119 terms then that seems like a strong consistency argument to use 
them unless there is a good reason not to.


I think RFC 2119 itself provides a fair counter-argument to the
imposition of such a requirement.  RFC 2119 states that "[i]mperatives
of the type defined in this memo must be used with care and sparingly."
To use "with care" and "sparingly" seems contrary to the notion of
employing them merely for "consistency."

I interpret this slightly differently.

If a standards track RFC has some text that should be interpreted in a 
way that matches (or perhaps is close) to the RFC 2119 language 
semantics then it is more consistent and less ambiguous to use RFC 2119 
terms since the vast majority of other RFCs are using it.  If nothing in 
the draft matches the RFC 2119 language then of course you don't need to 
cite it.


It might be interesting to look at the 7% of RFCs that don't use it and 
see if that was because it wasn't necessary, due to the authors choice, 
or some other reason.


Thanks,
Rob




Randy

___
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] upcoming adoptions - this appendix is normative

[Randy Presuhn]

Hi -

On 10/2/2017 7:18 AM, Robert Wilton wrote:

This discussion may be conflating two issues:

(i) Does RFC text have to use RFC2119 terms to be normative?
RFC 8174 categorically states that text can still be normative without 
using RFC 2119 terms.


Thus it's clear that their usage is not necessarily necessary.


(ii) Should standards track documents use RFC 2119 terms?
If 93% of recently published standards track RFCs make use of RFC 2119 
terms then that seems like a strong consistency argument to use them 
unless there is a good reason not to.


I think RFC 2119 itself provides a fair counter-argument to the
imposition of such a requirement.  RFC 2119 states that "[i]mperatives
of the type defined in this memo must be used with care and sparingly."
To use "with care" and "sparingly" seems contrary to the notion of
employing them merely for "consistency."

Randy

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

Re: [netmod] upcoming adoptions - this appendix is normative

[Robert Wilton]

This discussion may be conflating two issues:

(i) Does RFC text have to use RFC2119 terms to be normative?
RFC 8174 categorically states that text can still be normative without 
using RFC 2119 terms.


(ii) Should standards track documents use RFC 2119 terms?
If 93% of recently published standards track RFCs make use of RFC 2119 
terms then that seems like a strong consistency argument to use them 
unless there is a good reason not to.


We've already agreed that the datastores draft will use RFC 2119 terms 
where appropriate.  For the model drafts, Benoit's suggestion to state 
that the appendix is normative seems like an easy solution where it is 
required.


If it gets discussed at Singapore then I would suggest doing so at a bar 
rather than spending WG time on it ;-)


Cheers,
Rob


On 02/10/2017 12:58, Lou Berger wrote:

Juerge,

Understood.  I think you made this clear in our previous discussion on
this topic, even though ~93% of the RFCs published in the last 5 years
use it.   We certainly can discuss this with our AD, and if there's
sufficient interest in the WG even discuss it in Singapore. If others
are interested in face to face time for such a discussion, please let us
(all) know on the list.

Cheers,

Lou

On 10/2/2017 7:05 AM, Juergen Schoenwaelder wrote:

Lou,

the conclusion is that we add RFC 2119 here and there but I disagree
with the notion that normative text needs RFC 2119 language, i.e.,
that text that does not use RFC 2119 language is not normative. See
the pointers to the RFCs that I have provided. Now you want to make
this even a rule for all future WG docs so I strongly oppose to that.

/js

On Mon, Oct 02, 2017 at 06:39:35AM -0400, Lou Berger wrote:

Benoit,

I think this and related topic was closed with the conclusion of sticking
with 2119 language for normative text in current and future WG docs. We
certainly can add this sentence as well.

Lou


On October 2, 2017 5:11:20 AM Benoit Claise  wrote:


Dear all,

To avoid any confusion, just clearly mention it.
      "This appendix is normative | informative"
No need to debate for hours on this.

Regards, Benoit

- Original Message -
From: "Lou Berger" 
Sent: Thursday, September 14, 2017 6:06 PM


On 9/14/2017 12:36 PM, t.petch wrote:

Appendices are Normative if they say that they are Normative.  The
default is that they are not so say that they are and they are.

This is

well established practice.

Hi Tom,
My memory (I haven't checked recently) is there is nothing in or
defined process that says if an Appendix is normative or not. Other
SDOs certainly have formal definitions here. Within the IETF, my view
has been that if an appendix includes RFC2119 language, it is
normative. Actually, strictly speaking, any text in a Standards Track
RFC that doesn't include RFC2119 language is just informative.

Lou

Try RFC4910.

'   This appendix is normative.'

and not a SHOULD or a MUST in sight.

Tom Petch


Lou


___
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] upcoming adoptions - this appendix is normative

[Lou Berger]

Juerge,

Understood.  I think you made this clear in our previous discussion on
this topic, even though ~93% of the RFCs published in the last 5 years
use it.   We certainly can discuss this with our AD, and if there's
sufficient interest in the WG even discuss it in Singapore. If others
are interested in face to face time for such a discussion, please let us
(all) know on the list.

Cheers,

Lou

On 10/2/2017 7:05 AM, Juergen Schoenwaelder wrote:
> Lou,
>
> the conclusion is that we add RFC 2119 here and there but I disagree
> with the notion that normative text needs RFC 2119 language, i.e.,
> that text that does not use RFC 2119 language is not normative. See
> the pointers to the RFCs that I have provided. Now you want to make
> this even a rule for all future WG docs so I strongly oppose to that.
>
> /js
>
> On Mon, Oct 02, 2017 at 06:39:35AM -0400, Lou Berger wrote:
>> Benoit,
>>
>> I think this and related topic was closed with the conclusion of sticking
>> with 2119 language for normative text in current and future WG docs. We
>> certainly can add this sentence as well.
>>
>> Lou
>>
>>
>> On October 2, 2017 5:11:20 AM Benoit Claise  wrote:
>>
>>> Dear all,
>>>
>>> To avoid any confusion, just clearly mention it.
>>>      "This appendix is normative | informative"
>>> No need to debate for hours on this.
>>>
>>> Regards, Benoit
 - Original Message -
 From: "Lou Berger" 
 Sent: Thursday, September 14, 2017 6:06 PM

> On 9/14/2017 12:36 PM, t.petch wrote:
>> Appendices are Normative if they say that they are Normative.  The
>> default is that they are not so say that they are and they are.
 This is
>> well established practice.
> Hi Tom,
> My memory (I haven't checked recently) is there is nothing in or
> defined process that says if an Appendix is normative or not. Other
> SDOs certainly have formal definitions here. Within the IETF, my view
> has been that if an appendix includes RFC2119 language, it is
> normative. Actually, strictly speaking, any text in a Standards Track
> RFC that doesn't include RFC2119 language is just informative.
 Lou

 Try RFC4910.

 '   This appendix is normative.'

 and not a SHOULD or a MUST in sight.

 Tom Petch

> Lou
>
 ___
 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] upcoming adoptions - this appendix is normative

[Juergen Schoenwaelder]

Lou,

the conclusion is that we add RFC 2119 here and there but I disagree
with the notion that normative text needs RFC 2119 language, i.e.,
that text that does not use RFC 2119 language is not normative. See
the pointers to the RFCs that I have provided. Now you want to make
this even a rule for all future WG docs so I strongly oppose to that.

/js

On Mon, Oct 02, 2017 at 06:39:35AM -0400, Lou Berger wrote:
> Benoit,
> 
> I think this and related topic was closed with the conclusion of sticking
> with 2119 language for normative text in current and future WG docs. We
> certainly can add this sentence as well.
> 
> Lou
> 
> 
> On October 2, 2017 5:11:20 AM Benoit Claise  wrote:
> 
> > Dear all,
> > 
> > To avoid any confusion, just clearly mention it.
> >      "This appendix is normative | informative"
> > No need to debate for hours on this.
> > 
> > Regards, Benoit
> > > - Original Message -
> > > From: "Lou Berger" 
> > > Sent: Thursday, September 14, 2017 6:06 PM
> > > 
> > > > On 9/14/2017 12:36 PM, t.petch wrote:
> > > > > Appendices are Normative if they say that they are Normative.  The
> > > > > default is that they are not so say that they are and they are.
> > > This is
> > > > > well established practice.
> > > > Hi Tom,
> > > > My memory (I haven't checked recently) is there is nothing in or
> > > > defined process that says if an Appendix is normative or not. Other
> > > > SDOs certainly have formal definitions here. Within the IETF, my view
> > > > has been that if an appendix includes RFC2119 language, it is
> > > > normative. Actually, strictly speaking, any text in a Standards Track
> > > > RFC that doesn't include RFC2119 language is just informative.
> > > Lou
> > > 
> > > Try RFC4910.
> > > 
> > > '   This appendix is normative.'
> > > 
> > > and not a SHOULD or a MUST in sight.
> > > 
> > > Tom Petch
> > > 
> > > > Lou
> > > > 
> > > ___
> > > 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

-- 
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 - this appendix is normative

[Lou Berger]

Benoit,

I think this and related topic was closed with the conclusion of sticking 
with 2119 language for normative text in current and future WG docs. We 
certainly can add this sentence as well.


Lou


On October 2, 2017 5:11:20 AM Benoit Claise  wrote:


Dear all,

To avoid any confusion, just clearly mention it.
     "This appendix is normative | informative"
No need to debate for hours on this.

Regards, Benoit

- Original Message -
From: "Lou Berger" 
Sent: Thursday, September 14, 2017 6:06 PM


On 9/14/2017 12:36 PM, t.petch wrote:

Appendices are Normative if they say that they are Normative.  The
default is that they are not so say that they are and they are.

This is

well established practice.

Hi Tom,
My memory (I haven't checked recently) is there is nothing in or
defined process that says if an Appendix is normative or not. Other
SDOs certainly have formal definitions here. Within the IETF, my view
has been that if an appendix includes RFC2119 language, it is
normative. Actually, strictly speaking, any text in a Standards Track
RFC that doesn't include RFC2119 language is just informative.

Lou

Try RFC4910.

'   This appendix is normative.'

and not a SHOULD or a MUST in sight.

Tom Petch


Lou


___
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] upcoming adoptions - this appendix is normative

[Benoit Claise]

Dear all,

To avoid any confusion, just clearly mention it.
    "This appendix is normative | informative"
No need to debate for hours on this.

Regards, Benoit

- Original Message -
From: "Lou Berger" 
Sent: Thursday, September 14, 2017 6:06 PM


On 9/14/2017 12:36 PM, t.petch wrote:

Appendices are Normative if they say that they are Normative.  The
default is that they are not so say that they are and they are.

This is

well established practice.

Hi Tom,
My memory (I haven't checked recently) is there is nothing in or
defined process that says if an Appendix is normative or not. Other
SDOs certainly have formal definitions here. Within the IETF, my view
has been that if an appendix includes RFC2119 language, it is
normative. Actually, strictly speaking, any text in a Standards Track
RFC that doesn't include RFC2119 language is just informative.

Lou

Try RFC4910.

'   This appendix is normative.'

and not a SHOULD or a MUST in sight.

Tom Petch


Lou


___
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] upcoming adoptions - this appendix is normative

[Lou Berger]

Hi Tom.

    A few observations:


On 9/15/2017 12:28 PM, t.petch wrote:
> - Original Message -
> From: "Lou Berger" 
> Sent: Thursday, September 14, 2017 6:06 PM
>
>> On 9/14/2017 12:36 PM, t.petch wrote:
>>> Appendices are Normative if they say that they are Normative.  The
>>> default is that they are not so say that they are and they are.
> This is
>>> well established practice.
>> Hi Tom,
>> My memory (I haven't checked recently) is there is nothing in or
>> defined process that says if an Appendix is normative or not. Other
>> SDOs certainly have formal definitions here. Within the IETF, my view
>> has been that if an appendix includes RFC2119 language, it is
>> normative. Actually, strictly speaking, any text in a Standards Track
>> RFC that doesn't include RFC2119 language is just informative.
> Lou
>
> Try RFC4910.
>
> '   This appendix is normative. '
>
> and not a SHOULD or a MUST in sight.

- This is an Experimental not Proposed Standard RFC. 

- As an organization, we've improved or differentiation of normative and
informative text over the last 10 years

- The RFC editor still does *not* require use of RFC2119 language, see
https://tools.ietf.org/html/rfc7322#section-4.8.2
Lou
> Tom Petch
>
>> Lou
>>
>

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

Re: [netmod] upcoming adoptions

[Ladislav Lhotka]

Andy Bierman  writes:

> On Fri, Sep 15, 2017 at 9:02 AM, Robert Wilton  wrote:
>
>>
>>
>> On 15/09/2017 16:23, Andy Bierman wrote:
>>
>> Hi,
>>
>> So are you saying the NMDA transition strategy should be ignored?
>>
>> My personal preference for the routing modules would be to keep the same
>> module name and deprecate the old nodes.
>>
>> However, I doubt that there are many implementations of this 8022 yet, and
>> if the authors prefer to use a new namespace without the old nodes then I'm
>> fine with that also.  Are you opposed to this approach?
>>
>>
>
> A new module name mandates a new namespace, so they go together.
> Abandoning the old module is fine, except leaving that module with status
> "current" is not fine.
> IMO you need to republish the old module as well, with everything status
> obsolete.

I don't agree with this. The "status" tag is justified for subsequent
revisions of the same module so as to aid old clients.

But if the module name and namespace URI are different, there is no such
concern. Modules contained in RFCs 7223, 8022 etc. just define some
schemas that happen to be good for my purposes. So I want to be able to
continue using them, and don't want tools to issue useless warnings or
even refuse to process such modules.

I am fine though with making a new revision of ietf-routing
etc. mentioning in the module description that this module is not
compatible with the NMDA architecture, and providing a pointer to
ietf-routing-2.

Lada

>
>
>
>> E.g. For ietf-interfaces, and ietf-ip, which are older, and hence probably
>> much more widely implemented then I think that the modules should be
>> updated in place with the existing state tree deprecated.  I.e. I support
>> what Martin has done in his IDs, and don't want this to change.
>>
>> What is the problem with deprecated nodes?
>>
>> Nothing really, but I guess that they are likely to be baggage that is
>> going to be around for a long time even if very few people ever implement
>> the deprecated nodes.
>>
>>
>> Why aren't you following your own transition strategy?
>>
>> Really because I'm not an author, both solutions seem valid, and I
>> actually think just reaching a conclusion quickly is more important than
>> which particular solution is chosen.  I don't see any advantage is pushing
>> back the adoption call - it seems like it will probably just delay when we
>> can do WG LC.
>>
>> I actually think that the bigger question that needs to be resolved is
>> whether we need an optional extension to mark a module as NMDA compatible,
>> or for the extra NMDA state module, as I think that both you and Tom have
>> been asking for.
>>
>
> I am no fan of YANG conformance.
> The WG does not seem to understand the difference between
>(A) what a server is supposed to do
>(B) what a server claims to do
>
> There is no way to express (A) in a YANG module, just (B) in the new
> yang-library.
>
>
> Andy
>
>
>
>>
>> Thanks,
>> Rob
>>
>>
>>
>>
>> Andy
>>
>> On Fri, Sep 15, 2017 at 8:01 AM, Robert Wilton  wrote:
>>
>>>
>>>
>>> On 15/09/2017 15:52, Acee Lindem (acee) wrote:
>>>
 Hi,

 With respect to WG adoption, we will do whatever the WG decides for the
 RFC 8022 model. We have a strong preference toward not carrying the
 deprecated nodes forward and new module versions appears to be a good way
 to achieve this.

>>> Can we not adopt regardless?  We know that we are going to bis 8022, and
>>> having an adopted draft gives it a bit more legitimacy and helps other
>>> folks to migrate.
>>>
>>> Or perhaps we can start the call for adoption and continue to try and
>>> resolve this issue at the same time ;-).  I think that it would be good to
>>> try and get the updated model drafts to WG LC by Singapore.
>>>
>>> I know that it hasn't been asked yet, but I support adoption of any 8022
>>> bis draft that (i) provides the correct NDMA combined tree (ii) removes or
>>> deprecates the old state nodes :-)
>>>
>>> Sorry, if I'm being pushy :-)
>>> Rob
>>>
>>>
>>>
 I agree with Lada that deprecating all the schema nodes is unnecessary.
 However, we’ll do what it takes to reach consensus and satisfy the most
 pedantic among us.

 Thanks,
 Acee

 On 9/15/17, 6:38 AM, "netmod on behalf of Ladislav Lhotka"
  wrote:

 Kent Watsen píše v Čt 14. 09. 2017 v 14:52 +:
>
>> rfc8022bis-02 signals the intent to ditch the current/soon-to-be-legacy
>> module, but does it actually say it?  (I can't find it)
>>
> The modules contained therein have different names and namespaces, so
> there is
> no formal ancestry. I would prefer to keep the modules from RFC 8022 as
> they are
> - some weirdos may still want to use them.
>
> The draft does say that it obsoletes 8022, but I'm unsure if that's
>> going to
>> have a meaningful impact in 

Re: [netmod] upcoming adoptions

[Kent Watsen]

> A new module name mandates a new namespace, so they go together.
> Abandoning the old module is fine, except leaving that module with
> status "current" is not fine.  IMO you need to republish the old module
> as well, with everything status obsolete.

Agreed.

If a new module-name is used (e.g., routing-cfg-2), then the old module
name should be republished also, just to deprecate (obsolete?) the old
module.   The deprecated module could be published in this draft or
another draft (keep rfc8022bis clean?)

As co-chair, I'm okay with adoption starting even without this detail
finalized up front.

K.

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

Re: [netmod] upcoming adoptions

[Andy Bierman]

On Fri, Sep 15, 2017 at 9:02 AM, Robert Wilton  wrote:

>
>
> On 15/09/2017 16:23, Andy Bierman wrote:
>
> Hi,
>
> So are you saying the NMDA transition strategy should be ignored?
>
> My personal preference for the routing modules would be to keep the same
> module name and deprecate the old nodes.
>
> However, I doubt that there are many implementations of this 8022 yet, and
> if the authors prefer to use a new namespace without the old nodes then I'm
> fine with that also.  Are you opposed to this approach?
>
>

A new module name mandates a new namespace, so they go together.
Abandoning the old module is fine, except leaving that module with status
"current" is not fine.
IMO you need to republish the old module as well, with everything status
obsolete.



> E.g. For ietf-interfaces, and ietf-ip, which are older, and hence probably
> much more widely implemented then I think that the modules should be
> updated in place with the existing state tree deprecated.  I.e. I support
> what Martin has done in his IDs, and don't want this to change.
>
> What is the problem with deprecated nodes?
>
> Nothing really, but I guess that they are likely to be baggage that is
> going to be around for a long time even if very few people ever implement
> the deprecated nodes.
>
>
> Why aren't you following your own transition strategy?
>
> Really because I'm not an author, both solutions seem valid, and I
> actually think just reaching a conclusion quickly is more important than
> which particular solution is chosen.  I don't see any advantage is pushing
> back the adoption call - it seems like it will probably just delay when we
> can do WG LC.
>
> I actually think that the bigger question that needs to be resolved is
> whether we need an optional extension to mark a module as NMDA compatible,
> or for the extra NMDA state module, as I think that both you and Tom have
> been asking for.
>

I am no fan of YANG conformance.
The WG does not seem to understand the difference between
   (A) what a server is supposed to do
   (B) what a server claims to do

There is no way to express (A) in a YANG module, just (B) in the new
yang-library.


Andy



>
> Thanks,
> Rob
>
>
>
>
> Andy
>
> On Fri, Sep 15, 2017 at 8:01 AM, Robert Wilton  wrote:
>
>>
>>
>> On 15/09/2017 15:52, Acee Lindem (acee) wrote:
>>
>>> Hi,
>>>
>>> With respect to WG adoption, we will do whatever the WG decides for the
>>> RFC 8022 model. We have a strong preference toward not carrying the
>>> deprecated nodes forward and new module versions appears to be a good way
>>> to achieve this.
>>>
>> Can we not adopt regardless?  We know that we are going to bis 8022, and
>> having an adopted draft gives it a bit more legitimacy and helps other
>> folks to migrate.
>>
>> Or perhaps we can start the call for adoption and continue to try and
>> resolve this issue at the same time ;-).  I think that it would be good to
>> try and get the updated model drafts to WG LC by Singapore.
>>
>> I know that it hasn't been asked yet, but I support adoption of any 8022
>> bis draft that (i) provides the correct NDMA combined tree (ii) removes or
>> deprecates the old state nodes :-)
>>
>> Sorry, if I'm being pushy :-)
>> Rob
>>
>>
>>
>>> I agree with Lada that deprecating all the schema nodes is unnecessary.
>>> However, we’ll do what it takes to reach consensus and satisfy the most
>>> pedantic among us.
>>>
>>> Thanks,
>>> Acee
>>>
>>> On 9/15/17, 6:38 AM, "netmod on behalf of Ladislav Lhotka"
>>>  wrote:
>>>
>>> Kent Watsen píše v Čt 14. 09. 2017 v 14:52 +:

> rfc8022bis-02 signals the intent to ditch the current/soon-to-be-legacy
> module, but does it actually say it?  (I can't find it)
>
 The modules contained therein have different names and namespaces, so
 there is
 no formal ancestry. I would prefer to keep the modules from RFC 8022 as
 they are
 - some weirdos may still want to use them.

 The draft does say that it obsoletes 8022, but I'm unsure if that's
> going to
> have a meaningful impact in the wild.  I think Juergen said they had
> this
> issue with MIB2 and only after a couple years of misuse did they
> republish the
> legacy MIBs with deprecated status.
>
> I'm okay with this change being made after adoption, so long as there's
> general agreement to do it.  Are the authors okay with it, or are there
> any
> better suggestions?
>
> PS: Sadly, the 'module' statement does not have 'status' as a
> substatement [I
> just added this omission to the yang-next tracker].  I think the only
> way to
> "deprecate a module" is to instead deprecate the all the
> nodes/rpcs/notifications in the module.  Kind of ugly, but it's for a
> deprecated module, so who care, right?  ;)
>
 I think it is unnecessary. If somebody needs adding such a module to the
 

Re: [netmod] upcoming adoptions - this appendix is normative

[t.petch]

- Original Message -
From: "Lou Berger" 
Sent: Thursday, September 14, 2017 6:06 PM

> On 9/14/2017 12:36 PM, t.petch wrote:
> > Appendices are Normative if they say that they are Normative.  The
> > default is that they are not so say that they are and they are.
This is
> > well established practice.
>
> Hi Tom,
> My memory (I haven't checked recently) is there is nothing in or
> defined process that says if an Appendix is normative or not. Other
> SDOs certainly have formal definitions here. Within the IETF, my view
> has been that if an appendix includes RFC2119 language, it is
> normative. Actually, strictly speaking, any text in a Standards Track
> RFC that doesn't include RFC2119 language is just informative.

Lou

Try RFC4910.

'   This appendix is normative. '

and not a SHOULD or a MUST in sight.

Tom Petch

> Lou
>

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

Re: [netmod] upcoming adoptions

[Robert Wilton]

On 15/09/2017 16:23, Andy Bierman wrote:

Hi,

So are you saying the NMDA transition strategy should be ignored?
My personal preference for the routing modules would be to keep the same 
module name and deprecate the old nodes.


However, I doubt that there are many implementations of this 8022 yet, 
and if the authors prefer to use a new namespace without the old nodes 
then I'm fine with that also.  Are you opposed to this approach?


E.g. For ietf-interfaces, and ietf-ip, which are older, and hence 
probably much more widely implemented then I think that the modules 
should be updated in place with the existing state tree deprecated. I.e. 
I support what Martin has done in his IDs, and don't want this to change.



What is the problem with deprecated nodes?
Nothing really, but I guess that they are likely to be baggage that is 
going to be around for a long time even if very few people ever 
implement the deprecated nodes.




Why aren't you following your own transition strategy?
Really because I'm not an author, both solutions seem valid, and I 
actually think just reaching a conclusion quickly is more important than 
which particular solution is chosen.  I don't see any advantage is 
pushing back the adoption call - it seems like it will probably just 
delay when we can do WG LC.


I actually think that the bigger question that needs to be resolved is 
whether we need an optional extension to mark a module as NMDA 
compatible, or for the extra NMDA state module, as I think that both you 
and Tom have been asking for.


Thanks,
Rob





Andy

On Fri, Sep 15, 2017 at 8:01 AM, Robert Wilton > wrote:




On 15/09/2017 15:52, Acee Lindem (acee) wrote:

Hi,

With respect to WG adoption, we will do whatever the WG
decides for the
RFC 8022 model. We have a strong preference toward not
carrying the
deprecated nodes forward and new module versions appears to be
a good way
to achieve this.

Can we not adopt regardless?  We know that we are going to bis
8022, and having an adopted draft gives it a bit more legitimacy
and helps other folks to migrate.

Or perhaps we can start the call for adoption and continue to try
and resolve this issue at the same time ;-).  I think that it
would be good to try and get the updated model drafts to WG LC by
Singapore.

I know that it hasn't been asked yet, but I support adoption of
any 8022 bis draft that (i) provides the correct NDMA combined
tree (ii) removes or deprecates the old state nodes :-)

Sorry, if I'm being pushy :-)
Rob



I agree with Lada that deprecating all the schema nodes is
unnecessary.
However, we’ll do what it takes to reach consensus and satisfy
the most
pedantic among us.

Thanks,
Acee

On 9/15/17, 6:38 AM, "netmod on behalf of Ladislav Lhotka"
 on
behalf of lho...@nic.cz > wrote:

Kent Watsen píše v Čt 14. 09. 2017 v 14:52 +:

rfc8022bis-02 signals the intent to ditch the
current/soon-to-be-legacy
module, but does it actually say it?  (I can't find it)

The modules contained therein have different names and
namespaces, so
there is
no formal ancestry. I would prefer to keep the modules
from RFC 8022 as
they are
- some weirdos may still want to use them.

The draft does say that it obsoletes 8022, but I'm
unsure if that's
going to
have a meaningful impact in the wild.  I think Juergen
said they had
this
issue with MIB2 and only after a couple years of
misuse did they
republish the
legacy MIBs with deprecated status.

I'm okay with this change being made after adoption,
so long as there's
general agreement to do it.  Are the authors okay with
it, or are there
any
better suggestions?

PS: Sadly, the 'module' statement does not have
'status' as a
substatement [I
just added this omission to the yang-next tracker]. I
think the only
way to
"deprecate a module" is to instead deprecate the all the
nodes/rpcs/notifications in the module.  Kind of ugly,
but it's for a
deprecated module, so who care, right?  ;)

I think it is unnecessary. If somebody needs adding such a
module to the
data
model, he/she should probably have a reason to do so, such
 

Re: [netmod] upcoming adoptions

[Andy Bierman]

Hi,

So are you saying the NMDA transition strategy should be ignored?
What is the problem with deprecated nodes?
Why aren't you following your own transition strategy?


Andy

On Fri, Sep 15, 2017 at 8:01 AM, Robert Wilton  wrote:

>
>
> On 15/09/2017 15:52, Acee Lindem (acee) wrote:
>
>> Hi,
>>
>> With respect to WG adoption, we will do whatever the WG decides for the
>> RFC 8022 model. We have a strong preference toward not carrying the
>> deprecated nodes forward and new module versions appears to be a good way
>> to achieve this.
>>
> Can we not adopt regardless?  We know that we are going to bis 8022, and
> having an adopted draft gives it a bit more legitimacy and helps other
> folks to migrate.
>
> Or perhaps we can start the call for adoption and continue to try and
> resolve this issue at the same time ;-).  I think that it would be good to
> try and get the updated model drafts to WG LC by Singapore.
>
> I know that it hasn't been asked yet, but I support adoption of any 8022
> bis draft that (i) provides the correct NDMA combined tree (ii) removes or
> deprecates the old state nodes :-)
>
> Sorry, if I'm being pushy :-)
> Rob
>
>
>
>> I agree with Lada that deprecating all the schema nodes is unnecessary.
>> However, we’ll do what it takes to reach consensus and satisfy the most
>> pedantic among us.
>>
>> Thanks,
>> Acee
>>
>> On 9/15/17, 6:38 AM, "netmod on behalf of Ladislav Lhotka"
>>  wrote:
>>
>> Kent Watsen píše v Čt 14. 09. 2017 v 14:52 +:
>>>
 rfc8022bis-02 signals the intent to ditch the current/soon-to-be-legacy
 module, but does it actually say it?  (I can't find it)

>>> The modules contained therein have different names and namespaces, so
>>> there is
>>> no formal ancestry. I would prefer to keep the modules from RFC 8022 as
>>> they are
>>> - some weirdos may still want to use them.
>>>
>>> The draft does say that it obsoletes 8022, but I'm unsure if that's
 going to
 have a meaningful impact in the wild.  I think Juergen said they had
 this
 issue with MIB2 and only after a couple years of misuse did they
 republish the
 legacy MIBs with deprecated status.

 I'm okay with this change being made after adoption, so long as there's
 general agreement to do it.  Are the authors okay with it, or are there
 any
 better suggestions?

 PS: Sadly, the 'module' statement does not have 'status' as a
 substatement [I
 just added this omission to the yang-next tracker].  I think the only
 way to
 "deprecate a module" is to instead deprecate the all the
 nodes/rpcs/notifications in the module.  Kind of ugly, but it's for a
 deprecated module, so who care, right?  ;)

>>> I think it is unnecessary. If somebody needs adding such a module to the
>>> data
>>> model, he/she should probably have a reason to do so, such as data
>>> implemented
>>> on the server.
>>>
>>> Lada
>>>
>>> Kent


 --

 Hi Rob,

 On 9/14/2017 9:37 AM, Robert Wilton wrote:

> Hi Kent & Lou,
>
> When do you think that it will be possible to start the adoption
>
 process

> on these drafts?
>
> I think that the first two at least would seem to be ready for
> adoption.  For the 3rd draft, there still seems to be an open
>
 question

> of what to do with the old state tree, but presumably that could be
> solved after the draft has been adopted?
>
 I see an update for the third was published yesterday
 (https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-02)  that
 clarifies the intent is to replace the current modules, and presumably
 obsolete 8022.  And now that this intended direction is clear in the
 draft we could poll it.

 I think this still doesn't address if we need to indicate that the
 rfc8022 defined modules are deprecated by some other mechanisms than
 just replacing the RFC, e.g., by updating the old modules with all nodes
 marked as deprecated.  I think you're right that this could be done post
 adoption.  Of course others are free to disagree.

 I check with Kent and see what he thinks.

 Thanks,
 Lou

 Thanks,
> Rob
>
>
> On 30/08/2017 00:46, Kent Watsen wrote:
>
>> Hey folks,
>>
>> As discussed at the last meeting, we are heading to revising
>>
> existing RFCs

> to align them with NMDA.  The first batch have been published as
>> individual drafts:
>>
>> 1. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7223bis-00
>> 2. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7277bis-00
>> 3. https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-00
>>
>> Please take a look (comments welcome!) and stay tuned for the
>>
> related

> adoption calls.
>>
>> Thanks,
>> Kent 

Re: [netmod] upcoming adoptions

[Robert Wilton]

On 15/09/2017 15:52, Acee Lindem (acee) wrote:

Hi,

With respect to WG adoption, we will do whatever the WG decides for the
RFC 8022 model. We have a strong preference toward not carrying the
deprecated nodes forward and new module versions appears to be a good way
to achieve this.
Can we not adopt regardless?  We know that we are going to bis 8022, and 
having an adopted draft gives it a bit more legitimacy and helps other 
folks to migrate.


Or perhaps we can start the call for adoption and continue to try and 
resolve this issue at the same time ;-).  I think that it would be good 
to try and get the updated model drafts to WG LC by Singapore.


I know that it hasn't been asked yet, but I support adoption of any 8022 
bis draft that (i) provides the correct NDMA combined tree (ii) removes 
or deprecates the old state nodes :-)


Sorry, if I'm being pushy :-)
Rob




I agree with Lada that deprecating all the schema nodes is unnecessary.
However, we’ll do what it takes to reach consensus and satisfy the most
pedantic among us.

Thanks,
Acee

On 9/15/17, 6:38 AM, "netmod on behalf of Ladislav Lhotka"
 wrote:


Kent Watsen píše v Čt 14. 09. 2017 v 14:52 +:

rfc8022bis-02 signals the intent to ditch the current/soon-to-be-legacy
module, but does it actually say it?  (I can't find it)

The modules contained therein have different names and namespaces, so
there is
no formal ancestry. I would prefer to keep the modules from RFC 8022 as
they are
- some weirdos may still want to use them.


The draft does say that it obsoletes 8022, but I'm unsure if that's
going to
have a meaningful impact in the wild.  I think Juergen said they had
this
issue with MIB2 and only after a couple years of misuse did they
republish the
legacy MIBs with deprecated status.

I'm okay with this change being made after adoption, so long as there's
general agreement to do it.  Are the authors okay with it, or are there
any
better suggestions?

PS: Sadly, the 'module' statement does not have 'status' as a
substatement [I
just added this omission to the yang-next tracker].  I think the only
way to
"deprecate a module" is to instead deprecate the all the
nodes/rpcs/notifications in the module.  Kind of ugly, but it's for a
deprecated module, so who care, right?  ;)

I think it is unnecessary. If somebody needs adding such a module to the
data
model, he/she should probably have a reason to do so, such as data
implemented
on the server.

Lada


Kent


--

Hi Rob,

On 9/14/2017 9:37 AM, Robert Wilton wrote:

Hi Kent & Lou,

When do you think that it will be possible to start the adoption

process

on these drafts?

I think that the first two at least would seem to be ready for
adoption.  For the 3rd draft, there still seems to be an open

question

of what to do with the old state tree, but presumably that could be
solved after the draft has been adopted?

I see an update for the third was published yesterday
(https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-02)  that
clarifies the intent is to replace the current modules, and presumably
obsolete 8022.  And now that this intended direction is clear in the
draft we could poll it.

I think this still doesn't address if we need to indicate that the
rfc8022 defined modules are deprecated by some other mechanisms than
just replacing the RFC, e.g., by updating the old modules with all nodes
marked as deprecated.  I think you're right that this could be done post
adoption.  Of course others are free to disagree.

I check with Kent and see what he thinks.

Thanks,
Lou


Thanks,
Rob


On 30/08/2017 00:46, Kent Watsen wrote:

Hey folks,

As discussed at the last meeting, we are heading to revising

existing RFCs

to align them with NMDA.  The first batch have been published as
individual drafts:

1. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7223bis-00
2. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7277bis-00
3. https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-00

Please take a look (comments welcome!) and stay tuned for the

related

adoption calls.

Thanks,
Kent (and Lou)


___
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

--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

___
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] upcoming adoptions

[Acee Lindem (acee)]

Hi, 

With respect to WG adoption, we will do whatever the WG decides for the
RFC 8022 model. We have a strong preference toward not carrying the
deprecated nodes forward and new module versions appears to be a good way
to achieve this. 

I agree with Lada that deprecating all the schema nodes is unnecessary.
However, we’ll do what it takes to reach consensus and satisfy the most
pedantic among us. 

Thanks,
Acee 

On 9/15/17, 6:38 AM, "netmod on behalf of Ladislav Lhotka"
 wrote:

>Kent Watsen píše v Čt 14. 09. 2017 v 14:52 +:
>> rfc8022bis-02 signals the intent to ditch the current/soon-to-be-legacy
>> module, but does it actually say it?  (I can't find it)
>
>The modules contained therein have different names and namespaces, so
>there is
>no formal ancestry. I would prefer to keep the modules from RFC 8022 as
>they are
>- some weirdos may still want to use them.
>
>> 
>> The draft does say that it obsoletes 8022, but I'm unsure if that's
>>going to
>> have a meaningful impact in the wild.  I think Juergen said they had
>>this
>> issue with MIB2 and only after a couple years of misuse did they
>>republish the
>> legacy MIBs with deprecated status.
>> 
>> I'm okay with this change being made after adoption, so long as there's
>> general agreement to do it.  Are the authors okay with it, or are there
>>any
>> better suggestions?
>> 
>> PS: Sadly, the 'module' statement does not have 'status' as a
>>substatement [I
>> just added this omission to the yang-next tracker].  I think the only
>>way to
>> "deprecate a module" is to instead deprecate the all the
>> nodes/rpcs/notifications in the module.  Kind of ugly, but it's for a
>> deprecated module, so who care, right?  ;)
>
>I think it is unnecessary. If somebody needs adding such a module to the
>data
>model, he/she should probably have a reason to do so, such as data
>implemented
>on the server.
>
>Lada  
>
>> 
>> Kent
>> 
>> 
>> --
>> 
>> Hi Rob,
>> 
>> On 9/14/2017 9:37 AM, Robert Wilton wrote:
>> > Hi Kent & Lou,
>> > 
>> > When do you think that it will be possible to start the adoption
>>process 
>> > on these drafts?
>> > 
>> > I think that the first two at least would seem to be ready for
>> > adoption.  For the 3rd draft, there still seems to be an open
>>question 
>> > of what to do with the old state tree, but presumably that could be
>> > solved after the draft has been adopted?
>> 
>> I see an update for the third was published yesterday
>> (https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-02)  that
>> clarifies the intent is to replace the current modules, and presumably
>> obsolete 8022.  And now that this intended direction is clear in the
>> draft we could poll it.
>> 
>> I think this still doesn't address if we need to indicate that the
>> rfc8022 defined modules are deprecated by some other mechanisms than
>> just replacing the RFC, e.g., by updating the old modules with all nodes
>> marked as deprecated.  I think you're right that this could be done post
>> adoption.  Of course others are free to disagree.
>> 
>> I check with Kent and see what he thinks.
>> 
>> Thanks,
>> Lou
>> 
>> > 
>> > Thanks,
>> > Rob
>> > 
>> > 
>> > On 30/08/2017 00:46, Kent Watsen wrote:
>> > > Hey folks,
>> > > 
>> > > As discussed at the last meeting, we are heading to revising
>>existing RFCs
>> > > to align them with NMDA.  The first batch have been published as
>> > > individual drafts:
>> > > 
>> > > 1. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7223bis-00
>> > > 2. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7277bis-00
>> > > 3. https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-00
>> > > 
>> > > Please take a look (comments welcome!) and stay tuned for the
>>related
>> > > adoption calls.
>> > > 
>> > > Thanks,
>> > > Kent (and Lou)
>> > > 
>> > > 
>> > > ___
>> > > 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
>-- 
>Ladislav Lhotka
>Head, CZ.NIC Labs
>PGP Key ID: 0xB8F92B08A9F76C67
>
>___
>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] upcoming adoptions

[Juergen Schoenwaelder]

On Thu, Sep 14, 2017 at 01:06:28PM -0400, Lou Berger wrote:
> 
> Actually, strictly speaking, any text in a Standards Track
> RFC that doesn't include RFC2119 language is just informative.
>

I very doubt this is true. But then, I have seen so many different
interpretations of RFC 2119 language over the years that I personally
believe that RFC 2119 usage is to a large extend random and in most
cases practically pointless.

/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

[Lou Berger]

On 9/14/2017 12:36 PM, t.petch wrote:
> Appendices are Normative if they say that they are Normative.  The
> default is that they are not so say that they are and they are.  This is
> well established practice.

Hi Tom,
    My memory (I haven't checked recently) is there is nothing in or
defined process that says if an Appendix is normative or not.  Other
SDOs certainly have formal definitions here.  Within the IETF, my view
has been that if an appendix includes RFC2119 language, it is
normative.  Actually, strictly speaking, any text in a Standards Track
RFC that doesn't include RFC2119 language is just informative.

Lou
 

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

Re: [netmod] upcoming adoptions

[Acee Lindem (acee)]

Hi Rob, 

On 9/14/17, 9:37 AM, "netmod on behalf of Robert Wilton -X (rwilton -
ENSOFT LIMITED at Cisco)"  wrote:

>Hi Kent & Lou,
>
>When do you think that it will be possible to start the adoption process
>on these drafts?
>
>I think that the first two at least would seem to be ready for
>adoption.  For the 3rd draft, there still seems to be an open question
>of what to do with the old state tree, but presumably that could be
>solved after the draft has been adopted?

This is prefect timing. We discussed this issue at some length in the YANG
Routing Design Team and the course we on is publishing a new model which
is unencumbered from the current ietf-routing model. Refer to:

https://datatracker.ietf.org/doc/draft-acee-netmod-rfc8022bis/

Thanks,
Acee 


>
>Thanks,
>Rob
>
>
>On 30/08/2017 00:46, Kent Watsen wrote:
>> Hey folks,
>>
>> As discussed at the last meeting, we are heading to revising existing
>>RFCs to align them with NMDA.  The first batch have been published as
>>individual drafts:
>>
>> 1. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7223bis-00
>> 2. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7277bis-00
>> 3. https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-00
>>
>> Please take a look (comments welcome!) and stay tuned for the related
>>adoption calls.
>>
>> Thanks,
>> Kent (and Lou)
>>
>>
>> ___
>> 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] upcoming adoptions

[Kent Watsen]

> So rfc8022bis-02 publishes the v2 module, and the the deprecated version 
> of the v1 module as an appendix?

Lou and I were just discussing if appendix can be normative or not.  I always
thought no, but I haven't checked.  This is a grey area, in that understanding
that the old module is deprecating is not needed in order to understand the
new module, and we really just to ensure extraction tools work...


> I see "kind of ugly" as a feature in the this case, someone looking at 
> the updated v1 module isn't going to be able to miss that whatever they 
> are looking at is deprecated. ;-)

Funny, and true


K.


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

Re: [netmod] upcoming adoptions

[Robert Wilton]

On 14/09/2017 15:52, Kent Watsen wrote:

rfc8022bis-02 signals the intent to ditch the current/soon-to-be-legacy module, 
but does it actually say it?  (I can't find it)

The draft does say that it obsoletes 8022, but I'm unsure if that's going to 
have a meaningful impact in the wild.  I think Juergen said they had this issue 
with MIB2 and only after a couple years of misuse did they republish the legacy 
MIBs with deprecated status.
So rfc8022bis-02 publishes the v2 module, and the the deprecated version 
of the v1 module as an appendix?




I'm okay with this change being made after adoption, so long as there's general 
agreement to do it.  Are the authors okay with it, or are there any better 
suggestions?

PS: Sadly, the 'module' statement does not have 'status' as a substatement [I just added 
this omission to the yang-next tracker].  I think the only way to "deprecate a 
module" is to instead deprecate the all the nodes/rpcs/notifications in the module.  
Kind of ugly, but it's for a deprecated module, so who care, right?  ;)
I see "kind of ugly" as a feature in the this case, someone looking at 
the updated v1 module isn't going to be able to miss that whatever they 
are looking at is deprecated. ;-)


Rob




Kent


--

Hi Rob,

On 9/14/2017 9:37 AM, Robert Wilton wrote:

Hi Kent & Lou,

When do you think that it will be possible to start the adoption process
on these drafts?

I think that the first two at least would seem to be ready for
adoption.  For the 3rd draft, there still seems to be an open question
of what to do with the old state tree, but presumably that could be
solved after the draft has been adopted?

I see an update for the third was published yesterday
(https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-02)  that
clarifies the intent is to replace the current modules, and presumably
obsolete 8022.  And now that this intended direction is clear in the
draft we could poll it.

I think this still doesn't address if we need to indicate that the
rfc8022 defined modules are deprecated by some other mechanisms than
just replacing the RFC, e.g., by updating the old modules with all nodes
marked as deprecated.  I think you're right that this could be done post
adoption.  Of course others are free to disagree.

I check with Kent and see what he thinks.

Thanks,
Lou


Thanks,
Rob


On 30/08/2017 00:46, Kent Watsen wrote:

Hey folks,

As discussed at the last meeting, we are heading to revising existing RFCs to 
align them with NMDA.  The first batch have been published as individual drafts:

1. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7223bis-00
2. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7277bis-00
3. https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-00

Please take a look (comments welcome!) and stay tuned for the related adoption 
calls.

Thanks,
Kent (and Lou)


___
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] upcoming adoptions

[Kent Watsen]

rfc8022bis-02 signals the intent to ditch the current/soon-to-be-legacy module, 
but does it actually say it?  (I can't find it)

The draft does say that it obsoletes 8022, but I'm unsure if that's going to 
have a meaningful impact in the wild.  I think Juergen said they had this issue 
with MIB2 and only after a couple years of misuse did they republish the legacy 
MIBs with deprecated status.

I'm okay with this change being made after adoption, so long as there's general 
agreement to do it.  Are the authors okay with it, or are there any better 
suggestions?

PS: Sadly, the 'module' statement does not have 'status' as a substatement [I 
just added this omission to the yang-next tracker].  I think the only way to 
"deprecate a module" is to instead deprecate the all the 
nodes/rpcs/notifications in the module.  Kind of ugly, but it's for a 
deprecated module, so who care, right?  ;)

Kent


--

Hi Rob,

On 9/14/2017 9:37 AM, Robert Wilton wrote:
> Hi Kent & Lou,
>
> When do you think that it will be possible to start the adoption process 
> on these drafts?
>
> I think that the first two at least would seem to be ready for 
> adoption.  For the 3rd draft, there still seems to be an open question 
> of what to do with the old state tree, but presumably that could be 
> solved after the draft has been adopted?
I see an update for the third was published yesterday
(https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-02)  that
clarifies the intent is to replace the current modules, and presumably
obsolete 8022.  And now that this intended direction is clear in the
draft we could poll it.

I think this still doesn't address if we need to indicate that the
rfc8022 defined modules are deprecated by some other mechanisms than
just replacing the RFC, e.g., by updating the old modules with all nodes
marked as deprecated.  I think you're right that this could be done post
adoption.  Of course others are free to disagree.

I check with Kent and see what he thinks.

Thanks,
Lou

>
> Thanks,
> Rob
>
>
> On 30/08/2017 00:46, Kent Watsen wrote:
>> Hey folks,
>>
>> As discussed at the last meeting, we are heading to revising existing RFCs 
>> to align them with NMDA.  The first batch have been published as individual 
>> drafts:
>>
>> 1. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7223bis-00
>> 2. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7277bis-00
>> 3. https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-00
>>
>> Please take a look (comments welcome!) and stay tuned for the related 
>> adoption calls.
>>
>> Thanks,
>> Kent (and Lou)
>>
>>
>> ___
>> 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] upcoming adoptions

[Robert Wilton]

Hi Kent & Lou,

When do you think that it will be possible to start the adoption process 
on these drafts?


I think that the first two at least would seem to be ready for 
adoption.  For the 3rd draft, there still seems to be an open question 
of what to do with the old state tree, but presumably that could be 
solved after the draft has been adopted?


Thanks,
Rob


On 30/08/2017 00:46, Kent Watsen wrote:

Hey folks,

As discussed at the last meeting, we are heading to revising existing RFCs to 
align them with NMDA.  The first batch have been published as individual drafts:

1. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7223bis-00
2. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7277bis-00
3. https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-00

Please take a look (comments welcome!) and stay tuned for the related adoption 
calls.

Thanks,
Kent (and Lou)


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

[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] upcoming adoptions

[Juergen Schoenwaelder]

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.

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

Hi,

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).
First we tell everybody "these are just identifiers, pick any string you
want",
then we want to change it 8 years later to "except these strings which mean
special things".

The proper deterministic way to identify that the module or subtree is
special
is to tag it with a YANG extension. Adding semantics to the user-selected
identifier space
8 years after dozens of exceptions already exist is not a great plan.

If anybody ever actually implements this NMDA stuff, I think they will find
it useful to identify modules written for specific datastore usage, or
if the module is an NMDA transition module, an I2RS-specific module, etc.
The extension you suggested in another email would work.


Andy


On Thu, Sep 7, 2017 at 4:10 AM, Martin Bjorklund  wrote:

> Robert Wilton  wrote:
> >
> >
> > On 07/09/2017 11:15, Martin Bjorklund wrote:
> > > Robert Wilton  wrote:
> > >>
> > >> On 07/09/2017 11:05, Martin Bjorklund wrote:
> > >>> Robert Wilton  wrote:
> >  On 07/09/2017 03:36, Andy Bierman wrote:
> > > On Wed, Sep 6, 2017 at 10:57 AM, Kent Watsen  > > > wrote:
> > >
> > >
> > >
> > >   >> /netconf-state and /restconf-state don't seem to follow
> the
> > >   >> general
> > >   >> pattern we're correcting with the various NMDA updates.
> > >   Particularly,
> > >   >> these -state trees are NOT for the purpose to providing
> the
> > >   >> opstate
> > >   >> value for configured nodes.  These modules have the
> misfortune
> > >   >> of
> > >   >> having "-state" in their name, but they're otherwise fine.
> > >   >
> > >   >
> > >   > This contradicts some details we have been told about NMDA
> > >   >
> > >   > 1) the transition guidelines say otherwise
> > >   >
> > >   > New modules and modules that are not concerned with the
> > >   > operational state of configuration information SHOULD
> > >   > immediately be structured to be NMDA-compatible
> > >
> > >   Yes, I'm suggesting we give ourselves some leeway, by taking
> > >   advantage of the SHOULD keyword above and defer updating
> these
> > >   two modules to when it makes more sense to do so.
> > >
> > >
> > >
> > > OK -- good.
> > > I think another sentence needs to be added.
> > >
> > >
> > > NMDA compatibility conversion MAY be deferred if the module
> > > does not contain any configuration datastore objects.
> >  I agree.
> > >>> +1
> > >>>
> > >>>
> > >   > 2) RD defines operational state to include config=false
> nodes
> > >   > such as counters, so these modules are properly named.
> > >
> > >   module-name == top-level node name.  Either way, my point is
> that
> > >   the -state tree in these modules is not trying to provide the
> > >   opstate value for configured nodes (i.e. applied
> configuration).
> > >
> > >
> > > So a data node naming convention is needed?
> > > And a module naming convention?
> > >
> > > We need a rule that says the suffix "-state" is reserved for NMDA
> > > compatibility
> > > so module names and data nodes SHOULD NOT be named with an
> identifier
> > > that
> > > ends in this suffix.
> >  Also agree.
> > >>> -1
> > >>>
> > >>> There are cases where a -state suffix is natural, e.g. in
> > >>> ietf-hardware we have admin-state, oper-state, usage-state etc.
> > >>>
> > >>> I prefer to have a recommendation that generated modules and
> top-level
> > >>> nodes are called ...-state, but that should not be a reason for
> making
> > >>> -state illegal in general.
> > >> Sorry, it was specifically modules and top level data nodes that I
> > >> think this restriction should apply to.
> > > Even in this case I'd prefer to make a one-way recommendation.  Is
> > > there a technical reason for not allowing a normal module or top-level
> > > node be called ...-state?  IMO, *if* it is important to mark these
> > > modules as being generated, we should use a formal way to convey this
> > > information, not rely on a naming convention.  (i.e., use a YANG
> > > extension in the module).
> > My logic is slightly different:
> >
> > I think that new top level containers shouldn't be called ...-state
> > because either
> > (i) they already contain config nodes, in which case they are
> > misnamed, or
> > (ii) they might be revised to contain config nodes in the future, in
> > which case they would end up being misnamed.
> >
> > I basically, think that the suffix "-state" doesn't generally provide
> > any 

Re: [netmod] upcoming adoptions

[Martin Bjorklund]

Robert Wilton  wrote:
> 
> 
> On 07/09/2017 11:15, Martin Bjorklund wrote:
> > Robert Wilton  wrote:
> >>
> >> On 07/09/2017 11:05, Martin Bjorklund wrote:
> >>> Robert Wilton  wrote:
>  On 07/09/2017 03:36, Andy Bierman wrote:
> > On Wed, Sep 6, 2017 at 10:57 AM, Kent Watsen  > > wrote:
> >
> >
> >
> >   >> /netconf-state and /restconf-state don't seem to follow the
> >   >> general
> >   >> pattern we're correcting with the various NMDA updates.
> >   Particularly,
> >   >> these -state trees are NOT for the purpose to providing the
> >   >> opstate
> >   >> value for configured nodes.  These modules have the misfortune
> >   >> of
> >   >> having "-state" in their name, but they're otherwise fine.
> >   >
> >   >
> >   > This contradicts some details we have been told about NMDA
> >   >
> >   > 1) the transition guidelines say otherwise
> >   >
> >   > New modules and modules that are not concerned with the
> >   > operational state of configuration information SHOULD
> >   > immediately be structured to be NMDA-compatible
> >
> >   Yes, I'm suggesting we give ourselves some leeway, by taking
> >   advantage of the SHOULD keyword above and defer updating these
> >   two modules to when it makes more sense to do so.
> >
> >
> >
> > OK -- good.
> > I think another sentence needs to be added.
> >
> >
> > NMDA compatibility conversion MAY be deferred if the module
> > does not contain any configuration datastore objects.
>  I agree.
> >>> +1
> >>>
> >>>
> >   > 2) RD defines operational state to include config=false nodes
> >   > such as counters, so these modules are properly named.
> >
> >   module-name == top-level node name.  Either way, my point is that
> >   the -state tree in these modules is not trying to provide the
> >   opstate value for configured nodes (i.e. applied configuration).
> >
> >
> > So a data node naming convention is needed?
> > And a module naming convention?
> >
> > We need a rule that says the suffix "-state" is reserved for NMDA
> > compatibility
> > so module names and data nodes SHOULD NOT be named with an identifier
> > that
> > ends in this suffix.
>  Also agree.
> >>> -1
> >>>
> >>> There are cases where a -state suffix is natural, e.g. in
> >>> ietf-hardware we have admin-state, oper-state, usage-state etc.
> >>>
> >>> I prefer to have a recommendation that generated modules and top-level
> >>> nodes are called ...-state, but that should not be a reason for making
> >>> -state illegal in general.
> >> Sorry, it was specifically modules and top level data nodes that I
> >> think this restriction should apply to.
> > Even in this case I'd prefer to make a one-way recommendation.  Is
> > there a technical reason for not allowing a normal module or top-level
> > node be called ...-state?  IMO, *if* it is important to mark these
> > modules as being generated, we should use a formal way to convey this
> > information, not rely on a naming convention.  (i.e., use a YANG
> > extension in the module).
> My logic is slightly different:
> 
> I think that new top level containers shouldn't be called ...-state
> because either
> (i) they already contain config nodes, in which case they are
> misnamed, or
> (ii) they might be revised to contain config nodes in the future, in
> which case they would end up being misnamed.
> 
> I basically, think that the suffix "-state" doesn't generally provide
> any useful extra information.

Sure.  But there are many suffixes that don't generally provide useful
extra information.  I just think we should be careful with these kinds
of rules.  Bad names are hopefully catched during the review process.

> Lower down the tree, I guess that using "state" or  "*-state" is OK if
> it can be known that the leaf/container will *always* only be state
> and never potentially be configurable in future.  But I still think
> that it is necessary to be very careful here.
> 
> For example, If I designed a new routing protocol, then in v1 there
> might be no explicit neighbor configuration, and hence I put all of
> the neighbor information into a container call
> neighbor-state. However, if a v2 version of that protocol (or vendor
> extensions) wants to add some per neighbor configuration then it would
> hit the problem that the original container is poorly named to be
> updated to now also hold configuration.  So, generally avoiding
> "-state" in the name of containers seems to be good common sense to
> me.

I agree.  And avoid "*-config".



/martin


>   I would suggest adding something to 6087bis, but my previous
> suggested additions to 

Re: [netmod] upcoming adoptions

[Robert Wilton]

On 07/09/2017 11:15, Martin Bjorklund wrote:

Robert Wilton  wrote:


On 07/09/2017 11:05, Martin Bjorklund wrote:

Robert Wilton  wrote:

On 07/09/2017 03:36, Andy Bierman wrote:

On Wed, Sep 6, 2017 at 10:57 AM, Kent Watsen > wrote:



  >> /netconf-state and /restconf-state don't seem to follow the
  >> general
  >> pattern we're correcting with the various NMDA updates.
  Particularly,
  >> these -state trees are NOT for the purpose to providing the
  >> opstate
  >> value for configured nodes.  These modules have the misfortune of
  >> having "-state" in their name, but they're otherwise fine.
  >
  >
  > This contradicts some details we have been told about NMDA
  >
  > 1) the transition guidelines say otherwise
  >
  > New modules and modules that are not concerned with the
  > operational state of configuration information SHOULD
  > immediately be structured to be NMDA-compatible

  Yes, I'm suggesting we give ourselves some leeway, by taking
  advantage of the SHOULD keyword above and defer updating these
  two modules to when it makes more sense to do so.



OK -- good.
I think another sentence needs to be added.


NMDA compatibility conversion MAY be deferred if the module
does not contain any configuration datastore objects.

I agree.

+1



  > 2) RD defines operational state to include config=false nodes
  > such as counters, so these modules are properly named.

  module-name == top-level node name.  Either way, my point is that
  the -state tree in these modules is not trying to provide the
  opstate value for configured nodes (i.e. applied configuration).


So a data node naming convention is needed?
And a module naming convention?

We need a rule that says the suffix "-state" is reserved for NMDA
compatibility
so module names and data nodes SHOULD NOT be named with an identifier
that
ends in this suffix.

Also agree.

-1

There are cases where a -state suffix is natural, e.g. in
ietf-hardware we have admin-state, oper-state, usage-state etc.

I prefer to have a recommendation that generated modules and top-level
nodes are called ...-state, but that should not be a reason for making
-state illegal in general.

Sorry, it was specifically modules and top level data nodes that I
think this restriction should apply to.

Even in this case I'd prefer to make a one-way recommendation.  Is
there a technical reason for not allowing a normal module or top-level
node be called ...-state?  IMO, *if* it is important to mark these
modules as being generated, we should use a formal way to convey this
information, not rely on a naming convention.  (i.e., use a YANG
extension in the module).

My logic is slightly different:

I think that new top level containers shouldn't be called ...-state 
because either

(i) they already contain config nodes, in which case they are misnamed, or
(ii) they might be revised to contain config nodes in the future, in 
which case they would end up being misnamed.


I basically, think that the suffix "-state" doesn't generally provide 
any useful extra information.


Lower down the tree, I guess that using "state" or  "*-state" is OK if 
it can be known that the leaf/container will *always* only be state and 
never potentially be configurable in future.  But I still think that it 
is necessary to be very careful here.


For example, If I designed a new routing protocol, then in v1 there 
might be no explicit neighbor configuration, and hence I put all of the 
neighbor information into a container call neighbor-state. However, if a 
v2 version of that protocol (or vendor extensions) wants to add some per 
neighbor configuration then it would hit the problem that the original 
container is poorly named to be updated to now also hold configuration.  
So, generally avoiding "-state" in the name of containers seems to be 
good common sense to me.  I would suggest adding something to 6087bis, 
but my previous suggested additions to 6087bis didn't appear to be well 
received ;-)


Thanks,
Rob




/martin
.



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

Re: [netmod] upcoming adoptions

[Robert Wilton]

On 07/09/2017 11:05, Martin Bjorklund wrote:

Robert Wilton  wrote:


On 07/09/2017 03:36, Andy Bierman wrote:


On Wed, Sep 6, 2017 at 10:57 AM, Kent Watsen > wrote:



 >> /netconf-state and /restconf-state don't seem to follow the general
 >> pattern we're correcting with the various NMDA updates.
 Particularly,
 >> these -state trees are NOT for the purpose to providing the opstate
 >> value for configured nodes.  These modules have the misfortune of
 >> having "-state" in their name, but they're otherwise fine.
 >
 >
 > This contradicts some details we have been told about NMDA
 >
 > 1) the transition guidelines say otherwise
 >
 > New modules and modules that are not concerned with the
 > operational state of configuration information SHOULD
 > immediately be structured to be NMDA-compatible

 Yes, I'm suggesting we give ourselves some leeway, by taking
 advantage of the SHOULD keyword above and defer updating these
 two modules to when it makes more sense to do so.



OK -- good.
I think another sentence needs to be added.


NMDA compatibility conversion MAY be deferred if the module
does not contain any configuration datastore objects.

I agree.

+1



 > 2) RD defines operational state to include config=false nodes
 > such as counters, so these modules are properly named.

 module-name == top-level node name.  Either way, my point is that
 the -state tree in these modules is not trying to provide the
 opstate value for configured nodes (i.e. applied configuration).


So a data node naming convention is needed?
And a module naming convention?

We need a rule that says the suffix "-state" is reserved for NMDA
compatibility
so module names and data nodes SHOULD NOT be named with an identifier
that
ends in this suffix.

Also agree.

-1

There are cases where a -state suffix is natural, e.g. in
ietf-hardware we have admin-state, oper-state, usage-state etc.

I prefer to have a recommendation that generated modules and top-level
nodes are called ...-state, but that should not be a reason for making
-state illegal in general.
Sorry, it was specifically modules and top level data nodes that I think 
this restriction should apply to.


Thanks,
Rob





/martin
.



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

Re: [netmod] upcoming adoptions

[Martin Bjorklund]

Robert Wilton  wrote:
> 
> 
> On 07/09/2017 03:36, Andy Bierman wrote:
> >
> >
> > On Wed, Sep 6, 2017 at 10:57 AM, Kent Watsen  > > wrote:
> >
> >
> >
> > >> /netconf-state and /restconf-state don't seem to follow the general
> > >> pattern we're correcting with the various NMDA updates. 
> > Particularly,
> > >> these -state trees are NOT for the purpose to providing the opstate
> > >> value for configured nodes.  These modules have the misfortune of
> > >> having "-state" in their name, but they're otherwise fine.
> > >
> > >
> > > This contradicts some details we have been told about NMDA
> > >
> > > 1) the transition guidelines say otherwise
> > >
> > > New modules and modules that are not concerned with the
> > > operational state of configuration information SHOULD
> > > immediately be structured to be NMDA-compatible
> >
> > Yes, I'm suggesting we give ourselves some leeway, by taking
> > advantage of the SHOULD keyword above and defer updating these
> > two modules to when it makes more sense to do so.
> >
> >
> >
> > OK -- good.
> > I think another sentence needs to be added.
> >
> >
> > NMDA compatibility conversion MAY be deferred if the module
> > does not contain any configuration datastore objects.
> I agree.

+1


> > > 2) RD defines operational state to include config=false nodes
> > > such as counters, so these modules are properly named.
> >
> > module-name == top-level node name.  Either way, my point is that
> > the -state tree in these modules is not trying to provide the
> > opstate value for configured nodes (i.e. applied configuration).
> >
> >
> > So a data node naming convention is needed?
> > And a module naming convention?
> >
> > We need a rule that says the suffix "-state" is reserved for NMDA
> > compatibility
> > so module names and data nodes SHOULD NOT be named with an identifier
> > that
> > ends in this suffix.
> Also agree.

-1

There are cases where a -state suffix is natural, e.g. in
ietf-hardware we have admin-state, oper-state, usage-state etc.

I prefer to have a recommendation that generated modules and top-level
nodes are called ...-state, but that should not be a reason for making
-state illegal in general.


/martin

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

Re: [netmod] upcoming adoptions

[Robert Wilton]

On 07/09/2017 03:36, Andy Bierman wrote:



On Wed, Sep 6, 2017 at 10:57 AM, Kent Watsen > wrote:




>> /netconf-state and /restconf-state don't seem to follow the general
>> pattern we're correcting with the various NMDA updates. 
Particularly,
>> these -state trees are NOT for the purpose to providing the opstate
>> value for configured nodes.  These modules have the misfortune of
>> having "-state" in their name, but they're otherwise fine.
>
>
> This contradicts some details we have been told about NMDA
>
> 1) the transition guidelines say otherwise
>
> New modules and modules that are not concerned with the
> operational state of configuration information SHOULD
> immediately be structured to be NMDA-compatible

Yes, I'm suggesting we give ourselves some leeway, by taking
advantage of the SHOULD keyword above and defer updating these
two modules to when it makes more sense to do so.



OK -- good.
I think another sentence needs to be added.


NMDA compatibility conversion MAY be deferred if the module
does not contain any configuration datastore objects.

I agree.





> 2) RD defines operational state to include config=false nodes
> such as counters, so these modules are properly named.

module-name == top-level node name.  Either way, my point is that
the -state tree in these modules is not trying to provide the
opstate value for configured nodes (i.e. applied configuration).


So a data node naming convention is needed?
And a module naming convention?

We need a rule that says the suffix "-state" is reserved for NMDA 
compatibility

so module names and data nodes SHOULD NOT be named with an identifier that
ends in this suffix.

Also agree.

Thanks,
Rob




(Automation tools like deterministic rules, not naming conventions.
Here is an example why... there are always exceptions that do not follow
the conventions. Always people who are unaware of the conventions.)



K.




Andy



___
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] upcoming adoptions

[Andy Bierman]

On Wed, Sep 6, 2017 at 10:57 AM, Kent Watsen  wrote:

>
>
> >> /netconf-state and /restconf-state don't seem to follow the general
> >> pattern we're correcting with the various NMDA updates.  Particularly,
> >> these -state trees are NOT for the purpose to providing the opstate
> >> value for configured nodes.  These modules have the misfortune of
> >> having "-state" in their name, but they're otherwise fine.
> >
> >
> > This contradicts some details we have been told about NMDA
> >
> > 1) the transition guidelines say otherwise
> >
> > New modules and modules that are not concerned with the
> > operational state of configuration information SHOULD
> > immediately be structured to be NMDA-compatible
>
> Yes, I'm suggesting we give ourselves some leeway, by taking
> advantage of the SHOULD keyword above and defer updating these
> two modules to when it makes more sense to do so.
>
>

OK -- good.
I think another sentence needs to be added.


NMDA compatibility conversion MAY be deferred if the module
does not contain any configuration datastore objects.



> > 2) RD defines operational state to include config=false nodes
> > such as counters, so these modules are properly named.
>
> module-name == top-level node name.  Either way, my point is that
> the -state tree in these modules is not trying to provide the
> opstate value for configured nodes (i.e. applied configuration).
>
>
So a data node naming convention is needed?
And a module naming convention?

We need a rule that says the suffix "-state" is reserved for NMDA
compatibility
so module names and data nodes SHOULD NOT be named with an identifier that
ends in this suffix.

(Automation tools like deterministic rules, not naming conventions.
Here is an example why... there are always exceptions that do not follow
the conventions. Always people who are unaware of the conventions.)




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

Re: [netmod] upcoming adoptions

[Kent Watsen]

>> /netconf-state and /restconf-state don't seem to follow the general
>> pattern we're correcting with the various NMDA updates.  Particularly,
>> these -state trees are NOT for the purpose to providing the opstate
>> value for configured nodes.  These modules have the misfortune of
>> having "-state" in their name, but they're otherwise fine.
>
>
> This contradicts some details we have been told about NMDA
> 
> 1) the transition guidelines say otherwise
> 
> New modules and modules that are not concerned with the
> operational state of configuration information SHOULD
> immediately be structured to be NMDA-compatible

Yes, I'm suggesting we give ourselves some leeway, by taking
advantage of the SHOULD keyword above and defer updating these
two modules to when it makes more sense to do so.


> 2) RD defines operational state to include config=false nodes
> such as counters, so these modules are properly named.

module-name == top-level node name.  Either way, my point is that
the -state tree in these modules is not trying to provide the 
opstate value for configured nodes (i.e. applied configuration).  


K.



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

Re: [netmod] upcoming adoptions

[Andy Bierman]

On Wed, Sep 6, 2017 at 6:11 AM, Kent Watsen  wrote:

> >> I guess the NMDA transition plan to move the child nodes to a
> config=true
> >> node
> >> name /restconf that has only config=false nodes in it.  This seems quite
> >> disruptive
> >> and not a productive use of engineering resources, or support and
> customer
> >> re-training.
> >
> > I agree with you.  We've said that it is ok to have pure config false
> > trees, if it makes sense for what we're trying to model.
> >
> > The only "issue" with the tree above is that its top-level node's name
> > contains the word "state".
>
> /netconf-state and /restconf-state don't seem to follow the general
> pattern we're correcting with the various NMDA updates.  Particularly,
> these -state trees are NOT for the purpose to providing the opstate
> value for configured nodes.  These modules have the misfortune of
> having "-state" in their name, but they're otherwise fine.
>
>

This contradicts some details we have been told about NMDA

1) the transition guidelines say otherwise

New modules and modules that are not concerned with the
operational state of configuration information SHOULD
immediately be structured to be NMDA-compatible


2) RD defines operational state to include config=false nodes such as
counters,
so these modules are properly named.



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

Re: [netmod] upcoming adoptions

[Kent Watsen]

>> I guess the NMDA transition plan to move the child nodes to a config=true
>> node
>> name /restconf that has only config=false nodes in it.  This seems quite
>> disruptive
>> and not a productive use of engineering resources, or support and customer
>> re-training.
>
> I agree with you.  We've said that it is ok to have pure config false
> trees, if it makes sense for what we're trying to model.
>
> The only "issue" with the tree above is that its top-level node's name
> contains the word "state".

/netconf-state and /restconf-state don't seem to follow the general 
pattern we're correcting with the various NMDA updates.  Particularly,
these -state trees are NOT for the purpose to providing the opstate
value for configured nodes.  These modules have the misfortune of
having "-state" in their name, but they're otherwise fine.

K.  // contributor



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

Re: [netmod] upcoming adoptions

[Martin Bjorklund]

Andy Bierman  wrote:
> On Tue, Sep 5, 2017 at 12:59 AM, Martin Bjorklund  wrote:
> 
> > Benoit Claise  wrote:
> > > Kent,
> > > > Hey folks,
> > > >
> > > > As discussed at the last meeting, we are heading to revising existing
> > > > RFCs to align them with NMDA.  The first batch have been published as
> > > > individual drafts:
> > > >
> > > > 1. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7223bis-00
> > > > 2. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7277bis-00
> > > > 3. https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-00
> > > Good. And there is one more in for NETMOD, as discussed in
> > > https://datatracker.ietf.org/meeting/99/materials/slides-
> > 99-netmod-sessa-nmda-qa:
> > > RFC 7317
> > > In NETCONF, we have also:
> > > RFC 6022, no I-D submitted yet
> >
> > I don't think this one requires an update at this time.  *If* it is
> > changed, it might be worthwhile to remove definitions already covered
> > by yang-library, and probably align with the netconf server model.
> >
> > > RFC 7895, already adopted
> > > RFC 8040, no I-D submitted yet. No immediate plan to update?
> >
> > We have draft-ietf-netconf-nmda-restconf-00 which "Updates: 8040".
> >
> >
> 
> This draft does not address ietf-restconf-monitoring.

Correct.  See below.

>
>YANG tree diagram for the "ietf-restconf-monitoring" module:
> 
>   +--ro restconf-state
>  +--ro capabilities
>  |  +--ro capability*   inet:uri
>  +--ro streams
> +--ro stream* [name]
>+--ro namestring
>+--ro description?string
>+--ro replay-support? boolean
>+--ro replay-log-creation-time?   yang:date-and-time
>+--ro access* [encoding]
>   +--ro encoding  string
>   +--ro location  inet:uri
> 
> 
> I guess the NMDA transition plan to move the child nodes to a config=true
> node
> name /restconf that has only config=false nodes in it.  This seems quite
> disruptive
> and not a productive use of engineering resources, or support and customer
> re-training.

I agree with you.  We've said that it is ok to have pure config false
trees, if it makes sense for what we're trying to model.

The only "issue" with the tree above is that its top-level node's name
contains the word "state".

But OTOH, maybe we need to revisit this model for the upcoming new
notification work anyway.  It has a new defintiion of streams, so at
least we need to deprecate the /restconf-state/streams contianer.


/martin



> The /netconf-state container is the same, and many more just like it.
> 
> NEW:
> 
>  +--rw restconf
>  +--ro capabilities
>  |  +--ro capability*   inet:uri
>  +--ro streams
> +--ro stream* [name]
>+--ro namestring
>+--ro description?string
>+--ro replay-support? boolean
>+--ro replay-log-creation-time?   yang:date-and-time
>+--ro access* [encoding]
>   +--ro encoding  string
>   +--ro location  inet:uri
> 
> (+ old tree, but deprecated)
> 
> I doubt vendors will prioritize this high-impact/low-value upgrade, so
> the deprecated foo-state trees will be needed for many years.
> 
> 
> > /martin
> >
> 
> Andy
> 
> 
> >
> > ___
> > 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] upcoming adoptions

[Andy Bierman]

On Tue, Sep 5, 2017 at 12:59 AM, Martin Bjorklund  wrote:

> Benoit Claise  wrote:
> > Kent,
> > > Hey folks,
> > >
> > > As discussed at the last meeting, we are heading to revising existing
> > > RFCs to align them with NMDA.  The first batch have been published as
> > > individual drafts:
> > >
> > > 1. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7223bis-00
> > > 2. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7277bis-00
> > > 3. https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-00
> > Good. And there is one more in for NETMOD, as discussed in
> > https://datatracker.ietf.org/meeting/99/materials/slides-
> 99-netmod-sessa-nmda-qa:
> > RFC 7317
> > In NETCONF, we have also:
> > RFC 6022, no I-D submitted yet
>
> I don't think this one requires an update at this time.  *If* it is
> changed, it might be worthwhile to remove definitions already covered
> by yang-library, and probably align with the netconf server model.
>
> > RFC 7895, already adopted
> > RFC 8040, no I-D submitted yet. No immediate plan to update?
>
> We have draft-ietf-netconf-nmda-restconf-00 which "Updates: 8040".
>
>

This draft does not address ietf-restconf-monitoring.

   YANG tree diagram for the "ietf-restconf-monitoring" module:

  +--ro restconf-state
 +--ro capabilities
 |  +--ro capability*   inet:uri
 +--ro streams
+--ro stream* [name]
   +--ro namestring
   +--ro description?string
   +--ro replay-support? boolean
   +--ro replay-log-creation-time?   yang:date-and-time
   +--ro access* [encoding]
  +--ro encoding  string
  +--ro location  inet:uri


I guess the NMDA transition plan to move the child nodes to a config=true
node
name /restconf that has only config=false nodes in it.  This seems quite
disruptive
and not a productive use of engineering resources, or support and customer
re-training.
The /netconf-state container is the same, and many more just like it.

NEW:

 +--rw restconf
 +--ro capabilities
 |  +--ro capability*   inet:uri
 +--ro streams
+--ro stream* [name]
   +--ro namestring
   +--ro description?string
   +--ro replay-support? boolean
   +--ro replay-log-creation-time?   yang:date-and-time
   +--ro access* [encoding]
  +--ro encoding  string
  +--ro location  inet:uri

(+ old tree, but deprecated)

I doubt vendors will prioritize this high-impact/low-value upgrade, so
the deprecated foo-state trees will be needed for many years.


> /martin
>

Andy


>
> ___
> 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] upcoming adoptions

[Martin Bjorklund]

Benoit Claise  wrote:
> Kent,
> > Hey folks,
> >
> > As discussed at the last meeting, we are heading to revising existing
> > RFCs to align them with NMDA.  The first batch have been published as
> > individual drafts:
> >
> > 1. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7223bis-00
> > 2. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7277bis-00
> > 3. https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-00
> Good. And there is one more in for NETMOD, as discussed in
> https://datatracker.ietf.org/meeting/99/materials/slides-99-netmod-sessa-nmda-qa:
> RFC 7317
> In NETCONF, we have also:
>     RFC 6022, no I-D submitted yet

I don't think this one requires an update at this time.  *If* it is
changed, it might be worthwhile to remove definitions already covered
by yang-library, and probably align with the netconf server model.

>     RFC 7895, already adopted
>     RFC 8040, no I-D submitted yet. No immediate plan to update?

We have draft-ietf-netconf-nmda-restconf-00 which "Updates: 8040".


/martin

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

Re: [netmod] upcoming adoptions

[Martin Bjorklund]

"Acee Lindem (acee)"  wrote:
> Hi Martin, 
> 
> On 8/30/17, 6:28 AM, "Martin Bjorklund"  wrote:
> 
> >Hi,
> >
> >Kent Watsen  wrote:
> >> 3. https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-00
> >
> >I found some trivial errors in this draft:
> >
> >  o  The revision for ietf-routing doesn't match the filename's date.
> >
> >  o  The filename for ietf-ipv6-router-advertisements is wrong (last
> > "s" is missing)
> >
> >  o  All the old -state definitions are removed, rather than being
> > marked as "deprecated".
> 
> 
> I’m glad you brought this up. We discussed this in the Routing YANG Design
> Team and were planning to discuss it on a wide scale.
> 
> One of the advantages of the NMDA is that it makes the models easier to
> read and consume. This is somewhat negated if we have to retain all these
> data nodes in the associated modules and mark them as “deprecated”. What
> is the consequence of not including them? They are available in the
> previous version of the model if they are need for compatibility.

It is fairly common that instead of removing functions from a
published API, you mark them as deprecated for some time, and then,
later, remove them (*).

Note that since a server cannot implement two versions of a given
module, it has to decide which version to implement.  There might be
other modules that use / augment the -state tree; if the server
implements the latest version w/o the -state tree, it cannot at the
same time implement these augmenting modules.

(*) YANG inherits the deprecation model from SMIv2.  We actually have
three states: current -> deprecated -> obsolete.  And even when
something is obsolete, it is not removed.  I guess in SMIv2 this was
necessary b/c of OID assignments; maybe this could be revisited for
YANG.  But this would require an update to RFC 7950.


If we think that a module becomes cluttered with all the deprecated
definitions, we can actually move them all to a separate submodule.


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

Re: [netmod] upcoming adoptions

[Acee Lindem (acee)]

Hi Martin, 

On 8/30/17, 6:28 AM, "Martin Bjorklund"  wrote:

>Hi,
>
>Kent Watsen  wrote:
>> 3. https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-00
>
>I found some trivial errors in this draft:
>
>  o  The revision for ietf-routing doesn't match the filename's date.
>
>  o  The filename for ietf-ipv6-router-advertisements is wrong (last
> "s" is missing)
>
>  o  All the old -state definitions are removed, rather than being
> marked as "deprecated".


I’m glad you brought this up. We discussed this in the Routing YANG Design
Team and were planning to discuss it on a wide scale.

One of the advantages of the NMDA is that it makes the models easier to
read and consume. This is somewhat negated if we have to retain all these
data nodes in the associated modules and mark them as “deprecated”. What
is the consequence of not including them? They are available in the
previous version of the model if they are need for compatibility.

Thanks,
Acee 


>
>
>/martin

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

Re: [netmod] upcoming adoptions

[Martin Bjorklund]

Hi,

Kent Watsen  wrote:
> 3. https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-00

I found some trivial errors in this draft:

  o  The revision for ietf-routing doesn't match the filename's date.

  o  The filename for ietf-ipv6-router-advertisements is wrong (last
 "s" is missing)

  o  All the old -state definitions are removed, rather than being
 marked as "deprecated".


/martin

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