Re: [netmod] All IETF YANG modules MUST include revision-label statements

"Sterne, Jason (Nokia - CA/Ottawa)" <jason.sterne@nokia.com> Tue, 31 March 2020 16:48 UTC

Return-Path: <jason.sterne@nokia.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 36C253A2419 for <netmod@ietfa.amsl.com>; Tue, 31 Mar 2020 09:48:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 q3qgAMFvOIQM for <netmod@ietfa.amsl.com>; Tue, 31 Mar 2020 09:48:13 -0700 (PDT)
Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2097.outbound.protection.outlook.com [40.107.244.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB3BD3A1878 for <netmod@ietf.org>; Tue, 31 Mar 2020 09:48:12 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=R0nYP18/a2dxBW3Xbotpfv9e2+wQy61+/Leq+rIKxC3HArZFRImOD6EiCSby17/sp/67H0h1j378r0oIJaEWy0NIreHXiUfNhJpGmHM6QD8d7LPeUtTnBsmnugHbmmRPiXjaS71iyA5ztgtKvsJyQzG+BDehpnij4fFMkr6ZkZcdOWpSc/J+EQC/FxG0Yv0LN3ucZo2MVtuhHLrIl4q/eUZvr/3CJ8U/RsEekBKRDaaivp01DwA1YpJKkGoIuaib/7sdKni7QsXDj6upsxVKBpYouG/6pD9KZJzBM60nAKng3Q/0jIaVZ9xoa07EzEhzq0CtEHZMBrUnekbxTGgZng==
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=d1CilNvsmXNO3HQeXSIVTVLcexSKK9PMvgW/MsDZg/I=; b=ePX73u9YgccRRx3K0FK8XHrF/9+S1tcxYn1I2StLvZmHSVA6KIFwLu8VnAEv8gltvtIDmDHjFWxCs2kGzwreushX7cLG/yrsZFJg/jXP6adi/evFU5IxUHTCOhyqjxLTk85SDMh7cQVZC9YWMREGXVk3KDs+61SmmvIsbMoNeHSnhfc4W7zF1c+E8aPRweMSodvwmMBx6Ev4jJEEkS+eu/y7N0kE/DkHdxmosd8c446cs5N0cpROOCyx8/lDgei4t5uzECTGjD6jwCSih3esExJ9fjZRD/aK9MMsmVfOL5BeDQLHDriNrDjDXp2S2KQF4LpCkgwjBi7gEX0XbR/uZg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=d1CilNvsmXNO3HQeXSIVTVLcexSKK9PMvgW/MsDZg/I=; b=jUJ8saBsr143kbkITAMp7q2DgRe/4zLGinbmsSM9tSH3LnGqNNa7DZ3kbiwtUWaC3g0gsPiEgX19W3v/UXOJY7yCFV1GfHqyk+hq90uy+Qq3PnTITVICd+oYG05MMcc/rdx9Vzn4ivLrwCNV/MPk8m9ibgTNx7WC+mScuV6FKgM=
Received: from DM5PR08MB2633.namprd08.prod.outlook.com (2603:10b6:3:ca::21) by DM5PR08MB3481.namprd08.prod.outlook.com (2603:10b6:4:66::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.20; Tue, 31 Mar 2020 16:48:09 +0000
Received: from DM5PR08MB2633.namprd08.prod.outlook.com ([fe80::c00d:56c3:675e:ec63]) by DM5PR08MB2633.namprd08.prod.outlook.com ([fe80::c00d:56c3:675e:ec63%3]) with mapi id 15.20.2856.019; Tue, 31 Mar 2020 16:48:09 +0000
From: "Sterne, Jason (Nokia - CA/Ottawa)" <jason.sterne@nokia.com>
To: "Reshad Rahman (rrahman)" <rrahman@cisco.com>, "Ivory, William" <william.ivory@intl.att.com>, "mbj+ietf@4668.se" <mbj+ietf@4668.se>
CC: "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] All IETF YANG modules MUST include revision-label statements
Thread-Index: AQHWBtNsM0hFMwGcFk22QjMBKcTjZ6hhqAFwgAAE4QCAAAW5gIAAnvsAgACM3ICAAAl+sIAAAmmA
Date: Tue, 31 Mar 2020 16:48:09 +0000
Message-ID: <DM5PR08MB263312F04224546549A595BA9BC80@DM5PR08MB2633.namprd08.prod.outlook.com>
References: <047FB87D-37B2-41F4-86D2-B9A03050B4EB@cisco.com> <20200330.223957.1196399215343087647.id@4668.se> <DM5PR08MB2633E6B1CA925B2D6E4B3AAE9BCB0@DM5PR08MB2633.namprd08.prod.outlook.com> <20200330.235046.60166687757387667.id@4668.se> <23333468-9959-4ECA-B529-73E1D906E3E9@cisco.com> <5f184f8673fafbb8eff0ae8b0a19f81409fa45e1.camel@intl.att.com> <B93C60F3-9A67-4E7A-8C84-64E6937F738B@cisco.com> <DM5PR08MB2633A647E9910A09DB1F65F49BC80@DM5PR08MB2633.namprd08.prod.outlook.com>
In-Reply-To: <DM5PR08MB2633A647E9910A09DB1F65F49BC80@DM5PR08MB2633.namprd08.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=jason.sterne@nokia.com;
x-originating-ip: [65.110.221.64]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 0db43e20-cb05-4530-1d3c-08d7d5934b40
x-ms-traffictypediagnostic: DM5PR08MB3481:
x-microsoft-antispam-prvs: <DM5PR08MB34813A2946C3EBCBB01D15119BC80@DM5PR08MB3481.namprd08.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:6790;
x-forefront-prvs: 0359162B6D
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR08MB2633.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10019020)(4636009)(376002)(366004)(396003)(136003)(346002)(39860400002)(66574012)(33656002)(9686003)(478600001)(71200400001)(53546011)(316002)(7696005)(76116006)(110136005)(4326008)(6506007)(2906002)(66946007)(66476007)(86362001)(30864003)(186003)(8936002)(966005)(66446008)(2940100002)(8676002)(5660300002)(66556008)(52536014)(81156014)(64756008)(81166006)(55016002)(26005)(579004)(559001); DIR:OUT; SFP:1102;
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: GPbyrMNcGAmK6zO81dEvRp2YckwmRx97WaZpUqGIDp9sYFzYJbTnFcanW4YpQQInIdQC47gDMWFba5yrBk/QW/JNZZLqxf3UTfLx1cQNUq9RwEEcTniOwk7+iKnue8AQJC/v4VE6fXr0MrtzYJLvHt+Cjpf+kqD4NDzwhlcZs0HV+4lRJ8dKPhbhanzCTnPktd4IKcE81x6/xWt1ynG4hwWXdL8pcf9YquicbjDoEcJFGKBRfyN5FRsTs/BYmftbvypA2EdNqyQBKzqZEyLoiCbMsID9wSYdMKySbv9TFUxCudU+keWn7rxwvRKZ4KiM8tLScyMC653A8pUYhsYVR2WZbHtpT5TABQwookFEeJvTbv+xWDcWsnVEzZt7os8YrUWYkuZ5hsmk0yehtDYZ9Xe1BYmV8RQIR8Wj/OneVNp/Q9xVJ3KsDFSTLnkl/ZLYLF6f/PI2V0UKsj8VIZXs4iPFtbKQ3Iw8T/GuT0oWk/Alz+oK5S0/XimEtH5gepj0vUPuWvDqOuFXvMf7jC94WA==
x-ms-exchange-antispam-messagedata: W0ddmgrfpn2PUrOVFWtvvRTM/fL2sKhh9PyyWORwoqhuVnsrAa6jFI7cncUiwqikY6Rzcci1twxIHol3a0chYIVgN5Oq/j+n9CyzfKIqm8IBbsm0EWAlWMJ2IjixmYHclI9Ru/M+NimRgNcZfZ2o6Q==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_DM5PR08MB263312F04224546549A595BA9BC80DM5PR08MB2633namp_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0db43e20-cb05-4530-1d3c-08d7d5934b40
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Mar 2020 16:48:09.3557 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 1kj2BaWUypVIVJW4h5hhl/7HPEi9zlgHLgC76sNjiTWlhin2sV22vyyjxLAYoZrYld6Kl5enA8kXi4xZrZk8Xg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR08MB3481
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/9C-D5gfPJdVz4wqncZ-hyXX2rK4>
Subject: Re: [netmod] All IETF YANG modules MUST include revision-label statements
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: Tue, 31 Mar 2020 16:48:17 -0000

Darn - poor choice of my first example.  I meant this:

1.0.0 -> 1.1.0 -> 2.0.0 -> 3.0.0 -> 1.2.0

would be confusing comparing 1.0.0 and 1.2.0.

(I wasn't trying to illustrate a "loop", or coming back to a file that was the same content as previously)

From: Sterne, Jason (Nokia - CA/Ottawa)
Sent: Tuesday, March 31, 2020 12:42 PM
To: Reshad Rahman (rrahman) <rrahman@cisco.com>om>; Ivory, William <william.ivory@intl.att.com>om>; mbj+ietf@4668.se
Cc: netmod@ietf.org
Subject: RE: [netmod] All IETF YANG modules MUST include revision-label statements

The idea is that following down a chain of YANG versions of a module results in a semver that is "cumulative".  Just like you can't do this:

1.0.0 -> 1.1.0 -> 2.0.0 -> 3.0.0 -> 1.1.0

That would be confusing when comparing 1.0.0 and 1.1.0. The numbers would imply they are BC.

Once you mark an "M" you can't take it away.

In William's example, someone looking at 1.0.4 vs 1.0.2 would think they are BC with each other (by just looking at the yang semver.

We'd rather err on the side of "false positives" for an NBC change so that someone looks into it.  (e.g. 1.0.3M -> 1.0.4M may not be an NBC change but users should look just in case).

Jason

From: Reshad Rahman (rrahman) <rrahman@cisco.com<mailto:rrahman@cisco.com>>
Sent: Tuesday, March 31, 2020 12:04 PM
To: Ivory, William <william.ivory@intl.att.com<mailto:william.ivory@intl.att.com>>; mbj+ietf@4668.se<mailto:mbj+ietf@4668.se>; Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com<mailto:jason.sterne@nokia.com>>
Cc: netmod@ietf.org<mailto:netmod@ietf.org>
Subject: Re: [netmod] All IETF YANG modules MUST include revision-label statements

Hi,

Thanks for the suggestion.

This was discussed, I think the reason we didn’t go with that solution is that (as you mentioned) you need the module contents with all the previous version labels. Does anyone from the design team recall any other details?

Regards,
Reshad.

From: "Ivory, William" <william.ivory@intl.att.com<mailto:william.ivory@intl.att.com>>
Date: Tuesday, March 31, 2020 at 3:40 AM
To: "mbj+ietf@4668.se<mailto:mbj+ietf@4668.se>" <mbj+ietf@4668.se<mailto:mbj+ietf@4668.se>>, "jason.sterne@nokia.com<mailto:jason.sterne@nokia.com>" <jason.sterne@nokia.com<mailto:jason.sterne@nokia.com>>, "Reshad Rahman (rrahman)" <rrahman@cisco.com<mailto:rrahman@cisco.com>>
Cc: "netmod@ietf.org<mailto:netmod@ietf.org>" <netmod@ietf.org<mailto:netmod@ietf.org>>
Subject: Re: [netmod] All IETF YANG modules MUST include revision-label statements

Apologies if this has already been suggested and deemed unworkable, but if you have access to all previous version labels for a branch then you can add 'M' only to the versions that are NBC with the previous version, and subsequent versions could drop the M until the next NBC change, ie:

1.0.0 -> 1.0.1 -> 1.0.2 > 1.0.3M -> 1.0.4 -> 1.0.5M ...

Here 1.04 is BC with 1.03 but not 1.0.0 - 1.0.2; 1.0.5 is NBC with 1.0.4 and previous versions etc.

The revision statements contain the revision-labels so you should have all the previous revision-labels present in the file, and you have all the data you need. Now you don't have the problem of the branch being poisoned as soon as the first M is added.

William

On Mon, 2020-03-30 at 22:11 +0000, Reshad Rahman (rrahman) wrote:

On 2020-03-30, 5:51 PM, "Martin Björklund" <mbj+ietf@4668.se<mailto:mbj+ietf@4668.se>> wrote:



    "Sterne, Jason (Nokia - CA/Ottawa)" <jason.sterne@nokia.com<mailto:jason.sterne@nokia.com>> wrote:

    > > But it is not true.  What happened between 1.0.2M and 1.0.3M?

    >

    > It tells you there is an NBC change between 1.0.2M and 1.0.3M.



    No.  As you note below it says that all bets are off.  The change

    between these two could be a spelling error fix.  Hence, Reshad's

    statement that "The revision label allows a user to easily figure out

    whether 2 revisions are (N)BC." is not correct.

You are correct that once a branch is poisoned with an 'M', the information provided is not as rich.

Even though you don't know whether 1.0.3M is BC/NBC with 1.0.2M, you still know that

- 1.0.2M is NBC with 1.0.1 and 1.0.0

- 1.0.3M is NBC with 1.0.1 and 1.0.0

- 1.0.1 is BC with 1.0.0



Still useful IMO.



Regards,

Reshad.



    > The M gives an indication that a branch has been "poisoned" by an

    > NBC change and that all bets are off from that point onwards in that

    > branch.





    /martin





    >

    > > -----Original Message-----

    > > From: netmod <netmod-bounces@ietf.org<mailto:netmod-bounces@ietf.org>> On Behalf Of Martin Björklund

    > > Sent: Monday, March 30, 2020 4:40 PM

    > > To: rrahman@cisco.com<mailto:rrahman@cisco.com>

    > > Cc: netmod@ietf.org<mailto:netmod@ietf.org>

    > > Subject: Re: [netmod] All IETF YANG modules MUST include revision-label

    > > statements

    > >

    > > "Reshad Rahman (rrahman)" <rrahman@cisco.com<mailto:rrahman@cisco.com>> wrote:

    > > >

    > > > On 2020-03-30, 2:20 PM, "Martin Björklund" <mbj+ietf@4668.se<mailto:mbj+ietf@4668.se>> wrote:

    > > >

    > > >     "Reshad Rahman (rrahman)" <rrahman@cisco.com<mailto:rrahman@cisco.com>> wrote:

    > > >     > On 2020-03-28, 4:41 AM, "Martin Björklund" <mbj+ietf@4668.se<mailto:mbj+ietf@4668.se>> wrote:

    > > >     >

    > > >     >     "Reshad Rahman (rrahman)" <rrahman@cisco.com<mailto:rrahman@cisco.com>> wrote:

    > > >     >     > Hi,

    > > >     >     >

    > > >     >     > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_netmod-2Dwg_yang-2Dver-2Ddt_issues_45&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=p8kyeK3u4ZYiaQ2ZPGqwkyXmQgBH6r5jpYiYWzhqJ48&m=ffH268c0xOd0DSFLQzZ2JHAmCHjVzPJVJtGPNxiiJcs&s=nyxzbv7ZWMgcXuMEW8MqjeT3oVxla6qFiF96M8SaMUY&e=

    > > >     >     >

    > > >     >     >         o  7.1

    > > >     >     >

    > > >     >     >           The text says:

    > > >     >     >

    > > >     >     >             All IETF YANG modules MUST include revision-label statements

    > > for

    > > >     >     >             all

    > > >     >     >             newly published YANG modules, and all newly published

    > > revisions of

    > > >     >     >             existing YANG modules.  The revision-label MUST take the form

    > > of a

    > > >     >     >             YANG semantic version number [I-D.verdt-netmod-yang-

    > > semver].

    > > >     >     >

    > > >     >     >           I strongly disagree with this new rule.  IETF modules use a linear

    > > >     >     >           history, so there are no reasons to use "modified semver".

    > > >     >     >

    > > >     >     >           It is ok to use rev:nbc-changes if needed, though.

    > > >     >     >

    > > >     >     > We believe some IETF models may not follow linear history, this was

    > > >     >     > brought up (I think) for IDR. Modified semver allows for non-linear

    > > >     >     > history and also doesn't preclude linear history. So even if we end up

    > > >     >     > having no IETF modules using branching, modified semver still works.

    > > >     >

    > > >     >     With the clarifiactions and updates in

    > > >     >     draft-verdt-netmod-yang-module-versioning, non-linear versioning

    > > >     >     works without modified semver.  So there is no technical reason to use

    > > >     >     modified semver in IETF modules.

    > > >     >

    > > >     > So are you proposing we use some other revision-label scheme (e.g.

    > > semver 2.0.0) for IETF modules?

    > > >     >

    > > >     > Or that IETF modules shouldn't use revision-labels?

    > > >

    > > >     That IETF shouldn't use revision labels.

    > > >

    > > > The revision label allows a user to easily figure out whether 2

    > > > revisions are (N)BC.

    > >

    > > I think you meant "modified semver as revision label allows ..."

    > >

    > > But it is not true.  What happened between 1.0.2M and 1.0.3M?

    > >

    > >

    > > /martin

    > >

    > >

    > > > Without the label, you always have to use tooling.

    > > >

    > > > Regards,

    > > > Reshad.

    > > >

    > > >     I am all for using rev:nbc-changes or rev:editorial-changes (which I

    > > >     think should be added) in IETF modules.

    > > >

    > > >

    > > >     /martin

    > > >

    > > >

    > > >     >

    > > >     > Or do you have something else in mind?

    > > >     >

    > > >     > Regards,

    > > >     > Reshad.

    > > >     >

    > > >     >     I can reluctantly accept that modified smever is published as

    > > >     >     Experimental.  But that doesn't mean that IETF modules should use it.

    > > >     >

    > > >     >

    > > >     >     /martin

    > > >     >

    > > >     >

    > > >     >     >

    > > >     >     > Regards,

    > > >     >     > Reshad.

    > > >     >     >

    > > >     >     >

    > > >     >     > On 2020-03-20, 5:08 PM, "netmod on behalf of Reshad Rahman

    > > (rrahman)"

    > > >     >     > <netmod-bounces@ietf.org<mailto:netmod-bounces@ietf.org> on behalf of

    > > >     >     > rrahman=40cisco.com@dmarc.ietf.org<mailto:rrahman=40cisco.com@dmarc.ietf.org>> wrote:

    > > >     >     >

    > > >     >     >     Hi Martin,

    > > >     >     >

    > > >     >     >     We've opened issues to track your review comments (see below).

    > > Will

    > > >     >     >     kick off separate therads for each issue.

    > > >     >     >

    > > >     >     >     https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_netmod-2Dwg_yang-2Dver-2D&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=p8kyeK3u4ZYiaQ2ZPGqwkyXmQgBH6r5jpYiYWzhqJ48&m=ffH268c0xOd0DSFLQzZ2JHAmCHjVzPJVJtGPNxiiJcs&s=HjVuj69fVsCLulvyNUajxCbtSKPAVkUZVJNK8s-f-Ho&e=

    > > dt/issues?q=is%3Aissue+is%3Aopen+label%3Aupdated-mod-rev-handling

    > > >     >     >

    > > >     >     >     Regards,

    > > >     >     >     Reshad.

    > > >     >     >

    > > >     >     >     On 2020-03-10, 3:31 PM, "netmod on behalf of Martin Björklund"

    > > >     >     >     <netmod-bounces@ietf.org<mailto:netmod-bounces@ietf.org> on behalf of mbj+ietf@4668.se<mailto:mbj+ietf@4668.se>> wrote:

    > > >     >     >

    > > >     >     >         Hi,

    > > >     >     >

    > > >     >     >         Here are my review comments of

    > > >     >     >         draft-verdt-netmod-yang-module-versioning-01.

    > > >     >     >

    > > >     >     >

    > > >     >     >

    > > >     >     >         o  3.1.1

    > > >     >     >

    > > >     >     >             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.

    > > >     >     >

    > > >     >     >           I think this needs to capture that no descendant statements to

    > > >     >     >           "input" can be reordered.  Same for "output" (note, "input" and

    > > >     >     >           "output" in both "rpc" and "action").

    > > >     >     >

    > > >     >     >

    > > >     >     >         o  3.3

    > > >     >     >

    > > >     >     >             All revision labels that match the pattern for the "version"

    > > >     >     >             typedef in the ietf-yang-semver YANG module MUST be

    > > interpreted as

    > > >     >     >             YANG semantic version numbers.

    > > >     >     >

    > > >     >     >           I don't think this is a good idea.  Seems like a layer violation.

    > > >     >     >           What if my project use another dialect of semver, that wouldn't

    > > be

    > > >     >     >           possible with this rule.  I think this needs to be removed.

    > > >     >     >

    > > >     >     >

    > > >     >     >         o  3.3

    > > >     >     >

    > > >     >     >             Submodules MUST NOT use revision label schemes that could

    > > be

    > > >     >     >             confused

    > > >     >     >             with the including module's revision label scheme.

    > > >     >     >

    > > >     >     >           Hmm, how do I ensure that this MUST NOT is handled correctly?

    > > What

    > > >     >     >           exactly does "could be confused with" mean?

    > > >     >     >

    > > >     >     >

    > > >     >     >         o  3.3

    > > >     >     >

    > > >     >     >               In the filename of a YANG module, where it takes the form:

    > > >     >     >               module-

    > > >     >     >               or-submodule-name ['@' revision-label] ( '.yang' / '.yin' )

    > > >     >     >

    > > >     >     >           Should this section update 5.2 of RFC 7950?  I know that 5.2 just

    > > >     >     >           says "SHOULD".  But existing tools implement this SHOULD, and

    > > they

    > > >     >     >           need to be updated to handle this new convention.

    > > >     >     >

    > > >     >     >           But I wonder if this a good idea.  It means that a tool that looks

    > > >     >     >           for a module with a certain revision date cannot simply check

    > > the

    > > >     >     >           filenames, but need to parse all available modules (wijust to

    > > find

    > > >     >     >           the

    > > >     >     >

    > > >     >     >

    > > >     >     >

    > > >     >     >         o  3.4

    > > >     >     >

    > > >     >     >              leaf imperial-temperature {

    > > >     >     >                type int64;

    > > >     >     >                units "degrees Fahrenheit";

    > > >     >     >                status deprecated {

    > > >     >     >                  rev:status-description

    > > >     >     >                    "Imperial measurements are being phased out in favor

    > > >     >     >                     of their metric equivalents.  Use metric-temperature

    > > >     >     >                     instead.";

    > > >     >     >                }

    > > >     >     >                description

    > > >     >     >                  "Temperature in degrees Fahrenheit.";

    > > >     >     >              }

    > > >     >     >

    > > >     >     >           I don't think rev:status-description is necessary / worth it.  This

    > > >     >     >           can easily be written with the normal description statement

    > > instead:

    > > >     >     >

    > > >     >     >              leaf imperial-temperature {

    > > >     >     >                type int64;

    > > >     >     >                units "degrees Fahrenheit";

    > > >     >     >                status deprecated;

    > > >     >     >                description

    > > >     >     >                    "Imperial measurements are being phased out in favor

    > > >     >     >                     of their metric equivalents.  Use metric-temperature

    > > >     >     >                     instead.

    > > >     >     >

    > > >     >     >                     Temperature in degrees Fahrenheit.";

    > > >     >     >              }

    > > >     >     >

    > > >     >     >

    > > >     >     >         o  3.5

    > > >     >     >

    > > >     >     >           The example modules should be legal YANG modules.  Use e.g.

    > > >     >     >           "urn:example:module" as namespace.

    > > >     >     >

    > > >     >     >           Also, the modules are missing the last "}", which confuses the

    > > >     >     >           "rfcstrip" tool.

    > > >     >     >

    > > >     >     >

    > > >     >     >         o 4.1.1

    > > >     >     >

    > > >     >     >             Alternatively, the first example could have used the revision

    > > >     >     >             label

    > > >     >     >             "1.0.0" instead, which selects the same set of

    > > revisions/versions.

    > > >     >     >

    > > >     >     >             import example-module {

    > > >     >     >               rev:revision-or-derived 1.0.0;

    > > >     >     >             }

    > > >     >     >

    > > >     >     >           Shouldn't this be s/1.0.0/2.0.0/g ?

    > > >     >     >

    > > >     >     >

    > > >     >     >         o  5

    > > >     >     >

    > > >     >     >           I think the module name "ietf-yl-revisions" should be changed

    > > to

    > > >     >     >           "ietf-yang-library-revisions".   "yl" is not a well-known acronym.

    > > >     >     >

    > > >     >     >

    > > >     >     >         o  5.2.2

    > > >     >     >

    > > >     >     >           Wouldn't it be better if the leaf "deprecated-nodes-

    > > implemented" and

    > > >     >     >           "obsolete-nodes-absent" were of type "boolean" rather than

    > > type

    > > >     >     >           "empty"?

    > > >     >     >

    > > >     >     >

    > > >     >     >         o  7.1

    > > >     >     >

    > > >     >     >           The text says:

    > > >     >     >

    > > >     >     >             All IETF YANG modules MUST include revision-label statements

    > > for

    > > >     >     >             all

    > > >     >     >             newly published YANG modules, and all newly published

    > > revisions of

    > > >     >     >             existing YANG modules.  The revision-label MUST take the form

    > > of a

    > > >     >     >             YANG semantic version number [I-D.verdt-netmod-yang-

    > > semver].

    > > >     >     >

    > > >     >     >           I strongly disagree with this new rule.  IETF modules use a linear

    > > >     >     >           history, so there are no reasons to use "modified semver".

    > > >     >     >

    > > >     >     >           It is ok to use rev:nbc-changes if needed, though.

    > > >     >     >

    > > >     >     >

    > > >     >     >         o 7.1.1

    > > >     >     >

    > > >     >     >           There is a missing " in:

    > > >     >     >

    > > >     >     >            4.  For status "obsolete", it is RECOMMENDED to keep the

    > > "status-

    > > >     >     >                description" information, from when the node had status

    > > >     >     >                "deprecated, which is still relevant.

    > > >     >     >          HERE  -----------^

    > > >     >     >

    > > >     >     >

    > > >     >     >         o  8

    > > >     >     >

    > > >     >     >           s/CODE ENDS>/<CODE ENDS>/

    > > >     >     >

    > > >     >     >

    > > >     >     >         o Both YANG modules

    > > >     >     >

    > > >     >     >           All extensions should specify the grammar; i.e., in which

    > > statements

    > > >     >     >           they can be present and which substatements they can have.

    > > >     >     >

    > > >     >     >

    > > >     >     >

    > > >     >     >         /martin

    > > >     >     >

    > > >     >     >         _______________________________________________

    > > >     >     >         netmod mailing list

    > > >     >     >         netmod@ietf.org<mailto:netmod@ietf.org>

    > > >     >     >         https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=p8kyeK3u4ZYiaQ2ZPGqwkyXmQgBH6r5jpYiYWzhqJ48&m=ffH268c0xOd0DSFLQzZ2JHAmCHjVzPJVJtGPNxiiJcs&s=z5LiDOlko48vuqlIgA0Gm7dcsxmHOtwfod6wC46lRU0&e=

    > > >     >     >

    > > >     >     >

    > > >     >     >     _______________________________________________

    > > >     >     >     netmod mailing list

    > > >     >     >     netmod@ietf.org<mailto:netmod@ietf.org>

    > > >     >     >     https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=p8kyeK3u4ZYiaQ2ZPGqwkyXmQgBH6r5jpYiYWzhqJ48&m=ffH268c0xOd0DSFLQzZ2JHAmCHjVzPJVJtGPNxiiJcs&s=z5LiDOlko48vuqlIgA0Gm7dcsxmHOtwfod6wC46lRU0&e=

    > > >     >     >

    > > >     >     >

    > > >     >

    > > >     >

    > > >

    > > >

    > > _______________________________________________

    > > netmod mailing list

    > > netmod@ietf.org<mailto:netmod@ietf.org>

    > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=p8kyeK3u4ZYiaQ2ZPGqwkyXmQgBH6r5jpYiYWzhqJ48&m=ffH268c0xOd0DSFLQzZ2JHAmCHjVzPJVJtGPNxiiJcs&s=z5LiDOlko48vuqlIgA0Gm7dcsxmHOtwfod6wC46lRU0&e=





_______________________________________________

netmod mailing list

netmod@ietf.org<mailto:netmod@ietf.org>

https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=p8kyeK3u4ZYiaQ2ZPGqwkyXmQgBH6r5jpYiYWzhqJ48&m=ffH268c0xOd0DSFLQzZ2JHAmCHjVzPJVJtGPNxiiJcs&s=z5LiDOlko48vuqlIgA0Gm7dcsxmHOtwfod6wC46lRU0&e=