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

[Ladislav Lhotka <[e-mail]>]

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)
> 
> 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
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67