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

"Reshad Rahman (rrahman)" <rrahman@cisco.com> Mon, 30 March 2020 20:18 UTC

Return-Path: <rrahman@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 B68FA3A106B for <netmod@ietfa.amsl.com>; Mon, 30 Mar 2020 13:18:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.698
X-Spam-Level:
X-Spam-Status: No, score=-7.698 tagged_above=-999 required=5 tests=[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=PFeZChE0; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=hG0DPAFx
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 C8ifCg0pkZ6z for <netmod@ietfa.amsl.com>; Mon, 30 Mar 2020 13:18:37 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9524E3A1062 for <netmod@ietf.org>; Mon, 30 Mar 2020 13:18:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16134; q=dns/txt; s=iport; t=1585599517; x=1586809117; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=jnBZnxUFH93PaLiFlCIJ2qk9541LEQ2wGAYUfDfi0aU=; b=PFeZChE0l6mA+V7BCUUn204IKVBhli2M4jEHrxzFaTl2Bb0jL0g+chum MWoeIQo3rKD6m6HVVS9BiNYVEz+UenDPPMDv4jyxqhD8DjrtfmxfkM9w6 Tq26yh4PS7gtA1odlUQlvJZVw41vl3QvdXrsTdMo/VN/0/GO2SMJDmqMC I=;
IronPort-PHdr: =?us-ascii?q?9a23=3AcwA+UBfn5OYDhSJCJSol5AOvlGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwGRD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFn?= =?us-ascii?q?pnwd4TgxRmBceEDUPhK/u/dTYzHMFLUndu/mqwNg5eH8OtL1A=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DdAQCDU4Je/4ENJK1mGwEBAQEBAQE?= =?us-ascii?q?FAQEBEQEBAwMBAQGBe4FUUAVsWCAECyoKhBCDRQOKbIJfmB+BQoEQA1QKAQE?= =?us-ascii?q?BDAEBGA0IAgQBAYN/RQIXghskOBMCAwEBCwEBBQEBAQIBBQRthVYMhXABAQE?= =?us-ascii?q?BAgEBARAREQwBASwLAQ8CAQgYAgImAgICJQsVEAIEDgUigwQBgksDDiABDqJ?= =?us-ascii?q?1AoE5iGJ1gTKCfwEBBYJFgkIYggwDBoEOKowxGoFBP4ERJyCCHy4+gmcBAQI?= =?us-ascii?q?agS8aFyECglgygiyNfwEDgneGHplRCoI8h2GPNB2CTJRJhFeQaodFkm0CBAI?= =?us-ascii?q?EBQIOAQEFgWkigVhwFTsqAYJBUBgNjh2Dc4UUhUF0AhCBF40OAYEPAQE?=
X-IronPort-AV: E=Sophos;i="5.72,325,1580774400"; d="scan'208";a="496641387"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Mar 2020 20:18:35 +0000
Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 02UKIZdH013619 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 30 Mar 2020 20:18:35 GMT
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 30 Mar 2020 15:18:35 -0500
Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 30 Mar 2020 16:18:34 -0400
Received: from NAM12-MW2-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.1497.2 via Frontend Transport; Mon, 30 Mar 2020 15:18:34 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NAF0jYWtiP4TLLedKJ0bso1GPp2mK5UKiqtqsUbh4r+0h8zD/3XLTtYGUHlQWm2V9CEDdhtuzOFvgx1oHu8Tu7f4N54bF2QNyrIbt43dn9bMp2J2azTJJ97YB45Yx9DxcUh0znMAsiFg9E2t/eW3H8RlDqLkxmLVohVR2LFgdyltGa503LvL8ePspbeM5qUmV7XptdqkZxJqFSKpVvXZr4UgUPNRlREruYW3iCiEdw6GejqNsx5FF+bpqLWcMGplYqf4e1nXgUCgDXnL/MdtAJpwgn/pI1TeK0x6mUkAhW8horZZTAYp36mlUYCC9DkkWSWyett8Nl9rrnn8GUGIRQ==
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=jnBZnxUFH93PaLiFlCIJ2qk9541LEQ2wGAYUfDfi0aU=; b=aRj428pq2G3GStqxMLrHTd8M+qc82zaoyeZcQfGJr64rnx8mkblP21eYteuqVv6ehORd/cgnGfwa1GCX7h2rQUJAiuJJNqgJrsaJYeqpkD2rvGEfY4Gpin8udgOTdGgVktb+2hwmNr7cQ3e4qloilVzrSok1X029HjYGJbUwzrXyn4/+BKvvFIicoj0xBj+qkWokNVc9vi6s2l684il0eXQfrhENyGP/dK7hHXkz745dggM+Da6cmj2JJlHVuezKViYlCsEFKvs9nCPkqPQr4B1SUZ+olPIo8B+HPUv2AurMFInltve/yfQYzjf0ZWGIsv8i0nK/cTTqSOPbVGCPrQ==
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=jnBZnxUFH93PaLiFlCIJ2qk9541LEQ2wGAYUfDfi0aU=; b=hG0DPAFxR1ZABOtuAOLxUdsl3s0m+UAVvnZcYIq8+23zSd0pdA2ClhQd54P3t4VTQex+ggnkvCmelTzTarlm8igulJ3SwuhGBdbARLk5z5wbm3Y51yYB4c7/Nft3uGA4GFvE/Kb/NEqsITDM+9FCEg9Xa4gbalX/DVK0TiANjJs=
Received: from DM6PR11MB3420.namprd11.prod.outlook.com (2603:10b6:5:69::31) by DM6PR11MB4026.namprd11.prod.outlook.com (2603:10b6:5:198::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.19; Mon, 30 Mar 2020 20:18:33 +0000
Received: from DM6PR11MB3420.namprd11.prod.outlook.com ([fe80::91cb:6555:db9b:53fa]) by DM6PR11MB3420.namprd11.prod.outlook.com ([fe80::91cb:6555:db9b:53fa%7]) with mapi id 15.20.2856.019; Mon, 30 Mar 2020 20:18:33 +0000
From: "Reshad Rahman (rrahman)" <rrahman@cisco.com>
To: =?utf-8?B?TWFydGluIEJqw7Zya2x1bmQ=?= <mbj+ietf@4668.se>
CC: "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: All IETF YANG modules MUST include revision-label statements
Thread-Index: AQHWBNyukTO5JXWurk2ljZZiFHPveKhhLBqAgABJ5QD//934AA==
Date: Mon, 30 Mar 2020 20:18:33 +0000
Message-ID: <047FB87D-37B2-41F4-86D2-B9A03050B4EB@cisco.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>
In-Reply-To: <20200330.202016.930329343788112268.id@4668.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.21.0.200113
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rrahman@cisco.com;
x-originating-ip: [70.31.50.95]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: a644290c-dd98-4464-884d-08d7d4e78514
x-ms-traffictypediagnostic: DM6PR11MB4026:
x-microsoft-antispam-prvs: <DM6PR11MB4026DBB5C6873735D7A2DCB5ABCB0@DM6PR11MB4026.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:6430;
x-forefront-prvs: 0358535363
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB3420.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(346002)(396003)(376002)(366004)(39860400002)(136003)(8676002)(2616005)(81156014)(8936002)(186003)(316002)(81166006)(26005)(66574012)(6486002)(478600001)(36756003)(86362001)(4326008)(53546011)(71200400001)(66946007)(91956017)(66556008)(64756008)(66446008)(2906002)(6506007)(66476007)(5660300002)(966005)(6512007)(33656002)(76116006); 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: izXcQria9yiTVP99r96sHW8llkEt1FKDYd9HrXG8Et0wYd1QLzakt7x24PZUw/7hDbW3oNVj4yIZtwr1vAGDEkqZ+hPKQdDH+hAZZX2JaG+N3h03IoQwoXFAG7mNu+2xb+6G2tA7g/N5j0GMzCIVk8Jd0lBU4ImSO3d6JqL0TC/HQLEquSgP2Z6act261QohSGtkVdiZS3wBHkl3SAd4nlvCLDQQxhwhT8dNbsMVxxGl5d0JZawWa6HV51BIFslMDbd42YMu9mxqzbyxIRqEyOX1xViyYT8Y2Wu9tAncteE8th62wRPD7e3N+gb5/vdbNFB++aG78B6zXtBOB7jSALqTspDMIL4KI30bZUAnm/rww0PANqFsX4p7zhymm/M5Ie5BaezIxRpKTc2cZ0sWycTGGykudyd2E3HfT7yH3TFp2S4xOpAk+spgGWReVB4IXdOGpW3T/KxcEjA9zRvCaGQ93SzWVtEyn0B8xHJJh04aJQ2Hd/3rqr2S6oNyBNa65B+cktZ1Lx8BGeR9/6mBAw==
x-ms-exchange-antispam-messagedata: N5W5uAff7FIYkr5NNzIoijVScJ1Ucrets/JVu/faPmYux8GYegPqShVD0xlQnuDI0ss9FRaJ74s4KyoUUjFc03bw3nFYKmTIyPd6YEOQ60+vIjRBoclZ7zcmn7oALbfqnaLF6DgiLfkc5jEduderww==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <3E9CFDA2084C71408649E3DE5D7E7A81@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: a644290c-dd98-4464-884d-08d7d4e78514
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Mar 2020 20:18:33.0484 (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: 1MZz+hHXQvyRShuLELYC3RpHDxaeYlGzXqw0KtYWhC8EoVK9ehxa/ewRdltDGi78CULWhaLPnqpw1I5iIGsasQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4026
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com
X-Outbound-Node: alln-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/OakQeUhSsX6m3zGXSCbCIUYIou4>
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: Mon, 30 Mar 2020 20:18:40 -0000

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

    "Reshad Rahman (rrahman)" <rrahman@cisco.com> wrote:
    > On 2020-03-28, 4:41 AM, "Martin Björklund" <mbj+ietf@4668.se> wrote:
    > 
    >     "Reshad Rahman (rrahman)" <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.

The revision label allows a user to easily figure out whether 2 revisions are (N)BC. 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 on behalf of
    >     > 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://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 on behalf of 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
    >     >         https://www.ietf.org/mailman/listinfo/netmod
    >     >         
    >     >     
    >     >     _______________________________________________
    >     >     netmod mailing list
    >     >     netmod@ietf.org
    >     >     https://www.ietf.org/mailman/listinfo/netmod
    >     >     
    >     > 
    >     
    >