Subject: Re: [netmod] upcoming adoptions

From: Benoit Claise <[email-masked]>
Date: Tue, 5 Sep 2017 09:12:30 +0200

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
     RFC 7895, already adopted
     RFC 8040, no I-D submitted yet. No immediate plan to update?
>
> Please take a look (comments welcome!) and stay tuned for the related adoption calls.
Yes, we know that we have to update those RFCs.

Regards, Benoit
>
> Thanks,
> Kent (and Lou)
>
>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
> .
>

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 05 Sep 2017 09:59:49 +0200 (CEST)

Benoit Claise <[email-masked]> 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:
> >

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 8040, no I-D submitted yet. No immediate plan to update?

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

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 5 Sep 2017 16:05:28 -0700

> 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 name                        string
               +--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 name                        string
               +--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

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 06 Sep 2017 08:41:24 +0200 (CEST)

> This draft does not address ietf-restconf-monitoring.

Correct.  See below.

> and not a productive use of engineering resources, or support and customer

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

---

From: Kent Watsen <[email-masked]>
Date: Wed, 6 Sep 2017 13:11:51 +0000

> 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

---

From: Andy Bierman <[email-masked]>
Date: Wed, 6 Sep 2017 08:24:48 -0700

> 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

---

From: Kent Watsen <[email-masked]>
Date: Wed, 6 Sep 2017 17:57:06 +0000

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

---

From: Andy Bierman <[email-masked]>
Date: Wed, 6 Sep 2017 19:36:28 -0700

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

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

Andy

---

From: Robert Wilton <[email-masked]>
Date: Thu, 7 Sep 2017 10:35:25 +0100

On 07/09/2017 03:36, Andy Bierman wrote:
>
>
> On Wed, Sep 6, 2017 at 10:57 AM, Kent Watsen <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>
I agree.

> so module names and data nodes SHOULD NOT be named with an identifier that
Also agree.

Thanks,
Rob

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 07 Sep 2017 12:05:35 +0200 (CEST)

> > does not contain any configuration datastore objects.

+1

> > so module names and data nodes SHOULD NOT be named with an identifier

-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

---

From: Robert Wilton <[email-masked]>
Date: Thu, 7 Sep 2017 11:14:01 +0100

> -state illegal in general.
Sorry, it was specifically modules and top level data nodes that I think 
this restriction should apply to.

Thanks,
Rob

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 07 Sep 2017 12:15:47 +0200 (CEST)

Robert Wilton <[email-masked]> wrote:
> 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).

/martin

---

From: Robert Wilton <[email-masked]>
Date: Thu, 7 Sep 2017 11:51:56 +0100

> 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

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 07 Sep 2017 13:10:48 +0200 (CEST)

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

> 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.
> 
> 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 6087bis didn't appear to be well received ;-)

---

From: Andy Bierman <[email-masked]>
Date: Thu, 7 Sep 2017 10:51:54 -0700

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 <[email-masked]> wrote:

> > >>>>>       >> /netconf-state and /restconf-state don't seem to follow
> the
> > >>>>>       >> general
> > >>>>>       >> these -state trees are NOT for the purpose to providing
> the
> > >>>>>       >> opstate
> > >>>>>       >> value for configured nodes.  These modules have the
> misfortune
> > >>>>>       >> of
> > >>>>> so module names and data nodes SHOULD NOT be named with an
> identifier
> > >>>>> that
> > >>>>> ends in this suffix.
> > >>>> Also agree.
> > >>> -1
> > >>>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 7 Sep 2017 23:23:17 +0200

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         <http://www.jacobs-university.de/>

---

From: Robert Wilton <[email-masked]>
Date: Fri, 8 Sep 2017 11:17:10 +0100

>> But this is a really bad idea (and slippery slope).
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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 8 Sep 2017 12:56:48 +0200

> 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

---

From: Robert Wilton <[email-masked]>
Date: Fri, 8 Sep 2017 13:19:03 +0100

> over time a problem. There is quite some experience with this.
In the same vane, I think that you could regard RFC 6087 and 6087bis as 
one long list of CLRs ...

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

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

Thanks,
Rob

---

From: Andy Bierman <[email-masked]>
Date: Fri, 8 Sep 2017 05:19:38 -0700

> 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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 8 Sep 2017 14:38:53 +0200

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

---

From: Robert Wilton <[email-masked]>
Date: Fri, 8 Sep 2017 14:41:43 +0100

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

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

> 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

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 08 Sep 2017 16:23:59 +0200

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

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:

Ex2:

Ex3:

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 8 Sep 2017 16:24:46 +0200

On Fri, Sep 08, 2017 at 02:41:43PM +0100, Robert Wilton wrote:
> 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
> 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.

> 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

---

From: Robert Wilton <[email-masked]>
Date: Fri, 8 Sep 2017 16:22:31 +0100

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

---

From: Andy Bierman <[email-masked]>
Date: Fri, 8 Sep 2017 10:00:16 -0700

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 <[email-masked]> wrote:

> 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?
>
> usage of Xpath to a much smaller subset that makes sense, but that should
> be done in 7950bis rather than 6087bis.]
>
> using RFC 2119 language precisely so that it can't be subsequently
> 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
>
>
>
>

---

From: Robert Wilton <[email-masked]>
Date: Thu, 14 Sep 2017 14:37:44 +0100

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

