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

From: Benoit Claise <[email-masked]>
Date: Mon, 2 Oct 2017 11:10:47 +0200

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" <[email-masked]>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
> .
>

---

From: Lou Berger <[email-masked]>
Date: Mon, 02 Oct 2017 06:39:35 -0400

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 2 Oct 2017 13:05:04 +0200

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

-- 
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: Lou Berger <[email-masked]>
Date: Mon, 2 Oct 2017 07:58:47 -0400

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

---

From: Benoit Claise <[email-masked]>
Date: Mon, 2 Oct 2017 15:08:45 +0200

Dear all,

[including the routing and multicast YANG design teams]
Can we please finalize the discussion regarding ietf-routing versus 
ietf-routing-2, sooner than later.

I care about the NMDA transition strategy.

Here are all the ietf-routing dependent YANG modules (those modules that 
depend on ietf-routing)
https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-routing&recurse=0&rfcs=1&show_subm=1&show_dir=dependents
So many YANG modules.

Look at the difference for ietf-routing-2:
https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-routing-2&recurse=0&rfcs=1&show_subm=1&show_dir=dependents
Some dependent modules are compliant with ietf-routing-2, the multicast 
YANG modules, but these are the only ones.

Changing the module name from ietf-routing to ietf-routing-2 implies 
that the we have to warn all draft authors of ietf-routing YANG 
dependent modules:
     1. to make sure they are aware of ietf-routing-2  (publishing a 
RFC8022bis mentioning in the module description that this module is not 
compatible with the NMDA architecture, and providing a pointer to 
ietf-routing-2 ... is not an automatic way... so barely useful)
     2. to ask them to change their import to ietf-routing-2
Hopefully, in the routing case, it's mainly the IETF.
I'm glad that we didn't change the ietf-interfaces to ietf-interfaces-2, 
we would have to deal with cross SDO/consortia/opensource project issues
Note:

    we're in a transition phase today, while we implement the
    soon-to-be-published draft-clacla-netmod-model-catalog-02
    Because of this, the SDO/consortia/opensource dependent YANG modules
    will only appear in the Impact Analysis tomorrow at
    https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-interfaces&recurse=0&rfcs=1&show_subm=1&show_dir=dependents
    In the mean time, you can see all these dependent modules
    Ex:
    https://www.yangcatalog.org/yang-search/module_details.php?module=ietf-interfaces
             => click on "dependents"
    Those dependent modules is a new feature of
    draft-clacla-netmod-model-catalog-02

I'm wondering if this NMDA transition hurdle doesn't make a good 
justification to keep the same module name!
We could debate whether ietf-routing is implemented or not, but the 
point is moot: we don't know what we don't know.

Regarding one point made by Andy:

    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.

We recognized this use case and tagged the YANG module "tree-type" in 
the YANG catalog.
In the soon-to-be-published but already implemented 
draft-clacla-netmod-model-catalog-02 draft, you will see:

    leaf tree-type {
           type enumeration {
             enum "split" {
               description
                 "This module uses a split config/operational state layout.";
             }
             enum "nmda-compatible" {
               description
                 "This module is compatible with the Network Management Datastores
                  Architecture (NMDA) and combines config and operational state nodes.";
             }
             enum "transitional-extra" {
               description
                 "This module is derived as a '-state' module to allow for transitioning
                  to a full NMDA-compliant tree structure.";
             }
             enum "openconfig" {
               description
                 "This module uses the Openconfig data element layout.";
             }
             enum "unclassified" {
               description
                 "This module does not belong to any category or can't be determined.";
             }
             enum "not-applicable" {
               description
                 "This module is not applicable. For example, because the YANG module only contains typedefs, groupings, or is a submodule";
             }
           }
           description
             "The type of data element tree used by the module as it relates to the
              Network Management Datastores Architecture.";
           reference "draft-dsdt-nmda-guidelines Guidelines for YANG Module Authors (NMDA)";
         }
         description
           "Grouping of YANG module metadata that extends the common list defined in the YANG
            Module Library (RFC 7895).";
    }

If not convinced already, I hope that you start to see the YANG catalog 
value for the industry.
Let's keep in mind that automation is key. Therefore, YANG modules 
without module details (metadata) and related tools is not sufficient 
for the industry.

