Re: [netmod] handling module incompatibility => handling module transition
Benoit Claise <bclaise@cisco.com> Sun, 08 October 2017 14:58 UTC
Return-Path: <bclaise@cisco.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 018D213463F; Sun, 8 Oct 2017 07:58:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 urUoKUifTDHM; Sun, 8 Oct 2017 07:58:37 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9CB8132397; Sun, 8 Oct 2017 07:58:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23939; q=dns/txt; s=iport; t=1507474716; x=1508684316; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=WeV3hKj7T9+RyNwXpT7F3WeRl6RamhRZrW3a6jav4u8=; b=NiB6FcsY2rVYf2/dTcpaCHIdodvz38KKcqVeJCMGkyOruGxzCtjX5OCT FeNDrUZs1UZrBJyHXx1laclc96K/U/5j9EXGqh1ea9IYzAC5ZpT0J9YVa j4wRwZI4eyHJl3BcOwPx6neTUf0+lIpv2jF07Brn1BSYvWzixMG13kZAe E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0COAADXPNpZ/xbLJq1cGQEBAQEBAQEBAQEBBwEBAQEBgzCBEW4ng3qKH3SnHA6CBAofhRwChGAYAQIBAQEBAQEBayiFGQYjTggQCQIONAICVwYBDAYCAQEXihUQiFKdZ4InJ4p+AQEBAQEBAQEBAQEBAQEBAQEBAQEBHYMtg1OBaiuCfoRMBQESAYMygmEFihqCHIUKj3OHXoNfiSiCFFuIboctihaDZoddgTkfOIEDCzIhCB0VSYcfPjaHCYI0AQEB
X-IronPort-AV: E=Sophos;i="5.42,495,1500940800"; d="scan'208,217";a="656225827"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Oct 2017 14:58:33 +0000
Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v98EwWUG013302; Sun, 8 Oct 2017 14:58:32 GMT
To: Lou Berger <lberger@labn.net>, NetMod WG <netmod@ietf.org>
Cc: rtg-dir@ietf.org, draft-wu-l3sm-rfc8049bis.all@ietf.org, draft-acee-netmod-rfc8022bis@ietf.org
References: <caa884d9-9d71-e7ad-cffd-427b58750c58@labn.net>
From: Benoit Claise <bclaise@cisco.com>
Message-ID: <751fa015-a917-a104-f6c6-25cc9a5accba@cisco.com>
Date: Sun, 08 Oct 2017 16:58:32 +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: <caa884d9-9d71-e7ad-cffd-427b58750c58@labn.net>
Content-Type: multipart/alternative; boundary="------------1339468C61E431C5BF82A962"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/xDIT_6R0cw_UT97scDYPArTbCYU>
Subject: Re: [netmod] handling module incompatibility => handling module transition
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: Sun, 08 Oct 2017 14:58:40 -0000
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 "semver.org 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 yangcatalog.org 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 <https://tools.ietf.org/html/rfc8049>."; 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 yangcatalog.org, 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": [ "draft-ietf-mpls-static-yang@ietf.org", "draft-ietf-mpls-base-yang@ietf.org", "draft-ietf-ospf-sr-yang@ietf.org", "draft-ietf-pim-yang@ietf.org", "draft-ietf-bier-bier-yang@ietf.org", "draft-zhang-bier-te-yang@ietf.org", "draft-ietf-isis-yang-isis-cfg@ietf.org", "draft-ietf-teas-yang-rsvp-te@ietf.org", "draft-ietf-mpls-mldp-yang@ietf.org", "draft-zhao-pim-igmp-mld-snooping-yang@ietf.org", "draft-ietf-isis-sr-yang@ietf.org", "draft-acee-rtgwg-yang-rib-extend@ietf.org", "draft-ietf-pim-igmp-mld-yang@ietf.org", "draft-ietf-i2rs-fb-rib-data-model@ietf.org", "draft-ietf-ospf-yang@ietf.org", "draft-ietf-rtgwg-yang-rip@ietf.org", "draft-ietf-spring-sr-yang@ietf.org", "draft-ietf-teas-yang-rsvp@ietf.org", "draft-ietf-i2rs-pkt-eca-data-model@ietf.org", "draft-ietf-mpls-ldp-yang@ietf.org", "draft-ietf-bfd-yang@ietf.org", "draft-ietf-pim-msdp-yang@ietf.org" ] } } 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) > > > . >
- [netmod] handling module incompatibility Lou Berger
- Re: [netmod] handling module incompatibility Robert Wilton
- Re: [netmod] handling module incompatibility Kent Watsen
- Re: [netmod] handling module incompatibility t.petch
- Re: [netmod] handling module incompatibility Juergen Schoenwaelder
- Re: [netmod] handling module incompatibility => h… Benoit Claise
- Re: [netmod] [RTG-DIR] handling module incompatib… Lou Berger
- Re: [netmod] [RTG-DIR] handling module incompatib… Benoit Claise
- Re: [netmod] handling module incompatibility Qin Wu
- Re: [netmod] [RTG-DIR] handling module incompatib… Benoit Claise
- [netmod] draft-clacla-netmod-yang-model-update-00… Benoit Claise
- Re: [netmod] draft-clacla-netmod-yang-model-updat… Juergen Schoenwaelder
- Re: [netmod] draft-clacla-netmod-yang-model-updat… Andy Bierman
- Re: [netmod] draft-clacla-netmod-yang-model-updat… Rob Shakir
- Re: [netmod] draft-clacla-netmod-yang-model-updat… Benoit Claise