Re: [netmod] [RTG-DIR] handling module incompatibility => handling module transition
Benoit Claise <bclaise@cisco.com> Sun, 15 October 2017 16:26 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 7A66A133047; Sun, 15 Oct 2017 09:26:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
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: 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 A8L9t9oTqqjZ; Sun, 15 Oct 2017 09:26:40 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F58C132F2E; Sun, 15 Oct 2017 09:26:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; 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: A0COAAApi+NZ/xbLJq1cGQEBAQEBAQEBAQEBBwEBAQEBgm9CgRJuJ4N6ih90kDOWLxCCBAolhRYChRUYAQIBAQEBAQEBayiFHgEFGglOCBAJAg4KIAEJAgJXBgEMBgIBAReKAhCMYp1ngicmiwIBAQEBAQEBAQEBAQEBAQEBAQEBAQEdgy2DWIFqK4J/hE0FARECAYMxgmEFih+CHIUMkAGHX4NiiSqCFF2Ic4cyiiKDbYdggTkfOIEDVjQhCB0VSYJkCYJTHIFpPjYBilsBAQE
X-IronPort-AV: E=Sophos;i="5.43,383,1503360000"; d="scan'208,217";a="698031719"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Oct 2017 16:26:36 +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 v9FGQaI0004063; Sun, 15 Oct 2017 16:26:36 GMT
From: Benoit Claise <bclaise@cisco.com>
To: Lou Berger <lberger@labn.net>, NetMod WG <netmod@ietf.org>
Cc: rtg-dir@ietf.org, draft-acee-netmod-rfc8022bis@ietf.org, draft-wu-l3sm-rfc8049bis.all@ietf.org
References: <caa884d9-9d71-e7ad-cffd-427b58750c58@labn.net> <751fa015-a917-a104-f6c6-25cc9a5accba@cisco.com> <15f105bf980.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <708ad6ca-e37b-6236-59b2-80c611b132ae@cisco.com>
Message-ID: <a623bac8-cf84-9c46-2fc8-1556197d295f@cisco.com>
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: <708ad6ca-e37b-6236-59b2-80c611b132ae@cisco.com>
Content-Type: multipart/alternative; boundary="------------86328339758D90C1C732FFA1"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/SNM9GfkzyfDvyDC6x0cFb0NHxMk>
Subject: Re: [netmod] [RTG-DIR] 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, 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. https://www.ietf.org/mail-archive/web/ietf-announce/current/maillist.html If a follow up is required, I propose that we use a single public email thread: the ietf@ietf.org 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 <bclaise@cisco.com> 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 "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