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

["Sterne, Jason (Nokia - CA/Ottawa)" <[e-mail]>]

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