[netmod] Import by revision-date or label vs semantic version

"Rob Wilton (rwilton)" <rwilton@cisco.com> Wed, 02 September 2020 10:51 UTC

Return-Path: <rwilton@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 846C03A0EB7 for <netmod@ietfa.amsl.com>; Wed, 2 Sep 2020 03:51:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.598
X-Spam-Level:
X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 header.b=Ig0jRush; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=fpGUau7S
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 kdbhcAIHrWwN for <netmod@ietfa.amsl.com>; Wed, 2 Sep 2020 03:51:42 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAC533A0E11 for <netmod@ietf.org>; Wed, 2 Sep 2020 03:51:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4179; q=dns/txt; s=iport; t=1599043902; x=1600253502; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=dJv8vQ7AoX63otPBXzwfaoDHkETUfWAt9Vc6pJ/L2QY=; b=Ig0jRushfcpaZB1VAmViigCzDqJtP8hwMEOGSncVat46buWoU08V2PUl IpORqAy3qDn5PTLrNSpAASB6bnNezh0SyRI2hbCkCbneLnsXhHqTXAlRA cFE3PqT3ddcls/L/lMZfxmOwVRA6nu3f0E56C+eLFLyM3Ko08lLv48cLj M=;
IronPort-PHdr: 9a23:sT2FTR1SH4AhWsmHsmDT+zVfbzU7u7jyIg8e44YmjLQLaKm44pD+JxWGv6dsgUPHG4LB5KEMh+nXtvXmXmoNqdaEvWsZeZNBHxkClY0NngMmDcLEbC+zLPPjYyEgWsgXUlhj8iK6PFRbXsHkaA6arni79zVHHBL5OEJ8Lfj0HYiHicOx2qiy9pTfbh8OiiC6ZOZ5LQ69qkPascxFjA==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CUDwB0eE9f/4oNJK1gHQEBPAEFBQECAQkBFYFKAoFQUQdwWC8sCod0A6ZpgUKBEQNVCwEBAQwBASMKAgQBAYRLAoIjAiQ3Bg4CAwEBCwEBBQEBAQIBBgRthVwBC4YLKAYBATgRAT5CJgEEGxqDBYJLAy4BAwukZQKBOYhhdIE0gwEBAQWBNwKEDxiCEAMGgTgBgnCKNxuBQT+BVIIfg0gBAQOBJwESASODSIIttm4KgmUEiGSRa6BWklGKTpUJAgQCBAUCDgEBBYFqJCo9cHAVgyRQFwINkhCFFIVCdDcCBgoBAQMJfI48AYEQAQE
X-IronPort-AV: E=Sophos;i="5.76,381,1592870400"; d="scan'208";a="535710497"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 02 Sep 2020 10:51:41 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 082ApfBw023020 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for <netmod@ietf.org>; Wed, 2 Sep 2020 10:51:41 GMT
Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 2 Sep 2020 05:51:41 -0500
Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 2 Sep 2020 05:51:39 -0500
Received: from NAM10-BN7-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 2 Sep 2020 05:51:39 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CMQMpmkUy6ssXlKmGAkQuQt+TAUvwrENmlhOZ3SC4IFi55Dt70kuJWKSRyjcAQ/YeoLG+sCcFYMFW0c5705B9otdKnRfBZd0Ia+OrOaPBrCazGbR2mSBFKawVYSaUXuA+byqEWQ15b4g/rtn1sOj/iNhBA2dtJvIwt6pcaX4tqNvaHLJ3aCpXBL1Ljt4gKa4zyYwgSiWTu9z4o1GdiriB8iGBiwDbHb2IS3JQ90SgnRpwfTeeU///a0h19ISeKxG+JBqHLYTQWGwx/tUsog0rENDh1VXgtAIsfc1bdkHZBA6lFUOw8RQ8RRm75JjW/GH1ocW5DiN9H3lz610XtcrGQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FdfhLKYWCA6xxO+SdVr07i8nWvTG2sMSLF5VQ/XJ1eI=; b=lnIpFmHecTDJ/0ZnNlshZSGKcPUWLvEf2AYcInOHbXFoFEv8TtAzoGaF/g5tfz8WKl2JO4jSjR7kQcnxwQBYMWTob0tGI1A+SZBVfm7ov6/pLeaA0gKiaH53eMTO/uPptTRbTzmdK4GLKuWyjoZRGvPTt3wqH09VOFLW2+oM06mv5ic8PwZpfrA5yhK8lZ1smJz8Kwy6GFXK15oBsxHlZJnfWMnTrim49ffDE/2D0EAaa4T0YEXvssBAjwKmYS0P6chxznFAY7wR0nUoxhA87L8Tk6AUkw3+VK8bBaY0OGkCMXofnY5bRuWqixKM2FqMCRYda+nl1a7Kz3WcYlzODw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
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=FdfhLKYWCA6xxO+SdVr07i8nWvTG2sMSLF5VQ/XJ1eI=; b=fpGUau7S/sld+2vF3JRjRnrg8j7CKvOpRDr0PtoYo1eTx0XiVkRfCFEoRzNYEhfbgyqn3PBkYDmL4OKeWP7ikLpwFUovuHSceDUOYY0QNTtbVaIoX3GwoJAIvdw4JggMKOX2teP70mvSmpoNZ+51ULzr5jckbnRmwRnmA7hL6ks=
Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by BL0PR11MB3011.namprd11.prod.outlook.com (2603:10b6:208:7d::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3326.25; Wed, 2 Sep 2020 10:51:38 +0000
Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::4d3f:f3e:add7:dfc1]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::4d3f:f3e:add7:dfc1%3]) with mapi id 15.20.3305.026; Wed, 2 Sep 2020 10:51:38 +0000
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: Import by revision-date or label vs semantic version
Thread-Index: AdaBFsscPqOd+TnSR/qyxOf9nxjkWw==
Date: Wed, 02 Sep 2020 10:51:38 +0000
Message-ID: <MN2PR11MB4366EC1CC0D62CAC0B3B02A1B52F0@MN2PR11MB4366.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [82.15.79.32]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: e127377f-a6a9-42c8-86db-08d84f2e2b33
x-ms-traffictypediagnostic: BL0PR11MB3011:
x-microsoft-antispam-prvs: <BL0PR11MB30119FAD9BE8723A45156E1DB52F0@BL0PR11MB3011.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: o2YPLsbrItC2danx2u9AgOu4SaqNdsJAZBNAI/7b1j48POSPqtjelWC169457TLjegFvHTn/S6T8QEbckyJcaMCwEieUXfnoIF1evQ8LAgpjAx/bq5upzGjydyvNrtWjBZFKiFp+1BkvfqHVEVu8Lcd02JUq71fYzKIh+ZDld44o6H4IDJOLJ5CbnXZkbEWXOYwy5pVHitl4QHnRevHH1UpwUVpWfvc9ev9zVUpm56bAU6Z4S+8WwmSFO4y4MIwsJqVeh1xWFSU7FPKe6JtcMuBM/FdzJZubA03RrT0VNGCpAIQyZ5SmzwDXgvsFs0rSajACkjRkhFRQnmIyaDW/rciw6So+vwjemx+DGYx8kf5mTMJOtVRvz2oBVSGcsxg7rGebo1lKuptabBXGdM8H1Q==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4366.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(376002)(136003)(366004)(39860400002)(396003)(71200400001)(9686003)(64756008)(55016002)(2906002)(76116006)(6916009)(66946007)(66476007)(86362001)(8936002)(66556008)(83380400001)(66446008)(33656002)(478600001)(186003)(966005)(7696005)(26005)(6506007)(5660300002)(52536014)(8676002)(316002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: SWbNn6tjznBpb4/eCQ/QrTKL1j1McKIu/7cRnZ8ul/l5dDJfY1bVVDkfrTD6+cp4CYOFhEzQYvcW/zMTB9YFjy0cpOnPPnI7+zv8IvcYWXmlTESe+5a7niJTF7ZXRy4V9R87rAPqqgivEjAwCprpqT3CsAM3Lo8ibWQNR8XhdrojdvgUkHTG+OYLUedOpKH3JU37mx/j/AEPGOXcngV1w96Q869/0GoNPeJnah7z9gdRnznluy/4WjYQj/JZwpD4fTr2FGIg4a9ex3/np8HroNOe7d2CKKAEHeHvTJKy5jyEomutbf1k1HM97gKZBOOYxWR9pVJ0luykqO0rPWQWkeWP/HrN/+bdyCz5Upta/2BNIIV92aTsF48RE24EsDPWduQy9UD3ZgKgYyw4qP/WQlb+CTtgMCe3dn8HWjkxBK23jVglwqlq7TjY1Hq75nqdo0GjkcGkuSDOhs6YKNG498wEUAxj7pXCEz5x9xxI7RL1yziWj5RtLbr8IykLFVVbXvsnCZyeAJ0dViGFxleqB/xTvR37cCWnIc4XwtXcdfVLdWdxpYWSt17PkMPo3A8CDKIeFXwE7IRA5YwBXAuAZ5yqERoSSzcOwvQh4w//HxO7eh7kcLVo2GlRtNvJUoxZPl53lmVl5Ctlgo0B7z8aBA==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB4366.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e127377f-a6a9-42c8-86db-08d84f2e2b33
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Sep 2020 10:51:38.1314 (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: g3D9+SqaMwFzNjvPy7/to3zhZ963QuXSfgMRpdOPFcTNQfpgdDuCM8YloVnoev34OrDbAOGKwi6JBIrdT+WqEQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3011
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com
X-Outbound-Node: alln-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/t9fEock-o2vimLHwM9TlSGrTtgE>
Subject: [netmod] Import by revision-date or label vs semantic version
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 02 Sep 2020 10:51:45 -0000

Hi,

During the NETMOD 108 meeting I had made a comment that imports using revision-or-derived are not done using a semantic version number, but instead are done by revision label, which limits how they behave and what they are allowed to do.  Some participants were concerned that this might be confusing or even broken, and the outcome of that short discussion was that I should send an email to NETMOD with an example to help explain how they are proposed to work.

The main principle here is that the versioning drafts have a clear distinction between supporting an abstract version label vs a specific version label scheme (such as YANG Semver).

The new "revision-or-derived" extension is defined as part of base draft-ietf-netmod-yang-module-versioning.  The "revision-or-derived" extension takes a single argument that can either be a "revision date" or a "revision label".  It can be used regardless of the versioning scheme that is being used as a revision label, but therefore is also restricted to treating the revision label as an opaque textual label for a revision date.

So, making use of the examples in section 4.1 of https://tools.ietf.org/html/draft-ietf-netmod-yang-module-versioning-01

When a module has an import statement like this:

   import example-module {
     rev:revision-or-derived 2.0.0;
   }

Then the processing to find a suitable revision to import would be something like this (ignoring the issue of which revision is chosen from the set of suitable candidate revisions): 

1) Iterate suitable candidate "example-module" YANG files.
2) For each candidate file, parse the revision history, and check back through the revision history to see if a revision with label "2.0.0" exists.  If it does, then that module revision is a suitable candidate for import.  If no revision with label "2.0.0" exists then that module revision does not satisfy the import.  Note the tooling does not need to understand the format of the revision label at all, a textual comparison between labels is sufficient.

