Re: [netmod] ietf-routing or ietf-routing-2? module naming convention for NMDA transition. Re: upcoming adoptions
Martin Bjorklund <mbj@tail-f.com> Fri, 06 October 2017 15:48 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 5E982132D17; Fri, 6 Oct 2017 08:48:14 -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 mGqsSHBv0Qj3; Fri, 6 Oct 2017 08:48:11 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 82B7A13308A; Fri, 6 Oct 2017 08:48:11 -0700 (PDT)
Received: from localhost (h-40-225.A165.priv.bahnhof.se [94.254.40.225]) by mail.tail-f.com (Postfix) with ESMTPSA id B173C1AE0310; Fri, 6 Oct 2017 17:48:10 +0200 (CEST)
Date: Fri, 06 Oct 2017 17:48:10 +0200
Message-Id: <20171006.174810.2100217316354098631.mbj@tail-f.com>
To: bclaise@cisco.com
Cc: rtg-dt-yang-arch@ietf.org, netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <20171006.173244.1167478609964390238.mbj@tail-f.com>
References: <87h8w0bbyf.fsf@nic.cz> <fa482cdf-f2b7-c03a-5f5e-d6c5c2a1e1d7@cisco.com> <20171006.173244.1167478609964390238.mbj@tail-f.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/SKP9_-JsanqwrwN7CP_c2UDW7wU>
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: Fri, 06 Oct 2017 15:48:14 -0000
Martin Bjorklund <mbj@tail-f.com> 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. 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 <andy@yumaworks.com> writes: > > > > > >> On Fri, Sep 15, 2017 at 9:02 AM, Robert Wilton <rwilton@cisco.com> > > >> 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 <rwilton@cisco.com> > > >>> 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" > > >>>>> <netmod-bounces@ietf.org on behalf of lhotka@nic.cz> 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 > > >>>>>>>>> netmod@ietf.org > > >>>>>>>>> https://www.ietf.org/mailman/listinfo/netmod > > >>>>>>>>> . > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>> _______________________________________________ > > >>>>>>> netmod mailing list > > >>>>>>> netmod@ietf.org > > >>>>>>> https://www.ietf.org/mailman/listinfo/netmod > > >>>>>>> > > >>>>>> -- > > >>>>>> Ladislav Lhotka > > >>>>>> Head, CZ.NIC Labs > > >>>>>> PGP Key ID: 0xB8F92B08A9F76C67 > > >>>>>> > > >>>>>> _______________________________________________ > > >>>>>> netmod mailing list > > >>>>>> netmod@ietf.org > > >>>>>> https://www.ietf.org/mailman/listinfo/netmod > > >>>>>> > > >>>>> _______________________________________________ > > >>>>> netmod mailing list > > >>>>> netmod@ietf.org > > >>>>> https://www.ietf.org/mailman/listinfo/netmod > > >>>>> > > >>>> _______________________________________________ > > >>>> netmod mailing list > > >>>> netmod@ietf.org > > >>>> https://www.ietf.org/mailman/listinfo/netmod > > >>>> > > >>> > > >>> > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod
- [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