Re: [netmod] No descendent statements to input/output can be reordered

"Rob Wilton (rwilton)" <rwilton@cisco.com> Tue, 31 March 2020 11:41 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 608103A18E7 for <netmod@ietfa.amsl.com>; Tue, 31 Mar 2020 04:41:16 -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=a7JeEyYg; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ux2VPFvK
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 OtrtL5wXlbis for <netmod@ietfa.amsl.com>; Tue, 31 Mar 2020 04:41:14 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C28C53A18E4 for <netmod@ietf.org>; Tue, 31 Mar 2020 04:41:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12144; q=dns/txt; s=iport; t=1585654873; x=1586864473; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ZQqk5eMUFh73JX4UFwmTX/2UMcOcCKpn9rl1ZR8QpwM=; b=a7JeEyYgTZm3GlcKPWte1VhCFhVguZ27Fifb3JyfOW2vH+2Y8J5e+BV/ d7Tck+hlcHkRtSc/2nQNnjXkryyain9QS+WEKQgk0srySxKne3bZh0r7m IWbM2eGkObCh0oLd7X+dzHJWDuhyR7G5uExW0ZUPtb3j+EMs7QN4grBih g=;
X-IPAS-Result: =?us-ascii?q?A0DoAQAALINe/51dJa1mGwEBAQEBAQEFAQEBEQEBAwMBA?= =?us-ascii?q?QGBe4FUUAVsWCAECyoKhBCDRQOKa4JfmB2BQoEQA1QKAQEBDAEBGAsKAgQBA?= =?us-ascii?q?YN/RQIXgh0kOBMCAwEBAQMCAwEBAQEFAQEBAgEFBG2FVgyFcAEBAQEDAQEQE?= =?us-ascii?q?REMAQEsCwELBAIBCBEEAQEBAgImAgICJQsVCAgCBAENBQgagwWCSwMuAQMLo?= =?us-ascii?q?lECgTmIYnWBMoJ/AQEFhRcYggwDBoEOKowxGoFBP4ERR4JNPoJnAQECGoEvA?= =?us-ascii?q?hoFECECglgygiyOAgEDBweCaoYgmVMKgj2HYYVaiXmCTJRLhFePG4FRh0eSb?= =?us-ascii?q?QIEAgQFAg4BAQWBaSIqgS5wFTuCbFAYDY4dg3OFFIVBdAKBJ4xUAYEPAQE?=
IronPort-PHdr: =?us-ascii?q?9a23=3AFPFiUh1W2lQ+T6UNsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxKHt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQE1L6KOLtaQQxHd9JUxlu+HToeREPStzzbFDTvHC+qCUKFE?= =?us-ascii?q?WjZyxyIOm9WpbIiNi63Pyz/JuVZBhUgD26YvV5KxDk5Q7QrcIRx4BlL+49zR?= =?us-ascii?q?bS6n1PZ6xayHhpKlSagxuZhI+o8YRm8jhMtv5p7MNGXajgN6Q/VqBDTTk=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.72,327,1580774400"; d="scan'208";a="444672494"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 31 Mar 2020 11:41:12 +0000
Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 02VBfC4Y026389 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 31 Mar 2020 11:41:12 GMT
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 31 Mar 2020 06:41:12 -0500
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 31 Mar 2020 06:41:11 -0500
Received: from NAM12-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 31 Mar 2020 07:41:11 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=izMFB6jtzmcw0ZuCthmTAhgPIr/J6gUA+tJtw2co7udNVSYpfit9XAYyF4tIjBYKwP1qf6fjmq7dJ9FeBQuuSV3r5FdoHYQ4BYdLVyJ+xeDLObLVmcwGvjJp9tCoBiSjMRaOA427uCsUG1fusIguexxXsSOqrqMTCWBEkZdmxkYtZXNvxS7kfJyLEXTYEtxZ1RiFlVeJ6JgNAPMJInLtdC4Q46MqpGU+ksCGT1ySSvPNNaQtOst/RSbd+8zJOE7a9agQgl13DfkOV8tr4jrhZeWGrmx3rlTFMnTUyEy47oQeltqMc2usDqupDqL4GmWneM0y9eUUPMxeYJbTfXaRlw==
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=ZQqk5eMUFh73JX4UFwmTX/2UMcOcCKpn9rl1ZR8QpwM=; b=k2NuHo2QvRmKQfCIoKVhou3IOTYWSUuLiitRN0J8ZAzceAuR5Mcse6baTSjO8gfbLiKbLjm2PCuTiqeI7IDfAytnxIWcocJrwj0DG019sucRbJCyoBncRu0OOZ2ZbpQWd+da/vQAs+z/Oulx8sz5po+738TsIKj5x0A6FEenqq2VCC6FJrIowIMiRNV8KWJ3/L6+Ruv7trzcOrGTG6ImKbPeaIfen4RpKwmKXOlcJs2D2Q+4PD29JSbQI12PJu0lFBRnLSA+i61PXviMIyoVsQw5eK0JAJzWcP+okgAP1RLP5ryiBclWPSJOSLKse9XEQeEWzV2+osZzSXmQF9NKjA==
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=ZQqk5eMUFh73JX4UFwmTX/2UMcOcCKpn9rl1ZR8QpwM=; b=ux2VPFvK53gQzW0cIlI6C5LCoguiOaYRy9VQT63fXzHTGJNoEegnI/TRHPSXNmCTE6ZzfT4yl8RK8QmA0JQ7V8bS7E47o6XZWe6hDFLIlE2MOzbbNG5GaCA5cf6/HQNfJByipaIFwN6wF5lAiO9t2tatZ3Y2vDgU6WfKpHfG3eg=
Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by MN2PR11MB4495.namprd11.prod.outlook.com (2603:10b6:208:189::11) 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 11:41:10 +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 11:41:10 +0000
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: =?utf-8?B?TWFydGluIEJqw7Zya2x1bmQ=?= <mbj+ietf@4668.se>, "Reshad Rahman (rrahman)" <rrahman@cisco.com>
CC: "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] No descendent statements to input/output can be reordered
Thread-Index: AQHWBNz0Njy9Szf9jEGvOy5gvo//56hilsVQ
Date: Tue, 31 Mar 2020 11:41:10 +0000
Message-ID: <MN2PR11MB4366BF797649EFE9AFBC4FC0B5C80@MN2PR11MB4366.namprd11.prod.outlook.com>
References: <809C7D15-95DD-49CF-975A-B55F08D8C782@cisco.com> <20200328.094306.1883371784477662660.id@4668.se>
In-Reply-To: <20200328.094306.1883371784477662660.id@4668.se>
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: 406126f1-fed0-4684-e668-08d7d56868da
x-ms-traffictypediagnostic: MN2PR11MB4495:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <MN2PR11MB4495671B7DB7DCB3670EEEC1B5C80@MN2PR11MB4495.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)(376002)(39860400002)(346002)(136003)(366004)(396003)(66946007)(66556008)(110136005)(186003)(71200400001)(66446008)(26005)(4326008)(55016002)(9686003)(52536014)(76116006)(316002)(64756008)(66476007)(7696005)(81166006)(66574012)(33656002)(86362001)(53546011)(8676002)(8936002)(5660300002)(6506007)(478600001)(81156014)(966005)(6636002)(2906002); 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: wcnfE5GiJz0keqi7iSm7m12xJyD1dww2Anw61QM2StFDahPh0vH6J9PrlGyOWvdiTdermd8r/sUz9lU12LaEB++EvH4q4sOWzndYWVk0mbMFZjzFAq11AVEY5sE7iQju7YZDgWjhbVfo6X/wnUA/Y5rHt5Y0m4vsDzppKfLoE4pU0p8v/gkyJKaa8QhmBvyOnhnD29cXHUIfNL+qc794QO0Y7CelW3VorOammbHNSHrKvc7UafUz58VZ2eJUNeXA+RniNdO/xyOd3boVSemsvPMXsi60gDDwWrdSzIKEk6DRcCFmGFf/SECNOAwk40QxRoLMBdxoCEr2lHKq2mOl266CggDvItWaaFFaABz/lmWyj310UPbU0ivAXDwKa9RxtbE6nWy+o7w79oLZs/qrPegWzCH1/4qH+0QlTJplA2P5itjSHvsd8bbCfwvXhKvPY4hWW6uZNCO6xAOa5AHml+KWdXv0njph2oUssaUar+Y76FxNEHiL8AMrYwxqiGqpLoOpFCCx+HAUqx10fePjKQ==
x-ms-exchange-antispam-messagedata: 3cmUSBn9wNTOiD5E+RtAI5GtAIRQ2xqpmSy6E6ZrmEsQGcCqDmoPFPNr9wfl0csHN9iuk0wc5j3DHo62Muiq1lV67xfVQ/WjVsByHlTvqVIvhGQELAfWZAJzicxBQFnPStv0k+l4Ck1PZzakXoBDgg==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 406126f1-fed0-4684-e668-08d7d56868da
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Mar 2020 11:41:10.8086 (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: HR5oF99n4SMLLr/e93c1kg9+NDjcr4bcZaBln6pFLTjIjwi+zyo6w8wS9uCw/9jsNY8ysXE6vQsQsgNDA4kuvQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4495
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com
X-Outbound-Node: rcdn-core-6.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/mERSTDLC7sD9dMjqI2FROBtwu4M>
Subject: Re: [netmod] No descendent statements to input/output can be reordered
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 11:41:16 -0000

[As an individual contributor]

Hi,

> -----Original Message-----
> From: netmod <netmod-bounces@ietf.org> On Behalf Of Martin Björklund
> Sent: 28 March 2020 08:43
> To: Reshad Rahman (rrahman) <rrahman@cisco.com>
> Cc: netmod@ietf.org
> Subject: Re: [netmod] No descendent statements to input/output can be
> reordered
> 
> "Reshad Rahman (rrahman)" <rrahman@cisco.com> wrote:
> > 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?
> 
> Yes I mean descendant nodes.
> 
> 
> > Also, could you refresh our memory why the decision was made to
> > preserve order of input/output data nodes?
> 
> This is b/c this order is preserved on-the-wire for some encodings (like
> XML).
[RW] 

This is slightly on a tangent, but RFC 7950 allows modules to augment RPC/Action input/output parameters.  I'm not aware of any defined order that augmentations are required to be processed in.  Hence it seems to me that the order that the client expects and server uses could end up being different if there are multiple augmentation to RPC input/output parameters.

Regards,
Rob


> 
> 
> /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
> >
> >
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod