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

"Reshad Rahman (rrahman)" <rrahman@cisco.com> Mon, 30 March 2020 17:56 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 E8F9E3A0980 for <netmod@ietfa.amsl.com>; Mon, 30 Mar 2020 10:56:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.7
X-Spam-Level:
X-Spam-Status: No, score=-7.7 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=BatSS+v2; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=KX9o1Drh
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 qpBww2iqzSa0 for <netmod@ietfa.amsl.com>; Mon, 30 Mar 2020 10:56:24 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19DBB3A098B for <netmod@ietf.org>; Mon, 30 Mar 2020 10:56:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13392; q=dns/txt; s=iport; t=1585590983; x=1586800583; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=XX/YY9/FZ0gmVnzIWJ+2cyUkrRNzrH9clpk0v2HGjqY=; b=BatSS+v26l+7KwwTYtYF5fMbb6lJVx/8f/CLoOouAEzjKKGZEN0a04aa O41z0sCQ2rw9e8WUelOHdUv9GLnRjabc1qiRGjjTNk5uVrqiCB3+0vmAG YAsLVUEfovnRh0612EaKbCfjHz099MzG/ZgsOhsO6h4iKJiQOKbk61Ntm 8=;
IronPort-PHdr: =?us-ascii?q?9a23=3AZGFaSR0M8CqI7ZtYsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxKHt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQE1fyLPvjaQQxHd9JUxlu+HToeUU=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DdAQB7MoJe/4gNJK1mGwEBAQEBAQE?= =?us-ascii?q?FAQEBEQEBAwMBAQGBe4FUUAVsWCAECyoKhBCDRQOKaoJfmB+BQoEQA1QKAQE?= =?us-ascii?q?BDAEBGA0IAgQBAYN/RQIXghskOBMCAwEBCwEBBQEBAQIBBQRthVYMhXABAQE?= =?us-ascii?q?BAgEBARAREQwBASwLAQ8CAQgYAgImAgICJQsVEAIEDgUigwQBgksDDiABDqI?= =?us-ascii?q?5AoE5iGJ1gTKCfwEBBYJFgj4YggwDBoEOKowxGoFBP4ERJyCCHy4+gmcBAQI?= =?us-ascii?q?agS8xIQKCWDKCLI1/AQOCd4YemVEKgjyHYY80HYJMlEmEV5Bqh0WSbQIEAgQ?= =?us-ascii?q?FAg4BAQWBaSKBWHAVOyoBgkFQGA2OHYNzhRSFQXQCEIEXjGEBgQ8BAQ?=
X-IronPort-AV: E=Sophos;i="5.72,325,1580774400"; d="scan'208";a="746413740"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Mar 2020 17:55:52 +0000
Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 02UHtqA6008670 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 30 Mar 2020 17:55:52 GMT
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 30 Mar 2020 12:55:52 -0500
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 30 Mar 2020 12:55:51 -0500
Received: from NAM11-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 30 Mar 2020 12:55:51 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lRchMDDihjU5OF4m9BCzTum+lfWzQQLYCf7cnfs7+O6CL6rgree8m8fEe6BYhq0t3uVA5YnC3aThMC3012LqJPopwEoBp7jLTSIzxGAEvOls/amawkes/KX4+F30HmJXktsVmVdnFEWBkdbdwZofNhG78ECKRptfWfmE55ReP2wgS0lMLFHO8xUojOB3TWzkIykwPNwBcFxID7Y4pGnyXXI/zf8N45lhZ9Q3NQuQjjqG2AjkYnwmcoIjn0S7cIWrF4cDXxcqMBEbSRQLbfjcp6PvkNvZUtGZ0ZIMUUfo8Zi6celgBeedkNo4r2wRo9mUnYMB3NdwCiaGt8xzoiwk3A==
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=XX/YY9/FZ0gmVnzIWJ+2cyUkrRNzrH9clpk0v2HGjqY=; b=QMtmW/TfMV97LYx9vjDmagOG/y9tq3mzKNCmjnuYAyL8QcIFZ0uXcy0V53OqLybvgfP9RuNVq9v9tcappI2TiRch1xkziwwqvqu473JvcqH+HYmtPS8x81ultxTGMp/PfT9xC9jZ0bP82J76dSlbWG9PuaROXMSwu+pt5MmCpEGfHgfzX0VsbZu4/4hFMUQrAShwa6kLLIPS3FyxNaC5lDL8uJjQHveojMJEkdCd+H9fo3cVYUpPbEPw7yzQYtznwhSMiuVEMOoGY/T8DGcf2lwOvqESbG4EiCfEvr9t0Hg35bQ7LzPh2+HW2ZJQv9BpK76LaOyv8OIuxCz6ZyPbbg==
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=XX/YY9/FZ0gmVnzIWJ+2cyUkrRNzrH9clpk0v2HGjqY=; b=KX9o1DrhoVjZdmN3ONVqBYL8+inisUcrG154rreydJ/izO2I1sx/3XUmiS0H3K5XugOYn38ulwWo/eHPPCLGpTbaawt7bDDvRQ7s5MaBoH5wIQh+xYmttW6aa9wGWuV7cpJRbJoNXbCXx71iH46CyDNcee8Ys4xwXAzOXVI2Gdc=
Received: from DM6PR11MB3420.namprd11.prod.outlook.com (2603:10b6:5:69::31) by DM6PR11MB4612.namprd11.prod.outlook.com (2603:10b6:5:2a8::19) 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 17:55:50 +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 17:55:50 +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: AQHWBNyukTO5JXWurk2ljZZiFHPveKhhLBqA
Date: Mon, 30 Mar 2020 17:55:50 +0000
Message-ID: <76623C79-BB91-4B5F-8FEA-406ADEAD1647@cisco.com>
References: <75CFDBD9-143C-407A-B7C3-26CEC51E229C@cisco.com> <20200328.094121.1160081114435152145.id@4668.se>
In-Reply-To: <20200328.094121.1160081114435152145.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: 54ce3f13-8405-4af3-06f3-08d7d4d39587
x-ms-traffictypediagnostic: DM6PR11MB4612:
x-microsoft-antispam-prvs: <DM6PR11MB46129EF9B5879C9B6E0DEB25ABCB0@DM6PR11MB4612.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)(39860400002)(366004)(376002)(396003)(136003)(8676002)(8936002)(66574012)(4326008)(2616005)(81156014)(81166006)(6512007)(33656002)(64756008)(66946007)(71200400001)(2906002)(91956017)(6486002)(76116006)(66446008)(66556008)(66476007)(6506007)(478600001)(316002)(26005)(53546011)(186003)(966005)(5660300002)(86362001)(36756003); 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: Fv7Q3wTYW56WSYVcuJJ2JPwiTOob+0bqyDE6G0uo44nQTIfKkNumBJorRlEbwAMrxQBd7GGlJR02eWfA2yARrQeznaR3plsU3SkCZm8xUEY3PEM81AWt/cncS6HG9awfz+Ml4kO++Vi+IcTtK+F4Emb8QMJuADLpwEBy51jk2mXgVP8acvM+7H9odHOl/8F0WhI1afQlXJbOcvms71R/BNwn9bnIJpZwOoePYBTgdK9Q5Z7YTPHKS7U7kxAHpWb3eSxBpml2K76XPmh5amtelJKgERidRcXE/C5MQ5sTo5X0s1Up72TJNyjZB2Cs5a263Ky/VhsWohW7FvUAzi56/P4R/wpbffeNZaLUWK44KBgawktZ30bjJWXwnxdBjCduytxayPhIJp+68aGTdWyLIoNxY05xl5ytOpx1Qfh6znzRoqwIogh6yPZvs9M8wKOCmJqS1BW1XrC8izYo/UIoYMe5VLq9/RI4w6zF0LESCoedf1E1ofuKhjDN+xt0dWD4bGGNM0Py7KNtHAdP/ea6Kw==
x-ms-exchange-antispam-messagedata: YlrL1Z1CIjAx8Ik0+ZGBvQCaRGUALMpKcDNQ0LprRPoDqLbXhR7ILZnxGzDBwYuZ1WUAjMqb7LMfYBONlK2IECy9yYpCaYVeBFCdVZteKWG3BaQrwUCebID+aWXXMgmnuVxiD0Cfv3e6PQRPCZ+yOg==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <16AE95CDA0F5484EBB18B42DCD633687@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 54ce3f13-8405-4af3-06f3-08d7d4d39587
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Mar 2020 17:55:50.6387 (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: L385+FfWL0PZhXleFlfEZWkMag11Pir7v/5VPzGrqNzQYbLJIagZWJCfICe3vfnN51NTKqqG5lkMnIhJIJxsMw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4612
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com
X-Outbound-Node: alln-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/K1s5HgsIUwJL5dovdsJPt8VQddU>
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 17:56:26 -0000

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?

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