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

[Per Hedeland <[e-mail]>]

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 <[e-mail]>
>>> Sent: Thursday, November 22, 2018 10:28 AM
>>> To: Martin Bjorklund <[e-mail]>
>>> Cc: [e-mail]; Sterne, Jason (Nokia - CA/Ottawa)
>>> <[e-mail]>; [e-mail]
>>> 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 <[e-mail]> wrote:
>>>>> On Thu, 2018-11-22 at 15:00 +0100, Martin Bjorklund wrote:
>>>>>> Andy Bierman <[e-mail]> wrote:
>>>>>>> On Thu, Nov 22, 2018 at 5:39 AM Martin Bjorklund <[e-mail]>
>>> wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Ladislav Lhotka <[e-mail]> wrote:
>>>>>>>>> Andy Bierman <[e-mail]> writes:
>>>>>>>>>
>>>>>>>>>> On Mon, Nov 19, 2018 at 12:32 PM Sterne, Jason (Nokia -
>>> CA/Ottawa)
>>>> <
>>>>>>>>>> [e-mail]> 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