On Fri, Nov 23, 2018 at 11:05:48AM +0100, Martin Bjorklund wrote: > Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> wrote: > > On Fri, Nov 23, 2018 at 10:22:11AM +0100, Ladislav Lhotka wrote: > > > Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> writes: > > > > > > > On Thu, Nov 22, 2018 at 03:00:27PM +0100, Martin Bjorklund wrote: > > > >> Andy Bierman <a...@yumaworks.com> wrote: > > > >> > > > > >> > 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. > > > > > > > > Time for an errata? > > > > > > Here is the old discussion thread: > > > > > > https://www.ietf.org/mail-archive/web/netmod/current/msg15979.html > > > > > > Everything relevant had been extensively discussed in it, and I am > > > sceptical that we can come up with anything significantly better - it > > > will only be more (or different) hand-waving. The problem is inherent in > > > the leafref design introduced in YANG 1.1. It won't go away no matter > > > how much we paper over it. > > > > > > > So you think the use of 'schema tree' in the text quoted above (is > > used to identify the referred leaf or leaf-list node in the schema > > tree) is correct?? > > > > I do not want to discuss whether you like the design of leafrefs or > > not here - at this time we should focus on whether the text is correct > > or not given the design we have. So again, you think that 'schema > > tree' is correct in the statement? > > After reading the quoted thread and thinking some more, I think the > text in 9.9 is in fact correct. As Lada wrote in that thread: > > 2. It [path] also implicitly refers to a leaf node in the schema > [...] > > The problem is that this "implicit reference" isn't defined. 9.9 > talks about reference to a schema node, and 9.9.2 talks about the data > tree, but there is no text that ties these together.
Here is an attempt to rewrite things in a way according to how I understand things works. It should be possible to describe what we mean. If we can't do that, we have a bigger problem. (I have changed only the last two sentences.) OLD 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) 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. NEW 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) is used to identify a leaf or leaf-list node in the data tree. The value space of the leafref node is determined by the value space of the schema tree node definining the referenced data tree node. This likely is not perfect yet but perhaps we manage to make it perfect. ;-) What is not yet clearly described I think is what 'further restricted by corresponding instance nodes in the data tree' means (and that I think depends on require-instance). Perhaps add '(see Section 9.9.3)' to the end of the first sentence to handle this. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/> _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
