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

[Kent Watsen <[e-mail]>]

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

Kent // any hat



Robert Wilton <[e-mail]> wrote:
> 
> 
> On 09/10/2017 22:06, Benoit Claise wrote:
> > 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://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.
> >>>>
> >>>> Look at the difference for ietf-routing-2:
> >>>> 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=
> >>>> 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://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
> >>>>
> >>>>
> >>>> 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.
> 
> 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.

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

Agreed.


/martin

_______________________________________________
netmod mailing list
[e-mail]
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=