Re: [netmod] Revision labels for submodules

"Reshad Rahman (rrahman)" <rrahman@cisco.com> Fri, 08 May 2020 22:24 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 217C33A0FE6 for <netmod@ietfa.amsl.com>; Fri, 8 May 2020 15:24:45 -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_H4=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=a1NmcJPX; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=g+9MUbSS
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 ZnlPCXoGV8jf for <netmod@ietfa.amsl.com>; Fri, 8 May 2020 15:24:43 -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 F34913A0FE1 for <netmod@ietf.org>; Fri, 8 May 2020 15:24:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16730; q=dns/txt; s=iport; t=1588976682; x=1590186282; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=+9dX1H9FLB+snBWEU0sATaIRYGkYKI+SxDJZXhjFO64=; b=a1NmcJPXMNtF48cHG6CgmOGJ2n3rmWnQarJrbbomXTp6fyZD4bwqjeyh VNWanG3V7ykoU455E2s+S56X5r8OF6K/FYhuJZtxASq9J2LL+He4l7AsT T1I/aXC0cEBULlE1ba7heLcMcJ7bs8BAtTUt94l7sRmfer1J5r36cu+3M s=;
IronPort-PHdr: 9a23:8f1AJBbhKx1REF7LtD9XyMX/LSx94ef9IxIV55w7irlHbqWk+dH4MVfC4el21QaRD9mFtaICkOeF+6zjWGlV55GHvThCdZFXTBYKhI0QmBBoG8+KD0D3bZuIJyw3FchPThlpqne8N0UGRJigNxvJry764TsbAB6qMw1zK6z8EZLTiMLi0ee09tXTbgxEiSD7b6l1KUC9rB7asY8dho4xJw==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CZBQC427Ve/5ldJa1mHAEBAQEBAQcBARIBAQQEAQFAgUeBVFEFb1gvLAqEGoNGA41DmDiBQoEQA1QLAQEBDAEBGA0IAgQBAYN/RQIXgXckOBMCAwEBCwEBBQEBAQIBBQRthVYMhXEBAQEBAgEBARAREQwBASwLAQ8CAQgYAgImAgICJQsVEAIEDgUigwQBgksDDiABDqQvAoE5iGF2gTKDAQEBBYJJgm0Ygg4DBoEOKoJjiWEagUE/gREnHIJNPoJnAQECGoEvMSECglozgi2ORgEDMIJYhkKaWwqCSogbkA0dglyVaoR0kXWIApNQAgQCBAUCDgEBBYFpIimBLXAVOyoBgj5QGA2QQINyhRSFQnQCECUCBgEHAQEDCXyMOgGBDwEB
X-IronPort-AV: E=Sophos;i="5.73,369,1583193600"; d="scan'208";a="503095580"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 May 2020 22:24:41 +0000
Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 048MOfI3016236 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 May 2020 22:24:41 GMT
Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 8 May 2020 17:24:41 -0500
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 8 May 2020 17:24:40 -0500
Received: from NAM10-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 8 May 2020 17:24:40 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Q2bl4IAV5UFjaQMdTS/oftA33OKsC6N4LRmFwZgWuSdkuR3/gxmGpJKy3ScxX8ahop3RXkcj0Rg00CvoXaem0Wjwxw/0A5hBV6czWmisMOBGYYbWNBbg40IFzyKP+6GVlLTjd3DZ+vhW22rnFB3qF004KnKI/6fJqj98CMR0AXgknm1uH+YYUcyyxMXVztb2mcxqIG6xQRHcI0B65aEfPmlcl6WXc+y+/zFVXKAIUMgglkS7yBv0eErNEu/2Vn3NtOXC9Z614e257t7lh9PCjtJgIcXPW5ANvOj5s7Agsuhj6Mn6qqrFdcI/CKLcOd5qxxUonFTfbjb6DnYdEKi2lQ==
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=+9dX1H9FLB+snBWEU0sATaIRYGkYKI+SxDJZXhjFO64=; b=A8L+D++xh9rwW1f7aiSzkZuvg0HZl9Bij70HS9asmeQAWROCrE3WqPMiTe8+QmouYMTvXGuJkM5Y+ZoC4raEEfNnC9gXkTjq7iwVsv/+vNjVJ7AW5xEAW0uYYCSzf1nYxSu/sS2GIM/DYxMUOrfC4cKCs0OLFqI5FNfoL4yF4oEhxmhFHjuJlkQ4XyOI3oVsXMNBH8mISHBjmek8yRoF6kiax1w37vP6Qnp9QmhmwRl2TNoyT9nGec6ZIrcAAnr3NFiHm+BRygIID2E6GL+AUG09ywgv4SkGjKLJO0wqbxXcxhEKY0LXpER1JX7TXMOFiDp+GcWnUZi4YVBnH10KQA==
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=+9dX1H9FLB+snBWEU0sATaIRYGkYKI+SxDJZXhjFO64=; b=g+9MUbSStWM9pWmrA7pTK0Krpz4O9bDuowExGOGX6oLEmFZYTfay3TgtZsonMnIYLL/5tebS9vgRwU3TK0SU5/FmMAadSPfOYnNuvMvcLg9qJUA4EGlz9VbI5/qPf3BtrETPPtAa3OAIXApZivkzcAMfB5Q0wLHE8yqATwobC2E=
Received: from BN6PR11MB3875.namprd11.prod.outlook.com (2603:10b6:405:80::37) by BN6PR11MB1748.namprd11.prod.outlook.com (2603:10b6:404:101::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.20; Fri, 8 May 2020 22:24:38 +0000
Received: from BN6PR11MB3875.namprd11.prod.outlook.com ([fe80::89ae:b7c9:b936:b2bd]) by BN6PR11MB3875.namprd11.prod.outlook.com ([fe80::89ae:b7c9:b936:b2bd%3]) with mapi id 15.20.2979.033; Fri, 8 May 2020 22:24:38 +0000
From: "Reshad Rahman (rrahman)" <rrahman@cisco.com>
To: Martin Björklund <mbj+ietf@4668.se>
CC: "netmod@ietf.org" <netmod@ietf.org>, "jason.sterne@nokia.com" <jason.sterne@nokia.com>
Thread-Topic: [netmod] Revision labels for submodules
Thread-Index: AQHWJT+MiAxw1tFb+k6vD0etivad/KiesDOA///RIoA=
Date: Fri, 08 May 2020 22:24:37 +0000
Message-ID: <B692BC98-AA66-4E12-9EF5-516FFCF04F33@cisco.com>
References: <8D4A99E4-93D3-495C-9B46-26C61BBABAA7@cisco.com> <20200508.231215.893859438588129498.id@4668.se>
In-Reply-To: <20200508.231215.893859438588129498.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: 4668.se; dkim=none (message not signed) header.d=none;4668.se; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [70.31.50.95]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 60e1451b-d058-4023-5e27-08d7f39e983e
x-ms-traffictypediagnostic: BN6PR11MB1748:
x-microsoft-antispam-prvs: <BN6PR11MB174893F30082D29AB4DE5E4BABA20@BN6PR11MB1748.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 039735BC4E
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: TY93HOLeS4yoSlqFik64/UmOn3uULyPLKkpiCQHBsWijZ9mnMwzblmnymYNJr4GhS4ZCSh2sWyoX49FAIiATGf4CWZIhS+w7INonBtNdQlufRDDMme221vyzCZ5YtaMsAfKwcmDA7xdh5veWP43ZR8JscZrw40b+CqkEG8Hm1uaxbZRJIeh51bO/RPrKwdvXfnyEl8Km2uwmfcRAzenQAa09PU0+mGssE5RkanehxAnPRd9+q+jn7JAK+cupDyb3wZo9NJ+5CZrdVYd6js4I1K7YojbZPDRCFPcsSaU/vAIoloIzL3Q37l7lGcwwp0Uo+AKcOG9SbvDAQvJLpsnSBNQDXgEfXhso1vuD2ygz6iUupoZpEwQJZpcWZwnY6y1MZvDN4p6FgqA031zRlkC9+jhQXKLXlK3fISYujlPHB5J5WsmPazLONoE/rSRyjDfZ4qGydLUpGmW3rBcaptu0b+26P9qkT6hoUoZmYL+HwBQ0+wU+bdnDSgvZMxTKM2s0fLvOhLlLIOjN8k1CM/rpZoVhTUzHz5R5bH234ldJDzQ7GHD8pTT5pzVWbjkA5UFRNulnHiirBibMK5cFzr+S9nynfkb1LAhzEZLIwULvKd4=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN6PR11MB3875.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(39860400002)(366004)(346002)(396003)(376002)(33430700001)(8936002)(33656002)(66574014)(966005)(316002)(6506007)(53546011)(6486002)(33440700001)(478600001)(86362001)(2616005)(76116006)(66446008)(64756008)(4326008)(66476007)(54906003)(66556008)(8676002)(5660300002)(91956017)(36756003)(2906002)(186003)(26005)(66946007)(71200400001)(6512007); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: /Hj+4HT+PSRNWoHQ2LCh/Aa4OaMdp8kFVTYUxkw3wVPaQ+0fsCExEQQ8+4LdbDHMkNL/sf2Qih8w9hJYLJpZo4EIzrlULluif9H5xusLSvSbSBgJqFxsxGYVf6tMrNt2uROzTHSyv4i/0MxSXM0PPlogMa0eOQvU5SUPPUzUDsWBu8iDA2wKJ7x+3Yx4Ixq4tZ3rAS1p6ljbF5M0kTqv7BHWXoqgV/bF5MOSlxx707puEAcrVADXxlCN/ihG3iJZbSiM491nLQY2YVH5X/+HoLBk0rSr2Hh4uW57E2Br0Nbge1Bm3oGwMuAGkW0yuIYYy81EZzLto8TWd5O1+O69qvsLZ91W48mk40rtOtTxONyTKKALtU78HjP5cKPAbd6hSZJuXWwBbQ+v4TBkbDjSLJb6uRULuh0+g1nVmpGdrZEIjKyGCUaVFG+gDP2mId8EWvPkfCog42wKzhJcPsClxh3sNtUv+lQPRvMkPoEh7k4=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <BD7C68BE69B9FF4D82B33BDC0635BF26@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 60e1451b-d058-4023-5e27-08d7f39e983e
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 May 2020 22:24:37.8472 (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: i4vWw9yd/BH+lxdrIfFvcsgfQ9wq/WlVkYe2+KUduxeLtnk/qp8DCP0+2Vv6WHIi7FpGtXk3xfqJ8KKIUJAQJw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB1748
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com
X-Outbound-Node: rcdn-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/GceBas7h1Ac3uy-VpTCiWb9HcUc>
Subject: Re: [netmod] Revision labels for submodules
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: Fri, 08 May 2020 22:24:45 -0000

Hi,

On 2020-05-08, 5:12 PM, "Martin Björklund" <mbj+ietf@4668.se> wrote:

    Hi,
    
    "Reshad Rahman (rrahman)" <rrahman@cisco.com> wrote:
    > Hi,
    > 
    > This came up during this week's meeting. We briefly discussed whether
    > there's a need to version sub-modules or can we restrict versioning to
    > modules only. We would like to hear from the WG on this, especially
    > those with experience managing sub-modules.
    
    Yes I think this is needed.  At tail-f, there are several modules with
    many submodules.  These modules always use include by revision, and
    always the main module is always uddated when any submodule is
    updated.  It doens't make much sense IMO to not use include by
    revision.
    
    > For completeness, below is an update from Jason in github:
    > My initial reaction is that we should not preclude the use of revision
    > label with a submodule. Submodules have their own version today. The
    > trick is to define (or explicitly say it is out of scope) whether a
    > module version must change if any underlying submodule versions
    > change. That gets difficult if you consider simply moving a leaf from
    > one sub-module to another (without changing anything else about it -
    > its context, etc).
    
    Why would this be difficult?  The revision date is updated on any
    editorial change (see 7.1.9 of RFC 7950).  So if a leaf gets moved
    from submodule A to submodule B, then their revisions are udpated, and
    hence the module's include-by revision is udpated, and hence the
    module's revision ois updated.
    
I think what Jason meant is that by moving a leaf between submodules, it's possible the module's schema didn't change.
So yes revision date is updated, but you can't blindly update the revision-label.

Regards,
Reshad.

    /martin
    
    
    
    > 
    > Regards,
    > Reshad.
    > 
    > On 2020-03-27, 5:44 PM, "netmod on behalf of Reshad Rahman (rrahman)"
    > <netmod-bounces@ietf.org on behalf of
    > rrahman=40cisco.com@dmarc.ietf.org> wrote:
    > 
    >     Hi,
    >     
    >     https://github.com/netmod-wg/yang-ver-dt/issues/49
    >     
    >             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?
    >     
    >     Good point. What was meant by that the label space for modules and
    >     sub-modules are orthogonal.  e.g. the sub-module and module both have
    >     the same label, it shouldn't be inferred that the 2 are related.
    >     We'll change/clarify the text.
    >     
    >     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
    >         
    >     
    >     _______________________________________________
    >     netmod mailing list
    >     netmod@ietf.org
    >     https://www.ietf.org/mailman/listinfo/netmod
    >     
    >