The algorithm works equivalently if the import was done using a revision date instead of a label (e.g., rev:revision-or-derived 2019-02-01), except that obviously the comparison in the revision history is done on the revision date rather than the revision labels.


-------

So, how does this interact with YANG Semver (or vanilla Semver 2.0.0)?

Well, this still works because each version of a YANG module contains the revision history back to the root of the version tree.

E.g., the YANG file defining version 2.2.0 would contain revisions for versions 2.2.0, 2.1.0, 2.0.0, 1.0.0 in its revision history, and hence would satisfy an import using label "2.0.0" or derived" solely because a revision with that label exists in its revision history.

However, if the revision history had entries pruned (i.e., perhaps 2.1.0 hadn't been included in the revision history so that it was just 2.2.0, 2.0.0, 1.0.0) then this particular YANG file for version 2.2.0 WOULD NOT satisfy an import for "revision-or-derived 2.1.0;" because the module's revision history does not contain revision 2.1.0.

So, the import revision-or-derived works fine for Semver version labels as long as the revision history is consistent and complete.

-------

Finally, there has been some discussion about whether it would be useful to have an import statement that restricts imports to only backwards compatible versions - I'll post a separate email on this.

If the WG decided that this is useful, then this could still be supported, and without needing to understand the revision label.  Instead, it can be done by checking the revision history for the "rev:nbc-changes" substatement that indicates where NBC changes have occurred in the revision history.  As long as the allocated YANG Semver revision labels are consistent with the use of the rev:nbc-changes" substatement in the revision history then it would still behave in the intuitive way. 


Regards,
Rob

[As an individual contributor]