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

[Robert Wilton <[e-mail]>]

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

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