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

tom petch <ietfc@btconnect.com> Wed, 01 April 2020 11:21 UTC

Return-Path: <ietfc@btconnect.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 809DA3A0A3B for <netmod@ietfa.amsl.com>; Wed, 1 Apr 2020 04:21:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com
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 x3AU57Y0B1_N for <netmod@ietfa.amsl.com>; Wed, 1 Apr 2020 04:21:21 -0700 (PDT)
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50137.outbound.protection.outlook.com [40.107.5.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 053843A0955 for <netmod@ietf.org>; Wed, 1 Apr 2020 04:21:20 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kAEJA3dioYMZHklUm2G2Ws4Hhdn9L8UfmtpZiKOvsyUMmmk9YjMjwt42Ge9Yy00jIXRXHUoEx2EIJjxobtpxeDLQx4iHGuh51ojQzP4YffzNfxjBncVEB2TrE/rEp0zDZGFnpZo3kNr1x+1JRRJjBpbJVnvVkCF9NT333BC7PE+ZEw94VAKgQZTTps4BbNK0eqCaz66KJSTrtBq8nu+w/RKYTzz+mP2QAD0J4lQ72zN98xZg5kRHpq0WyvQ8dQixM5GQa/LqWKP2SNRR3qBXwfmYlhR4AyAGZgk09XYwRJuNDemrk7V3rywwRLSLSXWCqaHNRUHFbXBoV1Nkvei8rA==
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=SzPkhmTwXrnC8qXHt5bSJVy3YQa+OqxrHwwskahw9FQ=; b=GFCRu+cU3/GnKzfHCKj/pgi3ACbBfzpIOELt1m1uHQh//PEl7jvXQO3pY4Mm2TzJgwz2bYQR5zwS+ivORXK515rPNW9kN+gMOQqsyTTkVHdVvYHAg9mpT3k6RXbFkky1oxtXIoOy4oV+M0veYHMOGkqTeBbVgo5m1bbHCR3eCP/9oVzuXnlUXvJKp2gd9XqvnurHux7kw1nyXpUm3+8Fkb8X4jdkd7GS7BFpVAQPVBEJEFinLDoSFp7K40C+kZrRNxmg8+UrOar73oD4AB32Z40y18JUlMrlRqyAVRPCiebIAEX/IxYyKvJj81v4edTXdN9h/1uc+MTLd+yaYLrIHA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SzPkhmTwXrnC8qXHt5bSJVy3YQa+OqxrHwwskahw9FQ=; b=I5PCHCCPlp4CAGaeKWgFSI57C/RLkuf02NQQ/xaM72hrm2fnIjFbRkmvJDzCyRssvuwOEP1QlECTr6IhuAVn6N429NEozcifgCC9P29f/b0lhyiJ5vsSEZnA1mJGMP4Ibt+gsw090MHXMVQBSdsQU0Iy9yEhKQYlPpKKnGdC+fQ=
Received: from DB7PR07MB5657.eurprd07.prod.outlook.com (20.178.85.222) by DB7PR07MB5563.eurprd07.prod.outlook.com (20.178.47.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.12; Wed, 1 Apr 2020 11:21:18 +0000
Received: from DB7PR07MB5657.eurprd07.prod.outlook.com ([fe80::a438:bbc9:2ffe:33ee]) by DB7PR07MB5657.eurprd07.prod.outlook.com ([fe80::a438:bbc9:2ffe:33ee%5]) with mapi id 15.20.2878.013; Wed, 1 Apr 2020 11:21:18 +0000
From: tom petch <ietfc@btconnect.com>
To: =?utf-8?B?TWFydGluIEJqw7Zya2x1bmQ=?= <mbj+ietf@4668.se>, "rwilton@cisco.com" <rwilton@cisco.com>
CC: "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] No descendent statements to input/output can be reordered
Thread-Index: AQHWB1FOBW/F2Ml3aUmT9DFK9BjgOahilvOAgAGIsYk=
Date: Wed, 1 Apr 2020 11:21:18 +0000
Message-ID: <DB7PR07MB5657CDC9C3F6289C68E40CE1A0C90@DB7PR07MB5657.eurprd07.prod.outlook.com>
References: <809C7D15-95DD-49CF-975A-B55F08D8C782@cisco.com> <20200328.094306.1883371784477662660.id@4668.se> <MN2PR11MB4366BF797649EFE9AFBC4FC0B5C80@MN2PR11MB4366.namprd11.prod.outlook.com>, <20200331.135203.2237955857731629624.id@4668.se>
In-Reply-To: <20200331.135203.2237955857731629624.id@4668.se>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com;
x-originating-ip: [81.131.229.19]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 0569ac7b-82f4-44ef-646e-08d7d62ecc97
x-ms-traffictypediagnostic: DB7PR07MB5563:
x-microsoft-antispam-prvs: <DB7PR07MB55634B3DE477B36826033489A0C90@DB7PR07MB5563.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-forefront-prvs: 03607C04F0
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR07MB5657.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10019020)(366004)(136003)(39860400002)(396003)(346002)(376002)(6506007)(53546011)(7696005)(110136005)(316002)(55016002)(86362001)(71200400001)(4326008)(33656002)(9686003)(66556008)(64756008)(66446008)(91956017)(2906002)(52536014)(66574012)(76116006)(26005)(8936002)(966005)(81156014)(5660300002)(186003)(66476007)(66946007)(81166006)(8676002)(478600001); DIR:OUT; SFP:1102;
received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: P6gJPjZguKJkLV9vw9nret3Bf165U0YkYmEG7GHiVu6bCi6YUL7BQdReTalwK0lFmjyFAcJyxZpwpRVsLZ4ch2UHvGvr3THHo+rqfHXpLUxHodSjufabk5OyQGQK/uilTj1c+Wor5hWWizXv0mmW4XqwyqzUeb+bSz+foBJMFWBoNg8RoQ/QzfJIFDvuLgCb1lmd5/hFeD7iKRL8jCmNEmBZqm/ZA9mMuOpVluNOKLPZFRgIf9kbRD/b3TVrwJhZQdvnIjQ86QdBoZ3CTkJXU6YmgMfX0p+ayUicIHvAulPWOwVcn5P7P6bJcDgu/+ljNdDXTQ8qG82nO2wCIzQ6jRabpibXiq2dPBAEVQG7ZdllIfbud8Ini0HyZvzTXx7D9DJwgb04HCX8ZVCQeZ58H8fDSLuivs2lF0yGpk67t6+rssEmJh5Jh65GdWUD47kHs5cYNv1JsLilPT84H7UqJHPAHTm9J7AA5gJeBTeh4hBDTPLCk4PU7/EsAQ6URi2H0PG4qkIpztBLUEwAR5lUeQ==
x-ms-exchange-antispam-messagedata: 64ifEjPyV05yM8mRvmOk3bGkjUY2ldqUfAxdC3AFzgypmK/kW7GdFnwxzw14GcpjVLsBw3GZduQiBY6NOr1hZdxy0CCB4MP5kJVWAXt8Ik2TGrNcln7PLu9dt03k4yhp5K84KIvMhvwIBpVsds2FIA==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0569ac7b-82f4-44ef-646e-08d7d62ecc97
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2020 11:21:18.4488 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: rH1qPAHJjzvuf296YmzsLo26ukD7Mo9AXQCuYFRWm01PSg0dFvU0fpuD/PJJnnZHIsJHonWMtiz1lJi727bPOQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB5563
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/G3bU8yU9mKJw0LV65e5Pa_umucc>
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: Wed, 01 Apr 2020 11:21:24 -0000

From: netmod <netmod-bounces@ietf.org> on behalf of Martin Björklund <mbj+ietf@4668.se>
Sent: 31 March 2020 12:52
"Rob Wilton (rwilton)" <rwilton@cisco.com> wrote:
> [As an individual contributor]
>
> > -----Original Message-----
> > From: netmod <netmod-bounces@ietf.org> On Behalf Of Martin Björklund
> > Sent: 28 March 2020 08:43
> > "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.

RFC 7950, 7.17.2:

   When a node is augmented, the augmenting child nodes are encoded as
   subelements to the augmented node, in any order.

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

Correct.  This is something implementations must be able to handle.

<tp>
At a slight tangent, reordering of enumeration can result in new values being assigned as RFC 7950 s.11 points out so probably deserves a mention.  Ditto bits.

Tom Petch


/martin


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