Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?

"Sterne, Jason (Nokia - CA/Ottawa)" <jason.sterne@nokia.com> Thu, 22 November 2018 15:31 UTC

Return-Path: <jason.sterne@nokia.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 26067129533 for <netmod@ietfa.amsl.com>; Thu, 22 Nov 2018 07:31:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.36
X-Spam-Level:
X-Spam-Status: No, score=-3.36 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=nokia.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 rgtUjkn8M0Uc for <netmod@ietfa.amsl.com>; Thu, 22 Nov 2018 07:31:45 -0800 (PST)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70124.outbound.protection.outlook.com [40.107.7.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FFE11292AD for <netmod@ietf.org>; Thu, 22 Nov 2018 07:31:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Njjs5LBLPJVB5MPyIyGyD+sOHNbVKKSrUBPMjUcdc9I=; b=SoRd+Y5P3ObLVRvc5O4uuBLLs2hSLAdFIs+yICFhAABjqx4fhP9MswEntI4j1y4Hj4JQ6r5VrNdDwXJV+JOBNommRP8hX9OwpQJ5QNbnDmLQ0byPofn31LGE12fDP9k1U30EvhqYKhomK3lmv5F8zoQ4Fh3LvgxmBrO9/0pZRSc=
Received: from DB7PR07MB3978.eurprd07.prod.outlook.com (52.134.100.23) by DB7PR07MB5321.eurprd07.prod.outlook.com (20.178.44.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1382.7; Thu, 22 Nov 2018 15:31:42 +0000
Received: from DB7PR07MB3978.eurprd07.prod.outlook.com ([fe80::d501:332:48c7:4d6c]) by DB7PR07MB3978.eurprd07.prod.outlook.com ([fe80::d501:332:48c7:4d6c%3]) with mapi id 15.20.1382.007; Thu, 22 Nov 2018 15:31:42 +0000
From: "Sterne, Jason (Nokia - CA/Ottawa)" <jason.sterne@nokia.com>
To: Ladislav Lhotka <lhotka@nic.cz>, Martin Bjorklund <mbj@tail-f.com>
CC: "andy@yumaworks.com" <andy@yumaworks.com>, "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?
Thread-Index: AdSARc1DsD04ldMzQTGmSlWVLz4VPQABCoCAAIeMyAAAACrqAAAAdPmAAABDp4AAAlncAAAAPWQAAAB3qIAAABKU4A==
Date: Thu, 22 Nov 2018 15:31:42 +0000
Message-ID: <DB7PR07MB3978617868059E29A6B251F59BDB0@DB7PR07MB3978.eurprd07.prod.outlook.com>
References: <CABCOCHS18StYKGC4f7cPWFraKNHRsC9cWfrmfZ0j773awdicvQ@mail.gmail.com> <20181122.150027.823800945772964674.mbj@tail-f.com> <adedb81ce97abf16bafa47118349287954d4d410.camel@nic.cz> <20181122.161438.975515366125603770.mbj@tail-f.com> <b9cee54baea59539fe6e4005345049cac8fd6f3a.camel@nic.cz>
In-Reply-To: <b9cee54baea59539fe6e4005345049cac8fd6f3a.camel@nic.cz>
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=jason.sterne@nokia.com;
x-originating-ip: [45.72.219.254]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DB7PR07MB5321; 6:6Q7AaYQccmhmvssDKIKF+NnWDj3cYky5KFJeOSlTAJegr/VV/l1P+VxMhjMJbjt0BADxFT6oMVOut6FhTGS6IhGRSwlLYV1vMyctzx7Nmk4BEQX2rzDI829K9ygxi1P5EhQsY8DSEjyV1+G/sap70NX8Txo1HjThxl8xQYSR/9r3mRIWCYnw+0N+NqIF6fd4jWuAyn1tPiLGx5CU9JPAaF4Au5u+/IlQ/vcaYzk2KTY2bXn8b4HWtaWTjBjFhF/xwophZnP9vj8B9HNrjuDktIpYPmhDZwHQBVABOn7xO0hK8s+Q7dsSmBiezBE8Ki88WE3u1IEolGmXkBXsyjhZXO88cuBDIktc6bjIKxB/5rBwpzwdmV/rgBzbh+Tsy5hYgwQBm6bElNsY7e5ZTLvMPhTPEwJw3MUyhLBJy0chZjQXdkDnj/5Cv0mTJJg8FyOsXd5+YphfohREkGYMDtT3WQ==; 5:4eA9l9DyE6bSkhIdBGb28skQ8r6R8tiXaT1KYu9RLJfupsgu7/eo+xa0sndAhDDqOZYk8jFIVHRaYjpDfXNoftDI1gOyedRKgfu04gGT3MFSVTUzpgxXR5T3ViO4y/lYnS5aJ2c/YqWsA8gMI57JbC7VuSfkxBi5y0c0MOsf+RM=; 7:bVFCB2tHkthvwUviQFoj1/RY/Gv1/HCf0Pri3wDaa+z3HxqqJFmo/D/pMrg5XpwyDq8haZBOh4ogIWj/FgZrl+7dY4FOFSzcQxKRptHqzQsIzr0cuGedRjUHO+oAnA3NYDV83dUguQMATWgQ6rSbqQ==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: a173ce3a-3473-4f35-1668-08d6508f9a75
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7193020); SRVR:DB7PR07MB5321;
x-ms-traffictypediagnostic: DB7PR07MB5321:
x-microsoft-antispam-prvs: <DB7PR07MB53213BB6535930606F1BE5979BDB0@DB7PR07MB5321.eurprd07.prod.outlook.com>
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231442)(11241501184)(806099)(944501410)(52105112)(3002001)(10201501046)(6055026)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123558120)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:DB7PR07MB5321; BCL:0; PCL:0; RULEID:; SRVR:DB7PR07MB5321;
x-forefront-prvs: 0864A36BBF
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(376002)(346002)(136003)(366004)(39860400002)(53754006)(13464003)(189003)(199004)(102836004)(4001150100001)(114624004)(93886005)(6246003)(4326008)(105586002)(14444005)(256004)(316002)(14454004)(106356001)(26005)(186003)(6506007)(53546011)(53936002)(86362001)(6436002)(8936002)(229853002)(2900100001)(33656002)(446003)(7736002)(74316002)(54906003)(486006)(66066001)(9686003)(2906002)(6306002)(8676002)(81166006)(81156014)(55016002)(476003)(68736007)(25786009)(11346002)(110136005)(7696005)(71200400001)(71190400001)(76176011)(478600001)(5660300001)(305945005)(3846002)(6116002)(97736004)(99286004); DIR:OUT; SFP:1102; SCL:1; SRVR:DB7PR07MB5321; H:DB7PR07MB3978.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: e2oh1OYG/FWZ7uVXhK5WDIU9LeyXFY/lCuj8IGco5PHx8AqbJUr1c+0/phpETtWQF545IvTSxWM9z49cu66FxbhYS8qNbld7vjof53wj8z3B+TnpLcYOB5o0PWfg+hM75Ts1gh+2PRypJgHBnA67zcQzGJmdRmrEIMllT7glK9eR2wphfbdgsbpfuKBLcfjD0uQcpPw3Zd+LRCPInd1RHdXsHf7nKh/stSJWzgTpryDYwbTB8vwXqq+cAdQCjCURr9La0FR5gIYu0poS8aJ3QwQ4DhX7SuzWDpAZ4Z5boh1KSFGruvKdFaHoqDTlV0za2jQR/5evx62t1LEP8+k8HyvBy06m+UisYcEj0acqWto=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a173ce3a-3473-4f35-1668-08d6508f9a75
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Nov 2018 15:31:42.0703 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB5321
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/6w_KA_aD5cmKprcIj-dWpfrFnEs>
Subject: Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?
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: Thu, 22 Nov 2018 15:31:48 -0000

