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

Benoit Claise <> Thu, 12 October 2017 13:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 009A71342EA; Thu, 12 Oct 2017 06:30:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Status: No, score=-14.499 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, URIBL_BLOCKED=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 81WSGcwLYPdP; Thu, 12 Oct 2017 06:30:20 -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 DB3101344DF; Thu, 12 Oct 2017 06:30:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=32323; q=dns/txt; s=iport; t=1507815012; x=1509024612; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=ehjf8nRRZ08b5pmYhijdjG5RqOsz8nX6TyjdjcxppmM=; b=Dym4Am8ZTMOFr5bmOvBjuid1SrAitMmDG+Lq2VJcbEgwytlsYprsGpEQ zRhe9r3lEwf2OK0lobLo38auFZn6viyX2ZKASp9dzD2Xn6yHrkC9DMV5P vvzAAh0qPxhM0/jt1srJzikCL8dWhzWcTc3ccw+EU9LjYYE1PzHsw8p4C I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.43,366,1503360000"; d="scan'208,217";a="658044034"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Oct 2017 13:30:09 +0000
Received: from [] ( []) by (8.14.5/8.14.5) with ESMTP id v9CDU8b2019476; Thu, 12 Oct 2017 13:30:08 GMT
To: Lou Berger <>, NetMod WG <>
References: <> <> <>
From: Benoit Claise <>
Message-ID: <>
Date: Thu, 12 Oct 2017 15:30:09 +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="------------04E5314780CBCEB69EF6D7BF"
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: Thu, 12 Oct 2017 13:30:24 -0000

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.

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)