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

Per Hedeland <per@hedeland.org> Thu, 22 November 2018 16:04 UTC

Return-Path: <per@hedeland.org>
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 667ED126C7E for <netmod@ietfa.amsl.com>; Thu, 22 Nov 2018 08:04:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outbound.mailhop.org
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 rS6Z1yRCI2ri for <netmod@ietfa.amsl.com>; Thu, 22 Nov 2018 08:04:05 -0800 (PST)
Received: from outbound1f.eu.mailhop.org (outbound1f.eu.mailhop.org [52.28.59.28]) (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 A43CE124BF6 for <netmod@ietf.org>; Thu, 22 Nov 2018 08:04:04 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1542902640; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=sSspBI+s5zptOlQuxVxfgRQQachhKxFYe8voGsdM+f82FnHyetLugS4v5zI7/YJs9hQ2jpGqoA0kZ xANv3vGro1Fl5BRvCNl8HkmaAZYxByvBsxiKBJSGNj5m1t5Lch6cdD59xXW3mQHjvFGiJ1WViAkdWP veHqHFYUKavfASZscm1Bol5XHAl76/z1kF26ZPDREVKdtke4Ct+6jld1GbLKzoNrzyv7vviGX4B4bn /nF5JR+5qUe8aQGklddTQojHu4YpxPLzp39RltLt+z3g0Z086CKVBHtLqxlQgOMSAeLzsYBa0Y3yZK PNAbeqqecEGJM6sH+dNk26eWvb17/vw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:content-type:in-reply-to:mime-version:date: message-id:from:references:cc:to:subject:dkim-signature:from; bh=YFXyuvEDcevLqwCa7Ni3nrjwpm6noEgBGsV3988eHHM=; b=Tt9sKp7SMaXLwhpYyxCt4nXG19hQCQCK/KlILZoultubjiEcNZYxBR6IpbTKRmTVE6/xJ4VfyJdUU ftVCfV8+4YG7wPtJ0Id+sLJ+w0NmLb6qcsHe2KhAFwBZaBBFLwZE61sTFWintDDQz/sW/4awYEr//N 2rLKxVhfzECBMUge8i9amPsVoUh8sTUG9W//xpHGrHTYKDl1UjyxWQ8wAwbQNhszYb5u6H8RIpttey REs2IjxTF7ODj3c3TzBNVN3cscDHx+E/SQ64IxJQR5qiraYh2zVBMaRbTacJiw1R1g74dBCBfK+ot1 WmOgxiFY0zGJ9NNgtmRESxLbbgvqyVw==
ARC-Authentication-Results: i=1; outbound2.eu.mailhop.org; spf=none smtp.mailfrom=hedeland.org smtp.remote-ip=81.228.152.101; dmarc=none header.from=hedeland.org; arc=none header.oldest-pass=0;
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:content-type:in-reply-to:mime-version:date: message-id:from:references:cc:to:subject:from; bh=YFXyuvEDcevLqwCa7Ni3nrjwpm6noEgBGsV3988eHHM=; b=A7k9SRyu/y7+AxxFzlzfgKPb0b12xqNTWiCi/155U5c6UZX8ej39wANoih4ZrM0UOpdQM85/azuVD gOlD0i9W9KiVA3yZ2p2ACR7sa7mbZbCXmR3BzW1bcJvxP0SX1tHxBTblc8cG2UDlC8nxmQ5I3/iYW7 1OZD9PpApzDesuFkk1y5H5YjydiisHjrBryWIktrlfWrdbAeNJ4lDOwiwErpTCp/I+MJ7iznqLVc0P P2gmXLwOtkEiWzSfLMKqM8YeXwq9zDAqJnFe4xk/SESk8IjpSwAzG3+fQJ/ZOpGgiXw1iq5/bEWI+n WfxbwPYzR+crv/ayb5+aiC13DMoFswA==
X-MHO-RoutePath: cGVyaGVkZWxhbmQ=
X-MHO-User: 36985a54-ee70-11e8-a886-bd2f23b465e5
X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information
X-Originating-IP: 81.228.152.101
X-Mail-Handler: DuoCircle Outbound SMTP
Received: from hedeland.org (unknown [81.228.152.101]) by outbound2.eu.mailhop.org (Halon) with ESMTPSA id 36985a54-ee70-11e8-a886-bd2f23b465e5; Thu, 22 Nov 2018 16:03:57 +0000 (UTC)
Received: from mars.tail-f.com ([173.38.220.34]) (authenticated bits=0) by tellus.hedeland.org (8.15.2/8.15.2) with ESMTPSA id wAMG3qKg054990 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 22 Nov 2018 17:03:54 +0100 (CET) (envelope-from per@hedeland.org)
X-Authentication-Warning: tellus.hedeland.org: Host [173.38.220.34] claimed to be mars.tail-f.com
To: Ladislav Lhotka <lhotka@nic.cz>, "Sterne, Jason (Nokia - CA/Ottawa)" <jason.sterne@nokia.com>
Cc: Martin Bjorklund <mbj@tail-f.com>, "netmod@ietf.org" <netmod@ietf.org>
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> <DB7PR07MB3978617868059E29A6B251F59BDB0@DB7PR07MB3978.eurprd07.prod.outlook.com> <e721e717d892afb88eae0e42db7fc6de8bbec0c4.camel@nic.cz>
From: Per Hedeland <per@hedeland.org>
Message-ID: <439a474f-55d4-c6a5-9043-e87d2b241d63@hedeland.org>
Date: Thu, 22 Nov 2018 17:03:47 +0100
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <e721e717d892afb88eae0e42db7fc6de8bbec0c4.camel@nic.cz>
Content-Type: text/plain; charset=windows-1252
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/MNQq9Dc2WRPQ1rj30LmSdmmSeVU>
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 16:04:08 -0000

On 2018-11-22 16:37, Ladislav Lhotka wrote:
> On Thu, 2018-11-22 at 15:31 +0000, Sterne, Jason (Nokia - CA/Ottawa) wrote:
>> 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?
> 
> Yup.
> 
> Lada
> 
>>
>> (they *do* appear in augment paths though since that definitely needs to refer
>> to schema)

They also appear in 'deviation' and 'refine' paths, which unlike augment
paths can identify a leaf or leaf-list (although 'refine' is of course
only relevant for nodes in a (top-level) grouping).

--Per

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