Re: [netmod] [RTG-DIR] handling module incompatibility => handling module transition

Benoit Claise <> Sun, 15 October 2017 16:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7A66A133047; Sun, 15 Oct 2017 09:26:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id A8L9t9oTqqjZ; Sun, 15 Oct 2017 09:26:40 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8F58C132F2E; Sun, 15 Oct 2017 09:26:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=34225; q=dns/txt; s=iport; t=1508084800; x=1509294400; h=subject:from:to:cc:references:message-id:date: mime-version:in-reply-to; bh=OGnrVNSkqIK+AIR1/zMxHig7Xhyfdr6Y6Oa+fOXfXzU=; b=DnelOSiZz3kqP15xw4fPGsbh28uzSZFtpwf/nw6vE/r7Ho190hZg2j20 V7wa+UjQCe6Qf3Vgw5Xr+9QX39qlCwnLdIVevkfKycfzGrIjfxueFFYyQ sP/+ZGIk7n3LtgMGHtgiXjzYVEz3JAqqP0YmlTk/8O6xLa3DqmF2IIv/c U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0COAAApi+NZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9CgRJuJ4N6ih90kDOWLxCCBAolhRYChRUYAQIBAQEBAQEBayi?= =?us-ascii?q?FHgEFGglOCBAJAg4KIAEJAgJXBgEMBgIBAReKAhCMYp1ngicmiwIBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEdgy2DWIFqK4J/hE0FARECAYMxgmEFih+CHIUMkAGHX4N?= =?us-ascii?q?iiSqCFF2Ic4cyiiKDbYdggTkfOIEDVjQhCB0VSYJkCYJTHIFpPjYBilsBAQE?=
X-IronPort-AV: E=Sophos;i="5.43,383,1503360000"; d="scan'208,217";a="698031719"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Oct 2017 16:26:36 +0000
Received: from [] ( []) by (8.14.5/8.14.5) with ESMTP id v9FGQaI0004063; Sun, 15 Oct 2017 16:26:36 GMT
From: Benoit Claise <>
To: Lou Berger <>, NetMod WG <>
References: <> <> <> <>
Message-ID: <>
Date: Sun, 15 Oct 2017 18:26:35 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------86328339758D90C1C732FFA1"
Content-Language: en-US
Archived-At: <>
Subject: Re: [netmod] [RTG-DIR] handling module incompatibility => handling module transition
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 15 Oct 2017 16:26:44 -0000

On 10/12/2017 3:30 PM, Benoit Claise wrote:
> Hi Lou,
>> So circling back to the original question: what do we do about the 
>> non backward-compatible module being defined in rfc8049bis?
>> While being sympathetic to many of the comments made below as well as 
>> the "do over" concept, I find the comments about adhering to the 
>> rules of 7950 compelling - which leads to renaming the module in the 
>> bis to ietf-l3vpn-svc-2.
>> It would be good to ensure that this is the consensus of the group 
>> before asking the authors make this change.
> Since this draft is AD sponsored, I'll evaluate the consensus on 
> RFC8049bis.
> Moving to ietf-l3vpn-svc-2 is the easy path not to break backward 
> compatibility. However, since ietf-l3vpn-svc is unimplementable (it 
> has broken XPATH expressions, so a compliant implementation is 
> impossible), so technically, ietf-l3vpn-svc does not even exist.
See my message on this topic, as the IETF LC follow up.
If a follow up is required, I propose that we use a single public email 
thread: the

