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