Regards, Benoit
> Andy Bierman <[email-masked]> writes:
>
>> On Fri, Sep 15, 2017 at 9:02 AM, Robert Wilton <[email-masked]> 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 <[email-masked]> 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"
>>>>> <[email-masked] on behalf of [email-masked]> wrote:
>>>>>
>>>>> 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
>>>>>>
>>>>>> 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)
>>>>>>>>>
>>>>>>>>>
>>>>>> Ladislav Lhotka
>>>>>> Head, CZ.NIC Labs
>>>>>> PGP Key ID: 0xB8F92B08A9F76C67
>>>>>>

---

From: Robert Wilton <[email-masked]>
Date: Mon, 2 Oct 2017 15:18:00 +0100

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

---

From: Randy Presuhn <[email-masked]>
Date: Mon, 2 Oct 2017 09:37:39 -0700

Hi -

> RFC 8174 categorically states that text can still be normative without 

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

> 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

---

From: Robert Wilton <[email-masked]>
Date: Mon, 2 Oct 2017 18:03:44 +0100

Hi Randy,

On 02/10/2017 17:37, Randy Presuhn wrote:
>> RFC 8174 categorically states that text can still be normative 
>> without using 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 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

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 06 Oct 2017 17:32:44 +0200 (CEST)

Benoit Claise <[email-masked]> wrote:
> Here are all the ietf-routing dependent YANG modules (those modules
> that depend on ietf-routing)
> Some dependent modules are compliant with ietf-routing-2, the
> multicast YANG modules, but these are the only ones.
> 
> RFC8022bis mentioning in the module description that this module is
> not compatible with the NMDA architecture, and providing a pointer to
> I'm glad that we didn't change the ietf-interfaces to
> ietf-interfaces-2, we would have to deal with cross
> SDO/consortia/opensource project issues
> Note:
> 

Agreed.  I think there are no real reasons for keeping the module name
and deprecate the old defintiions.  Yes, it adds some noise to the
module but the fact is that we do deprecate all these defintions, and
I think we should not hide that.  

/martin

>                 "This module is not applicable. For example, because the YANG
>                 module only contains typedefs, groupings, or is a submodule";
>             }
>           }
>           description
> If not convinced already, I hope that you start to see the YANG
> catalog value for the industry.

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 06 Oct 2017 17:48:10 +0200 (CEST)

Martin Bjorklund <[email-masked]> wrote:
> and deprecate the old defintiions.

Whoops, forgot a "not", this should have been:

  I think there are no real reasons for not keeping the module name
  and deprecate the old defintiions.

> Yes, it adds some noise to the

/martin

---

From: Robert Wilton <[email-masked]>
Date: Fri, 6 Oct 2017 17:01:46 +0100

> I think we should not hide that.
This is also my preferred option.

I would like to just deprecate these nodes now, and then (for the 
routing module that is unlikely to have been widely implement) update it 
again in a 1-2 years time to remove the deprecated nodes (we can warn 
now that they will get removed).

Conversely, for ietf interfaces (which is much more likely to be widely 
implemented), I think that they should move to obsolete after 1-2 years 
and then hopefully be removed 1-2 years after that.

Thanks,
Rob

---

From: Benoit Claise <[email-masked]>
Date: Mon, 9 Oct 2017 23:06:48 +0200

On 10/6/2017 6:01 PM, Robert Wilton wrote:
> routing module that is unlikely to have been widely implement) update 
> it again in a 1-2 years time to remove the deprecated nodes (we can 
> warn now that they will get removed).
According to Acee, there is one ietf-routing implementation (based on an 
old draft version). If the point is that we don't want ietf-routing 
implementations to implement "deprecated" leaves, can we "obsolete" them 
now.
RFC 7950:

    7.21.2. The "status" Statement

        The "status" statement takes as an argument one of the strings
        "current", "deprecated", or "obsolete".

        o  "current" means that the definition is current and valid.

        o  "deprecated" indicates an obsolete definition, but it permits
           new/continued implementation in order to foster interoperability
           with older/existing implementations.

        o  "obsolete" means that the definition is obsolete and SHOULD NOT be
           implemented and/or can be removed from implementations.

Advantages:
     - we keep the same ietf-routing YANG module names
     - new implementations don't implement the "obsolete" parts.

