On Fri, 2018-11-23 at 12:33 +0100, Juergen Schoenwaelder wrote:
> 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

The term "value space of a schema tree node" is not defined.


>    definining the referenced data tree node.

With require-instance=false there needn't be any 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

Right. In this case it is not "further restricted" but rather there is a
discrete set of possible values.

Lada

> '(see Section 9.9.3)' to the end of the first sentence to handle this.
> 
> /js
>    
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to