Re: [Netmod-ver-dt] Comments on draft-verdt-netmod-yang-module-versioning.txt (May 16 version)
"Rob Wilton (rwilton)" <rwilton@cisco.com> Tue, 04 June 2019 09:14 UTC
Return-Path: <rwilton@cisco.com>
X-Original-To: netmod-ver-dt@ietfa.amsl.com
Delivered-To: netmod-ver-dt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2451200B2 for <netmod-ver-dt@ietfa.amsl.com>; Tue, 4 Jun 2019 02:14:21 -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 header.b=XSumgkUJ; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=veEhMqhK
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 osTrp1NeysR9 for <netmod-ver-dt@ietfa.amsl.com>; Tue, 4 Jun 2019 02:14:15 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BD75120074 for <netmod-ver-dt@ietf.org>; Tue, 4 Jun 2019 02:14:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=118877; q=dns/txt; s=iport; t=1559639655; x=1560849255; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=fmCPg/+qJ5pVoaLjyKPiQSiqFhI0oa1IY1rg+zRRCT8=; b=XSumgkUJCLg7mfiU//iqg9/PW2qHoViLKBAnvU4zFaDk90AnfFVUl+Mf UZG6rFW4kS1hPm9Xenabyj+j+8oHNaetxC47w3QfipOC8hdC5XDge62Nu 7QUp531RGs9UBXfGODDuRFt2uzMZT0QyGfaJ0xHTLq1QPEjk2MWDmoM+V g=;
X-Files: draft-verdt-netmod-yang-module-versioning (2).txt : 60334
IronPort-PHdr: 9a23:jDoS9hEW6uiyW4im4zDz8Z1GYnJ96bzpIg4Y7IYmgLtSc6Oluo7vJ1Hb+e4z1A3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNVcejNkO2QkpAcqLE0r+eeT1bigmG8JqX15+9Hb9Ok9QS47z
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AWAACVNfZc/40NJK1jAxoBAQEBAQIBAQEBBwIBAQEBgVIEAQEBAQsBgQ4vJAUnA2pVIAQLKAqHUQOOdBqCPZcvgS4UgRADVAIHAQEBDAEBJwYCAQGEQAKCUCM1CA4BAwEBBAEBAgEEbRwMhUoBAQEBAxIIAQwGEwEBMAgNAgIBCBEEAQEhAQYHAhkXFAkIAQEEARIIBg0HgwGBagMdAQIMnFcCgTiIX4FvM4J5AQEFgUZBgwUYgggHCQWBLwGFS4YOF4FAP4EQAUaBTn4+gQR1XQsCA4EjCAELBwEHAhMFBAYCCQoFBgEJAgINgnWCJosxITCBa4UZIId7GIxjagkCgg6DH4MihAxCg26EU4IjLzmGDIV1hiKBRoQTiHaBKYVkjCeCbwIEAgQFAg4BAQWBUAE2Z3FwFTuCbAmCBhESgQIBAoJIhFk7hT4BcoEpjW4PF4ELAYEgAQE
X-IronPort-AV: E=Sophos;i="5.60,550,1549929600"; d="txt'?scan'208,217";a="285351058"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 Jun 2019 09:14:12 +0000
Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id x549EBNF027241 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 4 Jun 2019 09:14:12 GMT
Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 4 Jun 2019 04:14:11 -0500
Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 4 Jun 2019 04:14:10 -0500
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 4 Jun 2019 04:14:10 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CY3UjorI1X2YuudU43Lh7AuriZnSHwrEmDoLVRs+934=; b=veEhMqhKWC4aqvwF8JMaR0N9RaKRxtPVOoGfT5AEaLbkQ0/T51qfXx589OoqCczn5MzcrnwlRS+9g3AjN+N5oYZ49r/b4oSSXVYbMSQdGJmN9c5drvWTMGk/l6m5oaOzgGFZtDii+GABwD/0Cs6IJm6yQm5UYokmm4Ep+Tfylkc=
Received: from BYAPR11MB2631.namprd11.prod.outlook.com (52.135.227.28) by BYAPR11MB2743.namprd11.prod.outlook.com (52.135.227.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1943.22; Tue, 4 Jun 2019 09:14:09 +0000
Received: from BYAPR11MB2631.namprd11.prod.outlook.com ([fe80::d837:c1dd:cdb1:bb78]) by BYAPR11MB2631.namprd11.prod.outlook.com ([fe80::d837:c1dd:cdb1:bb78%7]) with mapi id 15.20.1943.018; Tue, 4 Jun 2019 09:14:09 +0000
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: "Sterne, Jason (Nokia - CA/Ottawa)" <jason.sterne@nokia.com>, "netmod-ver-dt@ietf.org" <netmod-ver-dt@ietf.org>
Thread-Topic: Comments on draft-verdt-netmod-yang-module-versioning.txt (May 16 version)
Thread-Index: AdURb21sAkuH8qSrRduJlr3VI5Xo1gJRM+TQ
Date: Tue, 04 Jun 2019 09:14:08 +0000
Message-ID: <BYAPR11MB2631A012B0EF45E6F8313CD8B5150@BYAPR11MB2631.namprd11.prod.outlook.com>
References: <VI1PR07MB39811366C619F54ECD73EE3D9B010@VI1PR07MB3981.eurprd07.prod.outlook.com>
In-Reply-To: <VI1PR07MB39811366C619F54ECD73EE3D9B010@VI1PR07MB3981.eurprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rwilton@cisco.com;
x-originating-ip: [173.38.220.56]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b0fdbcdc-ce85-425e-d046-08d6e8cd005c
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(49563074)(7193020); SRVR:BYAPR11MB2743;
x-ms-traffictypediagnostic: BYAPR11MB2743:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <BYAPR11MB27435AA56251A1238AB38959B5150@BYAPR11MB2743.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0058ABBBC7
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(39860400002)(396003)(346002)(376002)(366004)(51444003)(189003)(199004)(606006)(11346002)(86362001)(33656002)(14454004)(52536014)(446003)(9326002)(476003)(229853002)(81166006)(81156014)(68736007)(2906002)(6436002)(73956011)(8936002)(66446008)(966005)(5660300002)(66616009)(66946007)(66556008)(76116006)(64756008)(66476007)(2501003)(478600001)(186003)(9686003)(110136005)(3846002)(6116002)(99286004)(486006)(296002)(316002)(256004)(14444005)(5024004)(26005)(790700001)(8676002)(53936002)(7736002)(99936001)(7696005)(76176011)(102836004)(71190400001)(66066001)(71200400001)(25786009)(6506007)(53546011)(561944003)(6246003)(6306002)(54896002)(236005)(74316002)(55016002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB2743; H:BYAPR11MB2631.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: wO2NfyhAe87QU23WgyWygPLo+LrOiG5+Eagj66nYGOyF47uG1ARSjX6PkXZc5Sm7Kez3mTXhMOx6mMMDecL6WrkbT6YQer7q0EF0Jj+hFeq7X4t3NJ92rP43woTgwB/tKSBhgA50CyYv9Zfy3bjl6xjr5qr9jHv+NDM8poz+2Pf4Vq6aa5YWwTS5qWHELqDWwxA7z7dfH1sp3vhGeYfGMTUZ9zgdFRCYxGmqnYE5mkLWL2yxO54uurvHOETb4ZzVbdD3BebuRwPnextanwrC54gv8RV2iQgZeIqTdgw8D+44/kmvAPKdLY5nIb8kcS/U2NvdggBGrazaLYApmQaoo3VG3AmOcwSPwQp1fPs9AsK1hLUy7uRf7vD4DaK48QETXu+JQrZQqhvrGY2HUfe10+PvBgJmrPN1zCBlHqISf7g=
Content-Type: multipart/mixed; boundary="_004_BYAPR11MB2631A012B0EF45E6F8313CD8B5150BYAPR11MB2631namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: b0fdbcdc-ce85-425e-d046-08d6e8cd005c
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jun 2019 09:14:08.4010 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: rwilton@cisco.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2743
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.23, xch-aln-013.cisco.com
X-Outbound-Node: alln-core-8.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod-ver-dt/73-ABYVlNCB838tyz0A3CTVv184>
Subject: Re: [Netmod-ver-dt] Comments on draft-verdt-netmod-yang-module-versioning.txt (May 16 version)
X-BeenThere: netmod-ver-dt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NetMod WG YANG Model Versioning Design Team <netmod-ver-dt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod-ver-dt>, <mailto:netmod-ver-dt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod-ver-dt/>
List-Post: <mailto:netmod-ver-dt@ietf.org>
List-Help: <mailto:netmod-ver-dt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod-ver-dt>, <mailto:netmod-ver-dt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Jun 2019 09:14:21 -0000
Hi Jason, I've attached the latest version of the doc, after applying the comments from Balazs's review. Inline with [RW] From: Netmod-ver-dt <netmod-ver-dt-bounces@ietf.org> On Behalf Of Sterne, Jason (Nokia - CA/Ottawa) Sent: 23 May 2019 14:57 To: netmod-ver-dt@ietf.org Subject: [Netmod-ver-dt] Comments on draft-verdt-netmod-yang-module-versioning.txt (May 16 version) Hi guys, Some comments on this file (May 16 version): https://github.com/netmod-wg/yang-ver-dt/blob/develop/yang-mod-ver/draft-verdt-netmod-yang-module-versioning.txt (A) Replace this abstract: This document specifies a new YANG module update procedure to allow for limited non-backwards-compatible changes, as an alternative proposal to module update rules in the YANG 1.1 specifications. This document updates RFC 7950, RFC 8407 and RFC 8525. with this (to avoid the implication that we are simply trying to "allow" NBC changes): This document specifies a method for documenting non-backwards-compatible changes that have occurred in a YANG module. Guidelines for managing the lifecycle of YANG modules are also provided. This document updates RFC 7950 (primarily the module update rules), RFC 8407 and RFC 8525. [RW] I've merged, and expanded this slightly. What about the following text? This document specifies a new YANG module update procedure that can document when non-backwards-compatible changes have occurred during the evolution of a YANG module. It provides a variant to the YANG import statement to better represent inter-module dependencies. It provides help and guidelines for managing the lifecycle of YANG modules and individual schema nodes. This document updates RFC 7950, RFC 8407 and RFC 8525. (B) replace this paragraph in section 1: Specifically, this document recognises a need to sometimes allow YANG modules to evolve with non-backwards-compatible changes, which could cause breakage to clients and importing YANG modules. with the following: Specifically, this document recognises a need to describe when a non-backwards-compatible (NBC) change has occurred in a YANG module [optional: in cases where the NBC change has been deemed necessary]. An NBC change can cause an incompatibility between a client using an older revision of the YANG module and a server using a newer revision. [RW] After updating with the comments from Balazs, the current text is: Specifically, this document recognises a need (within standards organizations, vendors, and the industry) to sometimes allow YANG modules to evolve with non-backwards-compatible changes, which could cause breakage to clients and importing YANG modules. Accepting that non-backwards-compatible changes do sometimes occur, it is important to have mechanisms to report where these changes occur, and to manage their effect on clients and the broader YANG ecosystem. I think that it is OK to say that NBC changes are sometimes allowed, specifically that is what our guidelines text currently states. I agree that there may still be push back on this. (C) In section 2, remove the following sentence from its paragraph/bullet and separate it down into its own paragraph fully left justified. It isn't really part of the list of 'updates' to RFC7950. We're just reinforcing that a rule is still in place. As per [RFC7950], YANG module revisions continue to be uniquely identified by the module's revision-date, and hence all revisions of a module MUST have unique revision dates. (D) In section 2.1, replace this text: This section updates [RFC7950] chapter 11 to provide a more flexible approach that allows for some non-backwards-compatible changes during YANG module updates. Where pragmatic, updates to YANG modules SHOULD be backwards- compatible, as described in Section 2.1.1. with this (the guidelines can recommend to avoid NBC changes, and what we're changing here in this particular section doesn't really directly allow or support NBC changes anyways): This section updates [RFC7950] chapter 11 to modify and clarify the definition of a non-backwards-compatible (NBC) change, and to allow a method of describing when an NBC change occurs in a YANG module. (E) section 2.1.2 -> change ' brekaage' to 'breakage' I'm also not sure if the examples of NBC changes makes sense to include here. Especially the 2nd, 4th 5th and 6th bullets which are clearly described already in section 11 of RFC 7950. Maybe just keep examples 1 & 3 and any others that are somewhat new based on our updates, or aren't terribly clear in section 11 of RFC 7950 That's as far as I've gotten for now. [RW] I've quite heavily reworked the initial parts of section 2. Please can you check whether you think that these comments still apply with the current text: 2. Refinements to YANG revision handling [RFC7950] assumes, but does not explicitly state, that the revision history for a YANG module is strictly linear, i.e., it is prohibited to have two independent revisions of a YANG module that are both directly derived from the same parent revision. This document clarifies [RFC7950] to explicitly allow non linear development of YANG module revisions, so modules MAY have multiple revisions that directly derive from the same parent revision. As per [RFC7950], YANG module revisions continue to be uniquely identified by the module's revision-date, and hence all revisions of a module MUST have unique revision dates. [RFC7950] chapter 11 requires that all updates to a YANG module are backwards compatible to the previous revision of the module. This document allows for more flexible evolution of YANG modules: Non- backwards-compatible changes between module revisions are allowed and are documented using a new 'nbc-changes' extension statement in the module revision history. 2.1. Updating a YANG module with a new revision This section updates [RFC7950] chapter 11 to refine the rules for permissible changes when a new YANG module revision is created. Where pragmatic, updates to YANG modules SHOULD be backwards- compatible, following the definition in Section 2.1.1. A new module revision MAY contain non-backwards-compatible changes, i.e., the semantics of an existing definition MAY be changed in a non-backwards-compatible way without requiring a new definition with a new identifier. A new module revision with non-backwards- compatible changes MUST include a 'rev:nbc-changes' extension substatement to signal the potential for incompatibility to existing module users and readers. 2.1.1. Backwards-compatible changes The following statements update [RFC7950] chapter 11 to define what changes constitute an allowable backwards-compatible change to a YANG module: o A "status" "deprecated" statement may be added, or changed from "current" to "deprecated", but adding or changing "status" to "obsolete" is not a backwards-compatible change. o Obsolete definitions MAY be removed from published modules, and are classified as backwards-compatible changes. In some circumstances it may be helpful to retain the obsolete definitions to ensure that their identifiers are not reused with a different meaning. o In statements that have any data definition statements as substatements, those data definition substatements MAY be reordered, as long as they do not change the ordering or any 'rpc' 'input' substatements. If new data definition statements are added, they can be added anywhere in the sequence of existing substatements. 2.1.2. Non-backwards-compatible changes Any changes to YANG modules that are not classified by Section 2.1.1 as being backwards-compatible are classified as 'non-backwards- compatible' changes. One particular change to [RFC7950] chapter 11 is that adding or changing a 'status' state to 'obsolete' is classified as a non- backwards-compatible change, because it could break any clients relying on servers implementing the obsoleted data node. 2.2. nbc-changes revision extension statement ... Thanks, Rob Jason
- [Netmod-ver-dt] Comments on draft-verdt-netmod-ya… Sterne, Jason (Nokia - CA/Ottawa)
- Re: [Netmod-ver-dt] Comments on draft-verdt-netmo… Rob Wilton (rwilton)
- Re: [Netmod-ver-dt] Comments on draft-verdt-netmo… Sterne, Jason (Nokia - CA/Ottawa)