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

[Ladislav Lhotka <[e-mail]>]

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