Re: [netmod] ietf-routing or ietf-routing-2? module naming convention for NMDA transition. Re: upcoming adoptions
Martin Bjorklund <mbj@tail-f.com> Tue, 10 October 2017 10:15 UTC
Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 065011332DF; Tue, 10 Oct 2017 03:15:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNLqVnckyMZR; Tue, 10 Oct 2017 03:15:41 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id F2E19134C77; Tue, 10 Oct 2017 03:15:07 -0700 (PDT)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id A03201AE02A7; Tue, 10 Oct 2017 12:15:06 +0200 (CEST)
Date: Tue, 10 Oct 2017 12:13:38 +0200
Message-Id: <20171010.121338.957274767620281285.mbj@tail-f.com>
To: rwilton@cisco.com
Cc: bclaise@cisco.com, andy@yumaworks.com, acee@cisco.com, netmod@ietf.org, rtg-dt-yang-arch@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <fe00b981-b993-e492-fe21-a1598dda60b7@cisco.com>
References: <4ad101fa-97b7-4cbe-331c-0697feae797b@cisco.com> <16eda4e4-5612-918c-9d06-eec39f67e88a@cisco.com> <fe00b981-b993-e492-fe21-a1598dda60b7@cisco.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/FlpbZYYqqeqU1eIX-fNBWVRUZDM>
Subject: Re: [netmod] ietf-routing or ietf-routing-2? module naming convention for NMDA transition. Re: upcoming adoptions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Oct 2017 10:15:43 -0000
Robert Wilton <rwilton@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 <bclaise@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://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. > > 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] ietf-routing or ietf-routing-2? module n… Benoit Claise
- Re: [netmod] upcoming adoptions - this appendix i… Lou Berger
- Re: [netmod] upcoming adoptions - this appendix i… Juergen Schoenwaelder
- Re: [netmod] upcoming adoptions - this appendix i… Robert Wilton
- Re: [netmod] upcoming adoptions - this appendix i… Robert Wilton
- Re: [netmod] upcoming adoptions - this appendix i… Randy Presuhn
- Re: [netmod] upcoming adoptions - this appendix i… Lou Berger
- Re: [netmod] upcoming adoptions - this appendix i… Benoit Claise
- [netmod] upcoming adoptions Kent Watsen
- Re: [netmod] upcoming adoptions Martin Bjorklund
- Re: [netmod] upcoming adoptions Acee Lindem (acee)
- Re: [netmod] upcoming adoptions Martin Bjorklund
- Re: [netmod] upcoming adoptions Juergen Schoenwaelder
- Re: [netmod] upcoming adoptions Benoit Claise
- Re: [netmod] upcoming adoptions Martin Bjorklund
- Re: [netmod] upcoming adoptions Andy Bierman
- Re: [netmod] upcoming adoptions Martin Bjorklund
- Re: [netmod] upcoming adoptions Kent Watsen
- Re: [netmod] upcoming adoptions Andy Bierman
- Re: [netmod] upcoming adoptions Kent Watsen
- Re: [netmod] upcoming adoptions Andy Bierman
- Re: [netmod] upcoming adoptions Robert Wilton
- Re: [netmod] upcoming adoptions Martin Bjorklund
- Re: [netmod] upcoming adoptions Robert Wilton
- Re: [netmod] upcoming adoptions Martin Bjorklund
- Re: [netmod] upcoming adoptions Robert Wilton
- Re: [netmod] upcoming adoptions Martin Bjorklund
- Re: [netmod] upcoming adoptions Andy Bierman
- Re: [netmod] upcoming adoptions Juergen Schoenwaelder
- Re: [netmod] upcoming adoptions Robert Wilton
- Re: [netmod] upcoming adoptions Juergen Schoenwaelder
- Re: [netmod] upcoming adoptions Robert Wilton
- Re: [netmod] upcoming adoptions Andy Bierman
- Re: [netmod] upcoming adoptions Juergen Schoenwaelder
- Re: [netmod] upcoming adoptions Robert Wilton
- Re: [netmod] upcoming adoptions Ladislav Lhotka
- Re: [netmod] upcoming adoptions Juergen Schoenwaelder
- Re: [netmod] upcoming adoptions Robert Wilton
- Re: [netmod] upcoming adoptions Andy Bierman
- Re: [netmod] upcoming adoptions Robert Wilton
- Re: [netmod] upcoming adoptions Lou Berger
- Re: [netmod] upcoming adoptions Kent Watsen
- Re: [netmod] upcoming adoptions Robert Wilton
- Re: [netmod] upcoming adoptions Kent Watsen
- Re: [netmod] upcoming adoptions Acee Lindem (acee)
- Re: [netmod] upcoming adoptions t.petch
- Re: [netmod] upcoming adoptions Lou Berger
- Re: [netmod] upcoming adoptions Juergen Schoenwaelder
- Re: [netmod] upcoming adoptions Ladislav Lhotka
- Re: [netmod] upcoming adoptions Acee Lindem (acee)
- Re: [netmod] upcoming adoptions Robert Wilton
- Re: [netmod] upcoming adoptions Andy Bierman
- Re: [netmod] upcoming adoptions Robert Wilton
- Re: [netmod] upcoming adoptions - this appendix i… t.petch
- Re: [netmod] upcoming adoptions Andy Bierman
- Re: [netmod] upcoming adoptions Kent Watsen
- Re: [netmod] upcoming adoptions Ladislav Lhotka
- Re: [netmod] upcoming adoptions - this appendix i… Lou Berger
- Re: [netmod] ietf-routing or ietf-routing-2? modu… Martin Bjorklund
- Re: [netmod] ietf-routing or ietf-routing-2? modu… Martin Bjorklund
- Re: [netmod] ietf-routing or ietf-routing-2? modu… Robert Wilton
- Re: [netmod] ietf-routing or ietf-routing-2? modu… Benoit Claise
- Re: [netmod] ietf-routing or ietf-routing-2? modu… Robert Wilton
- Re: [netmod] ietf-routing or ietf-routing-2? modu… Martin Bjorklund
- Re: [netmod] ietf-routing or ietf-routing-2? modu… Kent Watsen
- Re: [netmod] [Rtg-dt-yang-arch] ietf-routing or i… Lou Berger