Re: [netmod] ietf-routing or ietf-routing-2? module naming convention for NMDA transition. Re: upcoming adoptions

[Benoit Claise <[e-mail]>]

On 10/6/2017 6:01 PM, Robert Wilton wrote:
>
>
> On 06/10/2017 16:32, Martin Bjorklund wrote:
>> Benoit Claise <[e-mail]> wrote:
>>> 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.
>> 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.
> 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).
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
>>
>>
>>
>>> 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 <[e-mail]> writes:
>>>>
>>>>> On Fri, Sep 15, 2017 at 9:02 AM, Robert Wilton <[e-mail]>
>>>>> 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 <[e-mail]>
>>>>>> 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"
>>>>>>>> <[e-mail] on behalf of [e-mail]> 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)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> netmod mailing list
>>>>>>>>>>>> [e-mail]
>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>>>>>>>> .
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> netmod mailing list
>>>>>>>>>> [e-mail]
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>>>>>>
>>>>>>>>> -- 
>>>>>>>>> Ladislav Lhotka
>>>>>>>>> Head, CZ.NIC Labs
>>>>>>>>> PGP Key ID: 0xB8F92B08A9F76C67
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> netmod mailing list
>>>>>>>>> [e-mail]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> netmod mailing list
>>>>>>>> [e-mail]
>>>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> netmod mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>>>
>>>>>>
>
> .
>