---

From: Lou Berger <[email-masked]>
Date: Thu, 14 Sep 2017 09:49:48 -0400

Hi Rob,

> 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

---

From: Kent Watsen <[email-masked]>
Date: Thu, 14 Sep 2017 14:52:32 +0000

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,

Thanks,
Lou

---

From: Robert Wilton <[email-masked]>
Date: Thu, 14 Sep 2017 16:02:38 +0100

> 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…
So rfc8022bis-02 publishes the v2 module, and the the deprecated version 
of the v1 module as an appendix?

> 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 depreca…
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

---

From: Kent Watsen <[email-masked]>
Date: Thu, 14 Sep 2017 15:11:31 +0000

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

> are looking at is deprecated. ;-)

Funny, and true

K.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 14 Sep 2017 15:39:26 +0000

Hi Rob, 

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

>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

---

From: "t.petch" <[email-masked]>
Date: Thu, 14 Sep 2017 17:36:12 +0100

----- Original Message -----
From: "Kent Watsen" <[email-masked]>
Subject: Re: [netmod] upcoming adoptions

> new module, and we really just to ensure extraction tools work...

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.

Toim Petch

---

From: Lou Berger <[email-masked]>
Date: Thu, 14 Sep 2017 13:06:28 -0400

> 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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 14 Sep 2017 21:51:12 +0200

On Thu, Sep 14, 2017 at 01:06:28PM -0400, Lou Berger wrote:
> 
> Actually, strictly speaking, any text in a Standards Track

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 15 Sep 2017 12:38:29 +0200

Kent Watsen píše v Čt 14. 09. 2017 v 14:52 +0000:
> 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  

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

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 15 Sep 2017 14:52:45 +0000

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"
<[email-masked] on behalf of [email-masked]> wrote:

>> > > Please take a look (comments welcome!) and stay tuned for the
>>related
>> > > adoption calls.
>> > > 
>> > > Thanks,
>> > > Kent (and Lou)
>> > > 
>> > >

---

From: Robert Wilton <[email-masked]>
Date: Fri, 15 Sep 2017 16:01:58 +0100

> deprecated nodes forward and new module versions appears to be a good way
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

---

From: Andy Bierman <[email-masked]>
Date: Fri, 15 Sep 2017 08:23:38 -0700

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 <[email-masked]> wrote:

> 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.
>
> bis draft that (i) provides the correct NDMA combined tree (ii) removes or
> deprecates the old state nodes :-)
>
>>>>> When do you think that it will be possible to start the adoption
>>>>>
>>>> process
>>>>
>>>>> on these drafts?
>>>>>
>>>>> adoption.  For the 3rd draft, there still seems to be an open
>>>>>
>>>> question
>>>>
>>>>>> As discussed at the last meeting, we are heading to revising
>>>>>>
>>>>> existing RFCs
>>>>

---

From: Robert Wilton <[email-masked]>
Date: Fri, 15 Sep 2017 17:02:33 +0100

> 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 <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>
>     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 :-)
>
>         <[email-masked] <mailto:[email-masked]> on
>         behalf of [email-masked] <mailto:[email-masked]>> wrote:
>
>             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
>                 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
>                 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
>             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,
>
>                 (https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-02
>                 <https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-02>)
>                 that
>                         1.
>                         https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7223bis-00
>                         <https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7223bis-00>
>                         2.
>                         https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7277bis-00
>                         <https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7277bis-00>
>                         3.
>                         https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-00
>                         <https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-00>
>
>                         [email-masked] <mailto:[email-masked]>
>                         <https://www.ietf.org/mailman/listinfo/netmod>
>                         .
>
>
>
>                 [email-masked] <mailto:[email-masked]>
>                 <https://www.ietf.org/mailman/listinfo/netmod>
>
>             -- 
>             Ladislav Lhotka
>             Head, CZ.NIC Labs
>             [email-masked] <mailto:[email-masked]>
>             <https://www.ietf.org/mailman/listinfo/netmod>
>
>         [email-masked] <mailto:[email-masked]>
>         <https://www.ietf.org/mailman/listinfo/netmod>
>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/netmod>
>
>

---

From: "t.petch" <[email-masked]>
Date: Fri, 15 Sep 2017 17:28:50 +0100

----- Original Message -----
From: "Lou Berger" <[email-masked]>
Sent: Thursday, September 14, 2017 6:06 PM

Lou

Try RFC4910.

'   This appendix is normative. '

and not a SHOULD or a MUST in sight.

Tom Petch

---

From: Andy Bierman <[email-masked]>
Date: Fri, 15 Sep 2017 09:30:54 -0700

On Fri, Sep 15, 2017 at 9:02 AM, Robert Wilton <[email-masked]> wrote:

> 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.
>
> going to be around for a long time even if very few people ever implement
> the deprecated nodes.
>
>
> 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.
>
> 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

---

From: Kent Watsen <[email-masked]>
Date: Fri, 15 Sep 2017 16:44:02 +0000

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 18 Sep 2017 11:19:52 +0200

> IMO you need to republish the old module as well, with everything status

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

---

From: Lou Berger <[email-masked]>
Date: Mon, 18 Sep 2017 09:42:30 -0400

Hi Tom.

    A few observations:

> 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