[netmod] No descendent statements to input/output can be reordered (WAS Re: mbj review of draft-verdt-netmod-yang-module-versioning-01)

"Reshad Rahman (rrahman)" <rrahman@cisco.com> Fri, 27 March 2020 21:42 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 6ECC93A0CED for <netmod@ietfa.amsl.com>; Fri, 27 Mar 2020 14:42:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.6
X-Spam-Level:
X-Spam-Status: No, score=-9.6 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, 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=h7D8LtdU; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=qNcE9xH4
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 lvENzxUPzvAD for <netmod@ietfa.amsl.com>; Fri, 27 Mar 2020 14:41:58 -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 CAE673A0DA6 for <netmod@ietf.org>; Fri, 27 Mar 2020 14:41:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10198; q=dns/txt; s=iport; t=1585345317; x=1586554917; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=hPIy94zeXZilh7aLRFdmDP3DBSi3P9V0THMqwlKaIDY=; b=h7D8LtdUKBhUhKXBHzP87+FvsT2+ZbN4ByNwYEVHp7BHuzz8a5C8h+H0 ac8zzPWWWboIKkw7JIJND7wdNdIUc41rPtDynvEF/h7ncH76yxzDvUVdI eQFYPaDVCME6GkGQzmbMkMjGcbcGRGBKv2xaIZC7boxR4IwfKX9ntjevK k=;
IronPort-PHdr: =?us-ascii?q?9a23=3At/WCpByxiabjBf/XCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YhSN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZufE0T7KffsRyc7B89FElRi+iLzPA=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AuCgB7cn5e/5ldJa1mHQEBAQkBEQU?= =?us-ascii?q?FAYF7gVRQBWxYIAQLKgqEEINFA4pqTpowgUKBEANUCgEBAQwBARgNCAIEAQG?= =?us-ascii?q?Df0UZghokOBMCAwEBCwEBBQEBAQIBBQRthVYMhXMFARAREQwBASwMEQEiAh8?= =?us-ascii?q?HAgQlCxUSBAESIoMEAYJLAy4BDqIXAoE5iGJ1gTKCfwEBBYUmGIIMAwaBDiq?= =?us-ascii?q?MMRqBQT+BEScggwuCZwEBAhqBLzEhAoJYMoIsjX0BA4J3hh2ZTAqCPIdfhVW?= =?us-ascii?q?JWB2CTJRGhFePFIFQh0KSaAIEAgQFAg4BAQWBaSIqgS5wFTsqAYJBUBgNjh0?= =?us-ascii?q?4gzuFFIVBdAIQgReMYQGBDwEB?=
X-IronPort-AV: E=Sophos;i="5.72,313,1580774400"; d="scan'208";a="479215634"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Mar 2020 21:41:57 +0000
Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 02RLfufT030565 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 27 Mar 2020 21:41:56 GMT
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 27 Mar 2020 16:41:56 -0500
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 27 Mar 2020 16:41:56 -0500
Received: from NAM04-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 27 Mar 2020 16:41:55 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QEQwrfKYJIoAO5Rq4hifHJRggWmMVLv8MGuPFcMRCNIgl9PgvjtewF7VgsJ3Q79PC6kozu/6EN+x0SWlhY6MG8+2nsRYxW4mVnuCK5emZRXi56HbzH1okxjgFkk0PzJDOH5W5n2O2LJuMylXLIV5YRFXoFixPYcM6GC78/pxGdiGL+30VvZstLJgPiJ31usrUPPc0TxGtbsfBM1tvH3v/h81BGDj0dz2npRmURjEMWDKfvtb54TVBEx/Qx91mb8Z6vM9Jv84fQssd6iAH/L6HtuhcJTU16zIBf5RTX1juWjvVBCyKF3dU+CpqzhCtgBC0nWZKZrYdIWmNFn8/v5YcA==
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=hPIy94zeXZilh7aLRFdmDP3DBSi3P9V0THMqwlKaIDY=; b=IRJrlaA+GUkZl8gTu4OmiqA076j6VXibQCie+e3j/nMHyGfoX+jbZ+82/CcWJ9w6+mTcvSVJri9Fur1anewXRb5A6yxNjPohmp49rq3Zj1jTAMTuvpSRcggzI5d+DPDwLutOmzoZIUJhh+yjvOozI5ILK+e5sVqgSRCoWwXBTK42e2cHBsHBB2lbSn0KCCBowf7GBTOpgHj2OCMuatd63oLiiIXzI3D8PxhqDy7JG3Je1lYELDALJfpKU/FRToGpCpRxfIu21Rx0hXN7U/v8Zb5TaCfC/LcOnarPxIWqm8FoZksWqHniQLwcfpc4SmjUCSCYamdalWj0HKX6hCMvUg==
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=hPIy94zeXZilh7aLRFdmDP3DBSi3P9V0THMqwlKaIDY=; b=qNcE9xH4PSY6pSSkCFsQXLdwWE4nOGWk1wE+hy1k19mkj/tjzePJSu2qr1uapp7BVN3oAS8Y8X9r8gOpeaI/Y/972+Wlc6zFBuNrrpKw9zkZZc1BTT2kT3X9A9Ccm4ik0F7v6KsG6wLbVJBtVqZjf6n/b2gxj8gBLDR5Nn1cw/I=
Received: from DM6PR11MB3420.namprd11.prod.outlook.com (2603:10b6:5:69::31) by DM6PR11MB4188.namprd11.prod.outlook.com (2603:10b6:5:198::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.18; Fri, 27 Mar 2020 21:41:54 +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; Fri, 27 Mar 2020 21:41:54 +0000
From: "Reshad Rahman (rrahman)" <rrahman@cisco.com>
To: =?utf-8?B?TWFydGluIEJqw7Zya2x1bmQ=?= <mbj+ietf@4668.se>, "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: No descendent statements to input/output can be reordered (WAS Re: mbj review of draft-verdt-netmod-yang-module-versioning-01)
Thread-Index: AQHWBICIXhWWsfDDo0Goifxbx4NJTA==
Date: Fri, 27 Mar 2020 21:41:54 +0000
Message-ID: <809C7D15-95DD-49CF-975A-B55F08D8C782@cisco.com>
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: b9b8c8d7-54e4-4eb1-d105-08d7d297ab06
x-ms-traffictypediagnostic: DM6PR11MB4188:
x-microsoft-antispam-prvs: <DM6PR11MB4188D177C88318F1156642FDABCC0@DM6PR11MB4188.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-forefront-prvs: 0355F3A3AE
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(366004)(39860400002)(136003)(396003)(376002)(2906002)(86362001)(33656002)(8936002)(66556008)(64756008)(66446008)(66946007)(66476007)(8676002)(81156014)(5660300002)(53546011)(966005)(36756003)(6506007)(6512007)(76116006)(91956017)(71200400001)(316002)(2616005)(186003)(26005)(110136005)(81166006)(478600001)(66574012)(6486002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR11MB4188; H:DM6PR11MB3420.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords;
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: gfDSqIcH3T9WX8Mnwav4kAUa7dvkqy1Bs8zQhQHaOt3JMDb7JGzcEDLp40O1rzXy3OuXn276/7+OfRB7HjDp620Wr1edqdMqwS7RC2vlExE6evUcaPy6WavcaH5R4TLPQirD3jOLzRr/MlHFhWieD1t82xMTp0o9k6tJO0TjkeRTmqaDquhXP6emwo9Qb8EDvLNX3nVgj5amnnISyozgi/YYue5UOU2PnDoX9PyvCwZH2jtyS/huGPSCrAn5bMUPllFOY5wWQYcubHtQNa651Fj5YT62atpXi+DNy7iPm40S5QfCfL/LmnuGUCF233Zgz3sasXLooEph36fwbUtUjVufU/E9f6EAv8uf7bDY47sM6wCB0aKmmM5W6eiZAguwVBspcTnJVaze8E+Az9PfnEHRSVMp/pqTrfzja9RJ9cUiqVG/Mfv01tJooLx/LGmMNzNpoFcDeSb6aLGa7lOAzBDBXv29pl3P0JCkqiIR7vSqn2jTHcaTx+bse/noeaeEG/LZ9D3o4yrK8XLWT4phQA==
x-ms-exchange-antispam-messagedata: H6djJu8AffRQNOScEvZ5NgTFIOkXxl2YpKu1IChQc3eOwxpPVa4bXAn5Ws+a0HxdiczO8v7fiENrCG5261atERZ1naVPdRf1dg+T445y6dSXx8Nn+GQ/ynye8XhAER0WoG/T5vYm5JtbzHN/BUnhXw==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <2CFBB52CD35D3548BD9D7C4D07FDAC39@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: b9b8c8d7-54e4-4eb1-d105-08d7d297ab06
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Mar 2020 21:41:54.6570 (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: 6UjkUCjB2IqFIGA+Yq59ZBn37fbRRIxhAWZetehhRvU5pBpkFh5KgpdJd96EjjY9AnmJIoqMLC1x5Rdv1fBEew==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4188
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com
X-Outbound-Node: rcdn-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/iXWcIEmA_OF55c313-vj-zklzHY>
Subject: [netmod] No descendent statements to input/output can be reordered (WAS Re: mbj review of draft-verdt-netmod-yang-module-versioning-01)
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, 27 Mar 2020 21:42:05 -0000

Hi,

https://github.com/netmod-wg/yang-ver-dt/issues/47

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


Sounds good. JTBC, by descendent you're referring to data nodes (children, grandchildren etc) and not to statements like type and description?

Also, could you refresh our memory why the decision was made to preserve order of input/output data nodes?

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