I agree - let's keep the module name and mark the nodes obsolete. Kent // any hat
Robert Wilton <rwil...@cisco.com> 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 <bcla...@cisco.com> 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 netmod@ietf.org 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= _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
