On Tue, Jun 7, 2016 at 8:52 AM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:
> On Tue, Jun 07, 2016 at 11:26:03AM -0400, Dale R. Worley wrote:
> > Ladislav Lhotka <lho...@nic.cz> writes:
> > > "Dale R. Worley" <wor...@ariadne.com> writes:
> > >> A difficulty I have with the current wording is that it doesn't point
> > >> out the crucial fact about leafref that the XPath expression can only
> > >> select elements that are instantiations of one particular data node.
> I
> > >> don't know XPath, but it seems that that is not a general property of
> > >> XPath expressions, you seem to be able to write XPath expressions that
> > >> select heterogenous groups of elements. So it's worth pointing out
> that
> > >> the allowed XPath expressions can't do that, and that is because of
> the
> > >> restriction that the expression must match path-arg.
> > >
> > > Right, this is the slightly hand-waving part that I also objected to.
> An
> > > XPath expression in a leafref's "path" statement indeed selects a node
> > > set from an instance data tree. The node seet can be empty, but if it
> is
> > > non-empty, all its members necessarily have the same type, which is
> > > defined in a certain "leaf" schema node.
> > >
> > > The relationship is relatively straightforward but difficult to explain
> > > concisely. One basically has to follow the steps in the XPath
> > > expression, ignore all path-predicates, and skip all schema nodes that
> > > aren't data nodes (i.e., "choice" and "case" nodes).
> >
> > Yes, it's difficult to explain, though once one gets the idea, it's
> > straightforward enough. The problem I have is that it's not pointed out
> > explicitly anywhere. (E.g., Juergen suggests section 9.9.2, but I don't
> > see it there.)
> >
> > The crucial points seem to be:
> >
> > - The XPath expression is limited by the syntax "path-arg" and the rules
> > in 9.9.2.
> >
> > - Because of those restrictions, there exists one data node in the
> > schema such that: evalutating the expression for any leaf or
> > leaf-list node in any data tree returns a set of nodes, all of which
> > are instances of that one schema node.
> >
> > - The type of that schema node is the base type of the leafref.
> >
> > - Once you learn this, it's easy to see, for any particular
> > leaf/leaf-list node and path expression in a module, which schema node
> > is the one. But it's rather hard to describe that process.
> >
> > Actually, there's an ugly question: If the path expression references
> > an element name that doesn't exist in the module. Perhaps there are
> > rules in XPath that prevent it, but it seems to me that you could write
> >
> > leaf mgmt-interface {
> > mandatory false;
> > type leafref {
> > path "../interface/name";
> > require-instance true;
> > }
> > }
> >
> > when the current module doesn't have a "name" child defined for
> > "interface". As long as a data tree didn't contain a mgmt-interface
> > elememt, the constraint would not be violated.
> >
> > But a later revision of the module, the "name" child could be added,
> > allowing data trees to contain mgmt-interface elements, because data
> > trees could now have "name" elements.
> >
> > The point being that when you're figuring out which schema node is the
> > base type for the leafref, that schema node has to exist so the base
> > type can be extracted. But there's no direct statement of that as a
> > requirement for path validity.
> >
>
> As WG chair, I am getting a bit nervous. We have to wrap things up and
> we need deliver the specification - it is past WG last call, it is
> past IETF last call, it is past IESG approval (kind of). We can likely
> endlessly continue to search for possible ways to misunderstand the
> specification but lets remember the aphorism 'perfect is the enemy of
> good'.
>
> I leave it to Martin's discretion to decide whether he wants to add
> 'The referred leaf or leaf-list node in the schema tree MUST exist.'
> to the new text but I think the time has come to stop searching for
> new possible ways to misunderstand the specification.
>
>
Doesn't the text above exclude a default leaf or leaf-list from the
value space? That would be incorrect.
I like to see all issues closed by the end of the week a new revision
> with all changes posted. People can then check the edits to be sure
> nothing broke and then the document should move via Benoit into the
> RFC editor queue by the end of the following week or Monday June 20th.
>
> /js
>
>
Andy
> --
> Juergen Schoenwaelder Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
>
> _______________________________________________
> 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
