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

[Martin Bjorklund <[e-mail]>]

Martin Bjorklund <[e-mail]> 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.

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
> module but the fact is that we do deprecate all these defintions, and
> I think we should not hide that.  


/martin


> 
> 
> /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
> > >>>>
> > >>>
> > >>>
> > 
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod