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:32 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 0C6BC1349E6; Fri, 6 Oct 2017 08:32:49 -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 eQTYvxwvO_c9; Fri, 6 Oct 2017 08:32:46 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id B1EE113308A; Fri, 6 Oct 2017 08:32:45 -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 7F5E61AE0310; Fri, 6 Oct 2017 17:32:44 +0200 (CEST)
Date: Fri, 06 Oct 2017 17:32:44 +0200
Message-Id: <20171006.173244.1167478609964390238.mbj@tail-f.com>
To: bclaise@cisco.com
Cc: andy@yumaworks.com, rwilton@cisco.com, acee@cisco.com, netmod@ietf.org, rtg-dt-yang-arch@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <fa482cdf-f2b7-c03a-5f5e-d6c5c2a1e1d7@cisco.com>
References: <CABCOCHSKFAPR7Up1dQgy0Tpzzp7X9zMhOQsWcO35w-6AS7wjkQ@mail.gmail.com> <87h8w0bbyf.fsf@nic.cz> <fa482cdf-f2b7-c03a-5f5e-d6c5c2a1e1d7@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="utf-8"
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/8r1G3sApZcr6Tt-YBT1nWNJXyJc>
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:32:49 -0000

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.  


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