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

"Rob Wilton (rwilton)" <rwilton@cisco.com> Tue, 31 March 2020 12:09 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 019EF3A193C for <netmod@ietfa.amsl.com>; Tue, 31 Mar 2020 05:09:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.697
X-Spam-Level:
X-Spam-Status: No, score=-7.697 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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=OLzcoIxD; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=09XmLzyX
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 tl2KBMLlaLAw for <netmod@ietfa.amsl.com>; Tue, 31 Mar 2020 05:09:19 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F4043A193B for <netmod@ietf.org>; Tue, 31 Mar 2020 05:09:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=62610; q=dns/txt; s=iport; t=1585656559; x=1586866159; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=24JKVnJo9KJ9pthIEuRAzo725YLOZ1kyDDOlU6gzZbw=; b=OLzcoIxDqjtyf5qVKjg9jkt9OIYBsGnnn5xcoA7Tp15n1opTJvhiVoYx nhUes1AoHr0qmnN++oGVXUnohMrAmBChHOIsm2qqXe5CkQX7cBOPO1hvl v6zoIWcoVNJtT/zfDwMzmKjnALOdhZ4gTy5UfF5u7xrC93LPJKPNr0NYv w=;
IronPort-PHdr: =?us-ascii?q?9a23=3AkK86SBbvnMcmwGLuGTr6UpL/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20gebRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn?= =?us-ascii?q?1NksAKh0olCc+BB1f8KavwcC0+AMNEfFRk5Hq8d0NSHZW2ag=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DfAADxMYNe/5pdJa1mGgEBAQEBAQE?= =?us-ascii?q?BAQMBAQEBEQEBAQICAQEBAYF7gSUvUAVsWCAECyoKhBCDRQOKaoJfmB2BQoE?= =?us-ascii?q?QA1AECgEBAQwBARgBDAgCBAEBg39FAheCHSQ4EwIDAQELAQEFAQEBAgEFBG2?= =?us-ascii?q?FVgyFcAEBAQECAQEBEBEKEwEBLAsBDwIBCBEEAQEBIAEGAwICAiULFAkIAgQ?= =?us-ascii?q?BDQUIEQIHgwWBfk0DDiABAwuiUwKBOYhidYEygn8BAQWFFhiCDAMGgTiMMRq?= =?us-ascii?q?BQT+BEUeBT1AuPoJnAQECGoEvHAwJFgkCgloygiyOAgEDgniFfCSKBI9PCoI?= =?us-ascii?q?9h2GPU4JMlEuEV48bgVGHR5JtAgQCBAUCDgEBBYFpIoFYcBU7gmxQGA2OHQw?= =?us-ascii?q?Xg1CFFIVBdAIQgReMVAGBDwEB?=
X-IronPort-AV: E=Sophos;i="5.72,327,1580774400"; d="scan'208,217";a="739417764"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 31 Mar 2020 12:09:17 +0000
Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 02VC9HOk016664 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 31 Mar 2020 12:09:17 GMT
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 31 Mar 2020 07:09:17 -0500
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 31 Mar 2020 07:09:16 -0500
Received: from NAM11-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 31 Mar 2020 08:09:16 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FvmtydVDvomX2Rk25ymBOvad+4pE/5wffUX3fkrq38dSExZH0ErqtQt9SWQf07dO6N7zLQYB3DoVeujkbohlYrReoAcTUEppSEHNPOBhBQMlXZtcVSdu+NYQllGpYb2/o9vQiQw8gRIfymkI7eiZeWD5SO2LBJwMir/WBeyZZSyOOxrCioFrS2MiEGq/wmDAdw/PhT4tkzcidBXsXxj9g9emEgPGvCoRpuq0EJPs5i6pxN2EJpDlmuZgPlAvd/Bj4pBSDEUwtl0bzKkXQQz1d+jAH5GpZwbhewkMrDPaFkZNJ1r9aygep6xxa3VaENStb/uWCuBTMBAfaBYRgrENcg==
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=24JKVnJo9KJ9pthIEuRAzo725YLOZ1kyDDOlU6gzZbw=; b=XJcKgzbp00CgsWDpVtkOG1lv/cxNxvKG9RqLAy0SJ3X1DAhIMBA8r/dZWXKiAQX1hYlO4ptSo7l9UZbzuFt/Km4c/MLZmal2bBxhh0PBQ/nZt6stAX6Kqf37/J5l/tlUCNfruTmH0tQglfqRHkFZ/xhx0P43LFFWN6a6OmWaVURk3Bbv6QDVSdh1i/jM51DWqLZHxixkayhK0OkBbHRE41T/CqETTE87jChgeyYqFkc1b6zUhAjRJJPgqrDYgu5mwAm6e/TQ+LkButYPdjuC570Fx7ETEJPHdj4cvTZJewSQ5BGxnkSGs2uw4C2ybeueKTABHgCM5A8/t7fJ5lBDSw==
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=24JKVnJo9KJ9pthIEuRAzo725YLOZ1kyDDOlU6gzZbw=; b=09XmLzyXw0gNF/ZQbTCQMd2HLWi6n3wsryaBRsyw9D3nxTJOiLdF+uuRMSijGSBA+xDh5yFz+zilBhLaGehpC8qnEsaCAx4Pdm6mI7cnTCXAr+w4+UW+bEBHDlvoimusooTzyDb63Fh3+MXOpI1E9pvGFmHl3L7tQTDIN+kMW2I=
Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by MN2PR11MB4287.namprd11.prod.outlook.com (2603:10b6:208:189::17) 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 12:09:14 +0000
Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::3:2164:a8e2:33b3]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::3:2164:a8e2:33b3%5]) with mapi id 15.20.2856.019; Tue, 31 Mar 2020 12:09:14 +0000
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: Andy Bierman <andy@yumaworks.com>, =?utf-8?B?TWFydGluIEJqw7Zya2x1bmQ=?= <mbj+ietf@4668.se>
CC: NetMod WG <netmod@ietf.org>
Thread-Topic: [netmod] All IETF YANG modules MUST include revision-label statements
Thread-Index: AQHWBryXXEWOVM1ZWkW+qvBAGEwM/Khhcj8AgAAIq4CAARsOMA==
Date: Tue, 31 Mar 2020 12:09:14 +0000
Message-ID: <MN2PR11MB4366775C8E9A5488D33E484EB5C80@MN2PR11MB4366.namprd11.prod.outlook.com>
References: <75CFDBD9-143C-407A-B7C3-26CEC51E229C@cisco.com> <20200328.094121.1160081114435152145.id@4668.se> <76623C79-BB91-4B5F-8FEA-406ADEAD1647@cisco.com> <20200330.202016.930329343788112268.id@4668.se> <CABCOCHS=y8d00xHLzV+LNpvN_=jScw5VizGYWXGopsQAi8qZUw@mail.gmail.com>
In-Reply-To: <CABCOCHS=y8d00xHLzV+LNpvN_=jScw5VizGYWXGopsQAi8qZUw@mail.gmail.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=rwilton@cisco.com;
x-originating-ip: [82.15.79.32]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f3ec535c-8df9-4fd9-8f5d-08d7d56c549c
x-ms-traffictypediagnostic: MN2PR11MB4287:
x-microsoft-antispam-prvs: <MN2PR11MB4287D0DC8FCB7BCB9C700B2FB5C80@MN2PR11MB4287.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-forefront-prvs: 0359162B6D
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; SFTY:; SFS:(10009020)(4636009)(39860400002)(376002)(346002)(366004)(136003)(396003)(478600001)(8676002)(81166006)(966005)(7696005)(81156014)(6506007)(53546011)(9686003)(71200400001)(66574012)(4326008)(86362001)(5660300002)(52536014)(66446008)(66556008)(64756008)(66946007)(55016002)(76116006)(66476007)(186003)(110136005)(2906002)(33656002)(26005)(316002)(8936002); DIR:OUT; SFP:1101;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: MRS7grOcPB9s2TELQuXXpPe+loyvGtW2YAnp7y5/mxOuZhBTVwxa4pLDRt+eQG15VzX0t1keBj9784vUOgpFqYrXh+DgYkYillvJuK4vYxJLTCUyyAwcOJpS2LcGBElEIu3dVApIFnUL+ze/0HSSCW5S6nc6i92NTej+LWUiuoPPLeW8AgbMml4O1I/xNFt7mQHgrf1TmC1wS8OPvuzTzfWrnVXvj4jKeiQKr28VsLgIDUEjDV83sfEpCFtDVR5JKavelqzX4p3pQE7dOB1mEo+gOHijOdc6nRHfBFHLs+8GJrvVHa2gpS2uYefdav9aaM6M4SyyxM5ECYTIbz5BpWNeuAiKD1dBDExLbHf9CCpgFAcwN10psKyc8933TplqN9g5ESyNrquphOBjGl1AikjcZ3CL56rK0SVudPekwIDoH0Sx6CJozWP82W55VycPYhtMhPS5FgkFlT4K+plb9yrxA3KNzTCS44f1WGyN388qBsn3pHJ4QD/foA19JO6/2LF81vKxaOsVbeMKssWU9w==
x-ms-exchange-antispam-messagedata: HBkOMxn0hn4j8gem7XVXjvbEpehmLsmKt7qi9WzoGhMfJy7vRdbX1oKVHe72tJzmX+2+0V0VlUw614Z6umlFVjmqYMxpOAtlVmZy194xU2733mCNFlct4akV/3ea4gM6ojZvWvVyxIPabjqcBFP9BQ==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MN2PR11MB4366775C8E9A5488D33E484EB5C80MN2PR11MB4366namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: f3ec535c-8df9-4fd9-8f5d-08d7d56c549c
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Mar 2020 12:09:14.8145 (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: 8tHEO9rBWddUARJy1stj4jlW/EDX1EUXC52OxXQAEGDCUBjWHf+bMPJ6K5qB6O81PJ8RK1QivitcJX3FRbQNcQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4287
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com
X-Outbound-Node: rcdn-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/XBbevH8RFdoPfgFDr0HkpqMR9GU>
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 12:09:22 -0000

[As an individual contributor]

My impression is that Semver 2.0.0 works fine if you can always force clients to move to the latest version of the API whenever any bugfixes are made to the API (whether they are BC or NBC).  This is a natural fit for open source projects, but not so great for long life paid support contracts.

The goal of YANG semver is not to facilitate release branching.  It is to allow vendors to fix YANG modules without forcing clients to update to the latest version of that YANG module (which may contain other unrelated NBC changes and have lots of dependencies on other modules).

Note that OpenConfig also hit this problem, but they proposed a different solution.  I.e. ship the base module with another module that contains deviations to fix any bugs in the base module.  Alas this completely decouples the real module history from any revision-date/version number contained in the module, since to really understand the version of the module you also need to know the set of associated patch modules containing any deviations to the base module.

Regards,
Rob


From: netmod <netmod-bounces@ietf.org> On Behalf Of Andy Bierman
Sent: 30 March 2020 19:51
To: Martin Björklund <mbj+ietf@4668.se>
Cc: NetMod WG <netmod@ietf.org>
Subject: Re: [netmod] All IETF YANG modules MUST include revision-label statements



On Mon, Mar 30, 2020 at 11:20 AM Martin Björklund <mbj+ietf@4668.se<mailto:mbj%2Bietf@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%2Bietf@4668.se>> wrote:
>
>     "Reshad Rahman (rrahman)" <rrahman@cisco.com<mailto:rrahman@cisco.com>> wrote:
>     > Hi,
>     >
>     > https://github.com/netmod-wg/yang-ver-dt/issues/45
>     >
>     >         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.

I do not like modified semver because it will cause confusion with the real semver
introduced by OpenConfig.

Sometimes multiple release trains are needed, and the revision label (in addition to revision-date)
can help distinguish revisions from each release train, so plain semver that is introduced over time
would be OK.

It is possible to introduce only BC changes on each release train.
The BC vs. NBC issue has nothing to do with multiple release trains.



I am all for using rev:nbc-changes or rev:editorial-changes (which I
think should be added) in IETF modules.

I agree that this is sufficient and modified semver provides no added value, only confusion.


/martin


Andy


>
> 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: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://github.com/netmod-wg/yang-ver-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%2Bietf@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://www.ietf.org/mailman/listinfo/netmod
>     >
>     >
>     >     _______________________________________________
>     >     netmod mailing list
>     >     netmod@ietf.org<mailto:netmod@ietf.org>
>     >     https://www.ietf.org/mailman/listinfo/netmod
>     >
>     >
>
>
_______________________________________________
netmod mailing list
netmod@ietf.org<mailto:netmod@ietf.org>
https://www.ietf.org/mailman/listinfo/netmod