> On 24 May 2016, at 12:04, Martin Bjorklund <m...@tail-f.com> wrote:
> 
> Ladislav Lhotka <lho...@nic.cz> wrote:
>> 
>>> On 24 May 2016, at 10:33, Martin Bjorklund <m...@tail-f.com> wrote:
>>> 
>>> Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> wrote:
>>>> On Mon, May 23, 2016 at 05:29:42PM +0200, Ladislav Lhotka wrote:
>>>> 
>>>> [...]
>>>> 
>>>>> This mixes up paths in the data tree with those in the schema
>>>>> tree. The XPath expression in the "path" statement is evaluated in the
>>>>> context of a data tree, but if the result is an empty node set, then
>>>>> "this leaf node" makes no sense.
>>>>> 
>>>>> A specific example:
>>>>> 
>>>>> leaf fooref {
>>>>> type leafref {
>>>>>   path "../foo";
>>>>>   require-instance false;
>>>>> }
>>>>> }
>>>>> 
>>>>> leaf foo {
>>>>> type uint8;
>>>>> when "../bar < 42";
>>>>> }
>>>>> 
>>>>> leaf bar {   
>>>>> type uint8;
>>>>> default 100;
>>>>> }
>>>>> 
>>>>> If there is neither "foo" nor "bar" in the data tree, what is the
>>>>> value space of "fooref"?
>>>>> 
>>>> 
>>>> Hm. Is it not both? The path refers to a schema node in order to
>> 
>> The path argument is XPath (in particular, it can contain key value
>> predicates that can be interpreted only in an instance data tree), so
>> it doesn't refer to a schema node.
> 
> Note that is a very restricted XPath expression.  The key values are
> only used in predicates, and the predicates don't affect the location
> path.

But the one below is valid, right? You have always insisted that schema nodes 
for which "when" expression evaluates to false are not part of the schema, 
which means that different entries of the same list may have different schemas, 
and predicates then affect the location path - "if:interface" is an example. 

> 
>>>> determine the base type (which is the base value set if
>>>> require-instance is false). If require-instance is true, then there is
>>>> an additional constraint that refers to a set of data nodes that
>>>> essentially determine a (possibly empty) subset of the value space.
>>>> 
>>>> If you agree with this, then we essentially have to phrase this
>>>> clearly.
>>> 
>>> Exactly.  My proposal was:
>>> 
>>> OLD:
>>> 
>>>  The leafref type is used to declare a constraint on the value space
>>>  of a leaf, based on a reference to a set of leaf instances in the
>>>  data tree.  The "path" substatement (Section 9.9.2) selects a set of
>>>  leaf instances, and the leafref value space is the set of values of
>>>  these leaf instances.
>>> 
>>>  If the leaf with the leafref type represents configuration data, and
>>>  the "require-instance" property (Section 9.9.3) is "true", the leaf
>>>  it refers to MUST also represent configuration.  Such a leaf puts a
>>>  constraint on valid data.  All such nodes MUST reference existing
>>>  leaf instances or leafs with default values in use (see Section 7.6.1
>>>  and Section 7.7.2) for the data to be valid.  This constraint is
>>>  enforced according to the rules in Section 8.
>>> 
>>> NEW:
>>> 
>>>  The leafref type is used to declare a constraint on the value space
>>>  of a leaf, based on a reference to a set of leaf instances in the
>>>  data tree.  The "path" substatement (Section 9.9.2) is used to refer
>>>  to another leaf node.  The leafref value space is the value space of
>>>  this leaf node.
>> 
>> The "path" expression is evaluated in some context that's defined in
>> the text. The result is a node set in the *instance* data tree, and in
>> my example this node set is empty.
>> 
>> Yes, I understand that *usually* there is some leaf node in the schema
>> that defines the type of the leafs selected by the XPath expression
>> (if they existed), but I think it is problematic to simply say that an
>> XPath expression refers to a schema node.
>> 
>> Consider the example in Appendix A of RFC 7223. If I have a leafref
>> path like
>> 
>> "/if:interfaces/if:interface[name='at-0/0/0']/eth:duplex"
>> 
>> then if 'at-0/0/0' isn't an Ethernet interface, it doesn't refer to
>> any leaf node because "eth:duplex" is not valid for that particular
>> path expression.
> 
> Correct, so the value space would be the value space of eth:duplex.
> The additional constraint would always evaluate to false if there is
> never an interface 'at-0/0/0'.

There can be one:

"interface": {
   "name": "at-0/0/0",
   "type": "ianaift:atm",
   ...
}

According to sec. 7.21.5, the leaf node "eth:duplex" is invalid in this entry, 
so it makes no sense to talk about its value space.

Lada

> 
> 
> /martin
> 
> 
> 
>> 
>> Lada
>> 
>>> 
>>>  If the "require-instance" property is "true", there MUST exist an
>>>  instance, or a leaf with a default value in use (see Section 7.6.1
>>>  and Section 7.7.2), of the leaf being referred to with the same value
>>>  as the leafref value in a valid data tree.
>>> 
>>>  If the leaf with the leafref type represents configuration data, and
>>>  the "require-instance" property (Section 9.9.3) is "true", the leaf
>>>  it refers to MUST also represent configuration.
>>> 
>>> 
>>> Please comment and/or suggest improvements to this proposal.
>>> 
>>> 
>>> 
>>> /martin
>> 
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




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

Reply via email to