Regards, Benoit
>
> Conversely, for ietf interfaces (which is much more likely to be 
> widely implemented), I think that they should move to obsolete after 
> 1-2 years and then hopefully be removed 1-2 years after that.
>
> Thanks,
> Rob
>
>
>>
>>
>> /martin
>>
>>
>>
>>>                   Architecture (NMDA) and combines config and 
>>> operational state
>>>                   nodes.";
>>>              }
>>>                  "This module is derived as a '-state' module to 
>>> allow for
>>>                  transitioning
>>>                  "This module does not belong to any category or 
>>> can't be
>>>                  determined.";
>>>              }
>>>              enum "not-applicable" {
>>>                description
>>>              "The type of data element tree used by the module as it 
>>> relates to
>>>              the
>>>            reference "draft-dsdt-nmda-guidelines Guidelines for YANG 
>>> Module
>>>            Authors (NMDA)";
>>>          }
>>>          description
>>>            "Grouping of YANG module metadata that extends the common 
>>> list
>>>            defined in the YANG
>>>>>> However, I doubt that there are many implementations of this 8022 
>>>>>> yet,
>>>>>> and
>>>>>>>> With respect to WG adoption, we will do whatever the WG decides 
>>>>>>>> for
>>>>>>>> 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
>>>>>>>>> no formal ancestry. I would prefer to keep the modules from 
>>>>>>>>> RFC 8022
>>>>>>>>> as
>>>>>>>>> they are
>>>>>>>>>> general agreement to do it.  Are the authors okay with it, or 
>>>>>>>>>> are
>>>>>>>>>> there
>>>>>>>>>> any
>>>>>>>>>> better suggestions?
>>>>>>>>>>
>>>>>>>>> I think it is unnecessary. If somebody needs adding such a 
>>>>>>>>> module to
>>>>>>>>> the
>>>>>>>>> data
>>>>>>>>>>>> 1. 
>>>>>>>>>>>> https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7223bis-00 
>>>>>>>>>>>>
>>>>>>>>>>>> 2. 
>>>>>>>>>>>> https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7277bis-00 
>>>>>>>>>>>>

---

From: Robert Wilton <[email-masked]>
Date: Tue, 10 Oct 2017 10:59:06 +0100

On 09/10/2017 22:06, Benoit Claise wrote:
> According to Acee, there is one ietf-routing implementation (based on 
> an old draft version). If the point is that we don't want ietf-routing 
> implementations to implement "deprecated" leaves, can we "obsolete" 
> them now.
> RFC 7950:
>

For 8022bis, I would also support keeping the existing module name, and 
moving the existing state leaves directly to obsolete.  This is with the 
justification that this draft has only recently been published, and we 
do not expect there to be many implementations yet.

For RFC 7223, I think that the state leaves should move to deprecated 
then obsolete in a later revision, because the model is much older and 
hence likely to be much more established.

Thanks,
Rob

>>>>                  "This module is compatible with the Network 
>>>> Management
>>>>                  Datastores
>>>>              "The type of data element tree used by the module as 
>>>> it relates to
>>>>              the
>>>>            reference "draft-dsdt-nmda-guidelines Guidelines for 
>>>> YANG Module
>>>>            Authors (NMDA)";
>>>>          }
>>>>          description
>>>>            "Grouping of YANG module metadata that extends the 
>>>> common list
>>>>            defined in the YANG
>>>>>>> However, I doubt that there are many implementations of this 
>>>>>>> 8022 yet,
>>>>>>> and
>>>>>>> or for the extra NMDA state module, as I think that both you and 
>>>>>>> Tom
>>>>>>> have
>>>>>>> been asking for.
>>>>>>>
>>>>>>>>> With respect to WG adoption, we will do whatever the WG 
>>>>>>>>> decides for
>>>>>>>>> the
>>>>>>>> I know that it hasn't been asked yet, but I support adoption of 
>>>>>>>> any
>>>>>>>> 8022
>>>>>>>>> However, we’ll do what it takes to reach consensus and satisfy 
>>>>>>>>> the
>>>>>>>>> most
>>>>>>>>> pedantic among us.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Acee
>>>>>>>>>
>>>>>>>>>>> general agreement to do it.  Are the authors okay with it, 
>>>>>>>>>>> or are
>>>>>>>>>>> there
>>>>>>>>>>> any
>>>>>>>>>>> better suggestions?
>>>>>>>>>>>
>>>>>>>>>>>>> 3. 
>>>>>>>>>>>>> https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-00
>>>>>>>>>>>>>

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 10 Oct 2017 12:13:38 +0200 (CEST)

Robert Wilton <[email-masked]> wrote:
> For 8022bis, I would also support keeping the existing module name,
> and moving the existing state leaves directly to obsolete.  This is
> with the justification that this draft has only recently been
> published, and we do not expect there to be many implementations yet.