From what I can understand below, none of this debate affects the conclusion that choice & case identifiers do *not* appear in:
- leafref paths
- must statements
- when statements
right?

(they *do* appear in augment paths though since that definitely needs to refer to schema)

Jason

> -----Original Message-----
> From: Ladislav Lhotka <lhotka@nic.cz>
> Sent: Thursday, November 22, 2018 10:28 AM
> To: Martin Bjorklund <mbj@tail-f.com>
> Cc: andy@yumaworks.com; Sterne, Jason (Nokia - CA/Ottawa)
> <jason.sterne@nokia.com>om>; netmod@ietf.org
> Subject: Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC
> change?
> 
> On Thu, 2018-11-22 at 16:14 +0100, Martin Bjorklund wrote:
> > Ladislav Lhotka <lhotka@nic.cz> wrote:
> > > On Thu, 2018-11-22 at 15:00 +0100, Martin Bjorklund wrote:
> > > > Andy Bierman <andy@yumaworks.com> wrote:
> > > > > On Thu, Nov 22, 2018 at 5:39 AM Martin Bjorklund <mbj@tail-f.com>
> wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > Ladislav Lhotka <lhotka@nic.cz> wrote:
> > > > > > > Andy Bierman <andy@yumaworks.com> writes:
> > > > > > >
> > > > > > > > On Mon, Nov 19, 2018 at 12:32 PM Sterne, Jason (Nokia -
> CA/Ottawa)
> > <
> > > > > > > > jason.sterne@nokia.com> wrote:
> > > > > > > >
> > > > > > > >> Hi all,
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> If we have a YANG model with a leaf:
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> MODEL VERSION 1:
> > > > > > > >>
> > > > > > > >> container my-model {
> > > > > > > >>
> > > > > > > >>     leaf a { type string; }
> > > > > > > >>
> > > > > > > >> }
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> And then later we produce another version of the model where
> that
> > > > > > leaf is
> > > > > > > >> placed into a choice construct:
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> MODEL VERSION 2:
> > > > > > > >>
> > > > > > > >> container my-model {
> > > > > > > >>
> > > > > > > >>     choice some-choice {
> > > > > > > >>
> > > > > > > >>         case x {
> > > > > > > >>
> > > > > > > >>             leaf a { type string; }
> > > > > > > >>
> > > > > > > >>         }
> > > > > > > >>
> > > > > > > >>     }
> > > > > > > >>
> > > > > > > >> }
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> Is that considered a non-backwards-compatible change?
> > > > > > > >>
> > > > > > > >
> > > > > > > >
> > > > > > > > yes -- even though the data node /my-model/x did not change,
> > > > > > > > the schema node /my-model/a changed to /my-model/some-
> choice/x/a.
> > > > > > > > Any leafref path pointing at this leaf will break.
> > > > > > >
> > > > > > > This is not correct. A leafref path is a special XPath, and as such
> > > > > > > includes only data nodes, i.e. NOT choice and case nodes.
> > > > > > >
> > > > > > > What does change are schema node identifier. This could be
> > significant
> > > > > > > in an augment statement, but not ini this example because a leaf
> > cannot
> > > > > > > be augmented anyway.
> > > > > > >
> > > > > > > I don't see anything else that could break, so Jason's change seems
> > > > > > > backward compatible to me.
> > > > > >
> > > > > > Since it does change the schema tree, this is not legal according to
> > > > > > 7950.  So in that sense it is not backwards compatible.  The rules in
> > > > > > 7950 protect both clients and other modules that import the
> module.
> > > > > >
> > > > > >
> > > > > This text is confusing wrt/ schema tree vs data tree:
> > > > >
> > > > >
> > > > > 9.9 <https://tools.ietf.org/html/rfc7950#section-9.9>;;.  The leafref
> > > > > Built-In Type
> > > > >
> > > > >    The leafref built-in type is restricted to the value space of some
> > > > >    leaf or leaf-list node in the schema tree and optionally further
> > > > >    restricted by corresponding instance nodes in the data tree.  The
> > > > >    "path" substatement (Section 9.9.2
> > > > > <https://tools.ietf.org/html/rfc7950#section-9.9.2>;;) is used to
> > > > > identify the referred
> > > > >    leaf or leaf-list node in the schema tree.  The value space of the
> > > > >    referring node is the value space of the referred node.
> > > >
> > > > Yes, it should be "data tree" in both occurrences.
> > >
> > > I tend to disagree. The values of a leafref are first restricted according
> > to
> > > the *schema*, i.e. even before any leaf instance exists in the data tree
> > that
> > > the leafref can point to. Consider this example:
> > >
> > > list map {
> > >   key name;
> > >   leaf name {
> > >     type string;
> > >   }
> > >   leaf value {
> > >     type uint8;
> > >   }
> > > }
> > > leaf link {
> > >   type leafref {
> > >     path "../map[name='quux']/value";
> > >     default "foo";
> > >   }
> > > }
> > >
> > > We had a long discussion about this, maybe I could find it, and the
> > conclusion
> > > was that a YANG parser should flag the default "foo" value as incorrect
> even
> > > before any instance data are in sight.
> >
> > Yes, this is correct.  The quoted text needs to be rewritten to make
> > this more clear.  Altough the path refers to a (potential) node in the
> > data tree, that node obviously has a node in the schema tree, and its
> > value space restricts the value space of the leafref node.
> >
> > > I wasn't exactly happy with this conclusion because it assumes that we
> can
> > use
> > > the XPath from the argument of "path" to locate the *schema node* and
> check
> > its
> > > type. Although it looks appealing (everybody sees what the type of
> "value"
> > is,
> > > right?), I think this is just another unfortunate example of mixing up the
> > > schema and data instances.
> > >
> > > Let me ask: can we expect a newcomer to understand what's going on if
> even
> > > seasoned YANG doctors get confused?
> >
> > Yes.
> >
> > I've been told that people don't read documentation or specifications
> > and just look at examples.
> 
> The problem with examples is that they have to stay at a trivial level where
> everything looks obvious and nobody has to care about subtle details such as
> the
> difference between XPath and schema node identifiers. Those who had to
> implement
> the above logic for a general case will confirm that it is pretty tricky.
> 
> Lada
> 
> >
> >
> >
> > /martin
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67