Regards, Benoit
> What NETMOD should focus on is closing on the NMDA transition: the 
> ietf-routing versus ietf-routing-2 issue.
> Way bigger impact in terms of dependent YANG modules
> Regards, Benoit (as OPS AD)
> See below.
>> This change course doesn't solve the versioning issue discussed 
>> below, but this is not a new issue it's just the first time we'll 
>> actually executing the steps envisioned as part of the rules laid out 
>> in yang. My personal take away is that means that we should 
>> immediately start work on an extension defining along the lines of  ' 
>> *_obsolete|update_*' mentioned below.
> I believe that option 1 is the more pragmatic and complete solution. 
> option 2 is just half a step in the right direction.
> I believe we should discuss this topic in Singapore.
> Regards, Benoit (as individual contributor)
>> Lou
>> On October 8, 2017 10:59:15 AM Benoit Claise <>; wrote:
>>> Dear all,
>>> Focusing on draft-wu-l3sm-rfc8049bis, the big problem is: RFC8049 is 
>>> broken. The small problem is: trying to maintain backward compatibility.
>>> draft-wu-l3sm-rfc8049bis has rightly focused on the big problem.
>>> Let me extend the scope of this email thread from "handling module 
>>> incompatibility" to "handling module incompatibility and NMDA 
>>> transition".
>>> As I mentioned in the past (see " comparison of two YANG 
>>> modules" email in NETMOD), I believe the IETF will have to change 
>>> its way of working in terms of backward compatibility. See also the 
>>> email "ietf-routing or ietf-routing-2? module naming convention for 
>>> NMDA transition. Re: [netmod] upcoming adoptions" in NETMOD.
>>> However, we will have to tackle this discussion one day or the other:
>>> - we need _an automatic way_ to make the link between the YANG 
>>> module in RFC8049 and the YANG module in draft-wu-l3sm-rfc8049bis, 
>>> or any non backward compatible YANG modules.
>>> - we need _an automatic way_ to make the link between the YANG 
>>> module in RFC8022 and the YANG module in 
>>> draft-acee-netmod-rfc8022bis, or any new YANG module names used for 
>>> NMDA transition.
>>> Note: actually, we face two different problems. 
>>> draft-wu-l3sm-rfc8049bis might be declared backward incompatible 
>>> with RFC8049, while RFC8022bis is backward compatible with RFC8022. 
>>> The RFC8022bis went for a new YANG module name ietf-routing-2 to 
>>> avoid to document the -state tree (as deprecated), based on the 
>>> argument that ietf-routing is not yet implemented.
>>> Which solutions do we have from here?
>>> #1. We keep the same module name and express that the YANG module in 
>>> draft-wu-l3sm-rfc8049bis is not backward compatible with the RFC8049 
>>> one. This is the openconfig way. See 
>>> draft-clacla-netmod-model-catalog (and 
>>> draft-openconfig-netmod-model-catalog before)
>>>        // extension statements
>>>           extension openconfig-version {
>>>             argument "semver" {
>>>               yin-element false;
>>>             }
>>>             description
>>>               "The OpenConfig version number for the module. This is
>>>               expressed as a semantic version number of the form:
>>>                 x.y.z
>>>                where:
>>>                 * x corresponds to the major version,
>>>                 * y corresponds to a minor version,
>>>                 * z corresponds to a patch version.
>>>               This version corresponds to the model file within which it is
>>>               defined, and does not cover the whole set of OpenConfig models.
>>>               Where several modules are used to build up a single block of
>>>               functionality, the same module version is specified across each
>>>               file that makes up the module.
>>>               A major version number of 0 indicates that this model is still
>>>               in development (whether within OpenConfig or with industry
>>>               partners), and is potentially subject to change.
>>>               Following a release of major version 1, all modules will
>>>               increment major revision number where backwards incompatible
>>>               changes to the model are made.
>>>               The minor version is changed when features are added to the
>>>               model that do not impact current clients use of the model.
>>>               The patch-level version is incremented when non-feature changes
>>>               (such as bugfixes or clarifications to human-readable
>>>               descriptions that do not impact model functionality) are made
>>>               that maintain backwards compatibility.
>>>               The version number is stored in the module meta-data.";
>>>           }
>>> Similarly, we always keep the same YANG module name in case of NMDA 
>>> transition. So ietf-routing-2 should be changed back to ietf-routing.
>>> The email thread "[Rtg-dt-yang-arch] ietf-routing or ietf-routing-2? 
>>> module naming convention for NMDA transition. Re: [netmod] upcoming 
>>> adoptions" seems to go in that direction.
>>> #2. Or we have a different module name, let's say ietf-l3vpn-svc-2 
>>> or ietf-routing-2 but then, how do we make the link with the 
>>> previous module?
>>> Then ...  What? We create extension that will link the 
>>> draft-wu-l3sm-rfc8049bis YANG module to the RFC8049 YANG module? 
>>> Same principle as #1, but just more complex.
>>> Or we have a new YANG keyword (this implies YANG 2.0)
>>>     <CODE BEGINS>file"ietf-l3vpn-svc@2017-09-14.yang";
>>>     module ietf-l3vpn-svc-2 {
>>>       yang-version 1.1;
>>>       namespace "urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc";
>>>       prefix l3vpn-svc;
>>>       *_obsolete|update _*ietf-l3vpn-svc@2017-01-2
>>> And whose responsibility is this to warn/push all authors of 
>>> ietf-routing YANG modules to move to ietf-routing-2? (*)
>>> The following are non solution IMO:
>>> - Going from the draft-wu-l3sm-rfc8049bis YANG _module _to the 
>>> draft-wu-l3sm-rfc8049bis _document _to lookup the IETF "obsolete" 
>>> flag in order to understand that the RFC8049 YANG module is obsolete 
>>> is not an automatic solution.
>>> - Using the might be a solution as we track the 
>>> derived semantic, but this is just an offline trick. This is not 
>>> what I call "automatic way"
>>> - Using the YANG module description field might be interesting, but 
>>> again this is not an "automatic way":
>>>       description
>>>        "This YANG module defines a generic service configuration
>>>         model for Layer 3 VPNs. This model is common across all
>>>         vendor implementations. This obsoletes the RFC8049 YANG
>>>         module, ietf-l3vpn-svc@2017-01-2";
>>>       revision 2017-09-14 {
>>>        description
>>>     "First revision ofRFC8049 <>.";;
>>>        reference
>>>         "RFC xxxx: YANG Data Model for L3VPN Service Delivery";
>>> In conclusion, I believe openconfig got this right and that solution 
>>> #1 is the solution to go ... while waiting for a new YANG keyword in 
>>> YANG 2.0
>>> (*) If you want to change the module from ietf-routing to 
>>> ietf-routing-2, then you should follow with all authors of dependent 
>>> modules to make sure they transition to ietf-routing-2
>>> In the, because I needed the information as OPS AD, 
>>> we created a small script to get that authors list for IETF drafts. 
>>> For the ietf-routing, this produces the following
>>> {
>>>     "output": {
>>>         "author-email": [
>>> "";,
>>> "";,
>>> "";,
>>> "";,
>>> "";,
>>> "";,
>>> "";,
>>> "";,
>>> "";,
>>> "";,
>>> "";,
>>> "";,
>>> "";,
>>> "";,
>>> "";,
>>> "";,
>>> "";,
>>> "";,
>>> "";,
>>> "";,
>>> "";,
>>> "";
>>>         ]
>>>     }
>>> }
>>> Fortunately, we only deal with IETF dependent YANG modules in case 
>>> of the ietf-routing. That's an easier case.
>>> If we would change ietf-interfaces to ietf-interfaces-2, we would 
>>> have an cross SDO issue ... Btw, there are no automatic ways to 
>>> extract the authors of YANG modules from different SDOs: it's only a 
>>> metadata that that the different SDOs should insert in the 
>>> yangcatalog. So we would have to rely on liaisons or direct emails, 
>>> assuming we know the authors. Time consuming, believe me.
>>> Regards, Benoit
>>>> Hi,
>>>>      As part of the my Routing Directorate review of
>>>> draft-wu-l3sm-rfc8049bis I noted that there were several incompatible
>>>> changes being made to the ietf-l3vpn-svc module without changing the
>>>> name.  I raised this with the YANG doctors and others involved with the
>>>> draft and it surfaced some topics which really should be discussed here
>>>> in NetMod.
>>>> The background (as explained off-list by others, so I hope I have it
>>>> right)  is that one of the YANG Doctors noted that RFC8049 was broken
>>>> and could not be implemented as defined, and therefore a fix was
>>>> needed.  L3SM has concluded so the fix is in the individual draft
>>>> draft-wu-l3sm-rfc8049bis.  Since the rfc8049 version of ietf-l3vpn-svc
>>>> module could not be implemented, the feeling by the YANG Dr was that
>>>> even though the new module is incompatible with the original definition
>>>> the module the rule defined in Section 11 of YANG 1.1 (or section 10 of
>>>> RFC 6020) didn't have to be followed and the same name could be used.
>>>> In the subsequent discussion with the YANG Drs., the general discussion
>>>> was heading down the path of using a new module name, and thereby not
>>>> violating YANG module update rules.  This lead us back to the a similar
>>>> discussion we've been having in the context of 8022bis: how best to
>>>> indicate that a whole module is being obsoleted.  RFCs do this by adding
>>>> 'metadata' to the headers, e.g., "Obsoletes: 8049", but this doesn't
>>>> help YANG tooling.  For 8022, we have one approach - publishing an
>>>> updated rev of the original module marking all nodes as deprecated - but
>>>> that doesn't really make sense for rfc8049bis.
>>>> So the discussion for the WG is:
>>>> How do we handle incompatible module changes, notably when one module
>>>> 'obsoletes' another module --  from both the process and tooling
>>>> perspectives?
>>>> I know Benoit plans to bring in some thoughts/proposals, perhaps there
>>>> are others.
>>>> Cheers,
>>>> Lou
>>>> (as contributor/reviewer)