This is fine with me as well.

> hence likely to be much more established.

Agreed.

/martin

---

From: Kent Watsen <[email-masked]>
Date: Wed, 11 Oct 2017 14:25:50 +0000

I agree - let's keep the module name and mark the nodes obsolete.

Kent // any hat

Robert Wilton <[email-masked]> wrote:
> >>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.yangcatalog.org_yang-2Dsearch_impact-5Fanalysis.php-3Fmodules-5B-5D-3Dietf-2Drouting-26recurse-3D0-26rfcs-3D1-26show-5Fsubm-3D1-26show-5Fdir-3Ddependents&d=DwIFAw&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=kX_P_vaiOkWNohKKL0HP88U-glXsmhlyjgWw7rxg1bw&s=PEvVi2dNF5_gICJ7X97iuctNaAyUV5Pgnsr2LiDLFEA&e=
> >>>> So many YANG modules.
> >>>>
> >>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.yangcatalog.org_yang-2Dsearch_impact-5Fanalysis.php-3Fmodules-5B-5D-3Dietf-2Drouting-2D2-26recurse-3D0-26rfcs-3D1-26show-5Fsubm-3D1-26show-5Fdir-3Ddependents&d=DwIFAw&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=kX_P_vaiOkWNohKKL0HP88U-glXsmhlyjgWw7rxg1bw&s=ISgVe_scuCOokfsF8C62oeiGhfTWMjlAXiS7bnS4cpc&e=
> >>>> Â Â Â Â  1. to make sure they are aware of ietf-routing-2 (publishing a
> >>>> Â Â Â Â  2. to ask them to change their import to ietf-routing-2
> >>>> Â Â Â  we're in a transition phase today, while we implement the
> >>>> Â Â Â  soon-to-be-published draft-clacla-netmod-model-catalog-02
> >>>> Â Â Â  Because of this, the SDO/consortia/opensource dependent YANG
> >>>> modules
> >>>> Â Â Â  will only appear in the Impact Analysis tomorrow at
> >>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.yangcatalog.org_yang-2Dsearch_impact-5Fanalysis.php-3Fmodules-5B-5D-3Dietf-2Dinterfaces-26recurse-3D0-26rfcs-3D1-26show-5Fsubm-3D1-26show-5Fdir-3Ddependents&d=DwIFAw&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=kX_P_vaiOkWNohKKL0HP88U-glXsmhlyjgWw7rxg1bw&s=V7trpGHuvRSOwmb0ppL7GoztsKSUJI3yWJ-jxeSHTXs&e=
> >>>> Â Â Â  In the mean time, you can see all these dependent modules
> >>>> Â Â Â  Ex:
> >>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.yangcatalog.org_yang-2Dsearch_module-5Fdetails.php-3Fmodule-3Dietf-2Dinterfaces&d=DwIFAw&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=kX_P_vaiOkWNohKKL0HP88U-glXsmhlyjgWw7rxg1bw&s=euRn2n-i8nQZX5Y-ZieREslwccv7DJBS6L8jlNBA3TM&e=
> >>>> Â Â Â Â  Â Â Â  Â Â Â  => click on "dependents"
> >>>> Â Â Â  Those dependent modules is a new feature of
> >>>> Â Â Â  draft-clacla-netmod-model-catalog-02
> >>>>
> >>>>
> >>> Agreed.Â  I think there are no real reasons for keeping the module name
> >>> and deprecate the old defintiions.Â  Yes, it adds some noise to the
> > Â Â Â  - we keep the same ietf-routing YANG module names
> > Â Â Â  - new implementations don't implement the "obsolete" parts.
> 
> and moving the existing state leaves directly to obsolete.Â  This is

Agreed.

/martin

_______________________________________________
netmod mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwIFAw&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=kX_P_vaiOkWNohKKL0HP88U-glXsmhlyjgWw7rxg1bw&s=z1FXjDcWCxsDTbtcLAATaD4vb3tJHL5GhZ8ufDlZLIw&e=

---

From: Lou Berger <[email-masked]>
Date: Thu, 12 Oct 2017 10:30:55 -0400

As it was unclear if/that Kent was stating a position as chair: it looks 
like the consensus position of the working group is that we should keep the 
old name and mark nodes that are no longer needed due to nmda as obsolete.

Lou
As co-chair

On October 11, 2017 10:26:29 AM Kent Watsen <[email-masked]> wrote:

> Rtg-dt-yang-arch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtg-dt-yang-arch