On Thu, 2018-11-22 at 15:00 +0100, Martin Bjorklund wrote: > Andy Bierman <a...@yumaworks.com> wrote: > > On Thu, Nov 22, 2018 at 5:39 AM Martin Bjorklund <m...@tail-f.com> wrote: > > > > > Hi, > > > > > > Ladislav Lhotka <lho...@nic.cz> wrote: > > > > Andy Bierman <a...@yumaworks.com> writes: > > > > > > > > > On Mon, Nov 19, 2018 at 12:32 PM Sterne, Jason (Nokia - CA/Ottawa) < > > > > > jason.ste...@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. 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? Lada > > > > /martin > > > > > > > > > > > > > > > > > > /martin > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > Lada > > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > >> > > > > >> Does the answer depend on whether the choice contains other cases (or > > > > >> other cases that are the default case)? > > > > >> > > > > >> > > > > >> > > > > > > > > > > no > > > > > > > > > > > > > > >> MODEL VERSION 3: > > > > >> > > > > >> container my-model { > > > > >> > > > > >> choice some-choice { > > > > >> > > > > >> case x { > > > > >> > > > > >> leaf a { type string; } > > > > >> > > > > >> } > > > > >> > > > > >> case y { > > > > >> > > > > >> leaf b { type string; } > > > > >> > > > > >> } > > > > >> > > > > >> } > > > > >> > > > > >> } > > > > >> > > > > >> > > > > >> > > > > >> A client 'foo' using VERSION 1 would still be able to set & read back > > > leaf > > > > >> a in the same way as it always did. > > > > >> > > > > >> > > > > >> > > > > >> But if another client 'bar' (using VERSION 3) sets leaf 'b', then > > > leaf 'a' > > > > >> would disappear. That could be surprising to client 'foo' although > > > perhaps > > > > >> no more surprising than if another client simply deletes leaf 'a' > > > (using > > > > >> VERSION 1). > > > > >> > > > > >> > > > > >> > > > > >> Jason > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> _______________________________________________ > > > > >> netmod mailing list > > > > >> netmod@ietf.org > > > > >> https://www.ietf.org/mailman/listinfo/netmod > > > > >> > > > > > _______________________________________________ > > > > > netmod mailing list > > > > > netmod@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > -- > > > > Ladislav Lhotka > > > > Head, CZ.NIC Labs > > > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > > > _______________________________________________ > > > > netmod mailing list > > > > netmod@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod