On Mon, Jun 8, 2015 at 11:49 AM, Ladislav Lhotka <lho...@nic.cz> wrote:
> Andy Bierman <a...@yumaworks.com> writes:
>
>> On Mon, Jun 8, 2015 at 8:39 AM, Kent Watsen <kwat...@juniper.net> wrote:
>>>
>>>
>>>
>>>>I think the two leafs are coupled through the path statement and so the
>>>>values of both should conform to the same type. If I extend Balazs¹
>>>>example with uint8 and 1..10 range:
>>>>
>>>>1. Would a leafref value of 256 be acceptable?
>>>>
>>>>2. How about "foo"?
>>>
>>>
>>> I agree it doesn't makes sense, but is the configuration invalid?
>>>
>>> The leafref is marked require-instance=false, it just means a matching
>>> condition will never succeed.
>>>
>>
>> If require-instance = false then the node must conform to
>> the data type for the leaf. This means the typedef used
>> in the implemented version.
>>
>>> Would a configuration be invalid if a "when" expression could never
>>> evaluate to true?
>>>
>>
>> The node would never appear in a configuration.
>> A must-stmt then is always false would make the config invalid.
>
> What's actually relevant to the subject of this thread (and supports
> Kent's point somewhat) is this example:
>
> leaf foo {
> type uint8;
> must ". <= 10";
> }
> leaf bar {
> type leafref {
> require-instance false;
> path "../foo";
> }
> }
>
> Should <bar>20</bar> be flagged as invalid? IMO no. At first sight it
> looks exactly like Balazs' example but in fact it is different - if
> there is no "foo", the must expression doesn't apply.
>
I don't see where a range "1..20" is introduced.
The "leaf bar" has the same type as /foo,
so that is uint8.
I see your point... does "require-instance false"
mean it could be a valid value for the leaf, but
no instances happen to exist with that value?
Or does it mean valid for the same data-type but the instance
may never exist?
I think "valid for the data type" is correct.
The must-stmt says valid for the leaf to exist.
That is a separate test.
> Lada
Andy
>
>
>>
>>
>>>
>>> Kent
>>>
>>
>>
>> Andy
>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
