> On 16 Oct 2015, at 12:27, Balazs Lengyel <[email protected]> wrote:
>
> IMHO YANG should define the behavoir, and I would want it to be the same on
> Netconf/Restconf/CLI etc.
> I agree that " 1) you get an error back" would be the best: because it is the
> easiest to understand for the operator, with the fewest corner cases.
> Also we must define if in the same transaction we set b=42 and a=2. which of
> the 3 options are taken?
>
>
> We should not leave such complex cases undefined, or alternatively state that
> they are implementation dependant.
I might be difficult to say what is a complex case, unless we abandon XPath in
"when" statements and use something else - and considerably simpler.
Here is another interesting corner case - does it qualify as being complex?
leaf-list bar {
type uint8;
when "count(../*) > 1";
}
leaf foo {
type uint8;
}
Assuming no instances exist, is this edit allowed? (This was essentially your
question.)
<bar>1</bar>
<foo>2</foo>
But what about this?
<bar>1</bar>
<bar>2</bar>
Lada
> regards Balazs
>
> On 2015-10-16 09:43, Ladislav Lhotka wrote:
>>> On 15 Oct 2015, at 18:03, Martin Bjorklund <[email protected]>
>>> wrote:
>>>
>>> Andy Bierman
>>> <[email protected]>
>>> wrote:
>>>
>>>> On Thu, Oct 15, 2015 at 4:53 AM, Martin Bjorklund <[email protected]>
>>>> wrote:
>>>>
>>>>
>>>>> Andy Bierman <[email protected]>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> You are incorrect.
>>>>>>
>>>>>> Within the PAYLOAD (as this section describes), there is no when-stmt
>>>>>> for data nodes within the datastore. Look at the YANG for edit-config.
>>>>>> There are no when-stmts for "interface" in "edit-config".
>>>>>>
>>>>> Andy, there is some confusion here. The section talks about:
>>>>>
>>>>> For configuration data, there are three windows when constraints
>>>>> MUST be enforced:
>>>>>
>>>>> - during parsing of RPC payloads
>>>>> - during processing of NETCONF operations
>>>>> - during validation
>>>>>
>>>>> So the entire section talks about constraints *on configuration data*.
>>>>>
>>>>>
>>>>>
>>>> http://www.netconfcentral.org/modules/ietf-netconf/2011-06-01#edit-config.421
>>>>
>>>>
>>>>
>>>> Here is the YANG for edit-config?
>>>> Please point out the when-stmts in this rpc-stmt
>>>> specific to the "interface" node.
>>>> I just see an "anyxml" that has no when-stmts at all.
>>>>
>>>> So enforcing the when constraint on the RPC PAYLOAD
>>>> clearly has nothing to do with "interface" -- just the parameters
>>>> specified in the rpc-stmt.
>>>>
>>> Ok, you're right. 8.2.1 should be kept as it is. (we may need to
>>> rephrase the intro text in 8.2) But I think Balazs is also right.
>>> Suppose you have:
>>>
>>> leaf a {
>>> when "../b = 42";
>>> type int32;
>>> }
>>> leaf b {
>>> type int32;
>>> }
>>>
>>> and the db contains b=10.
>>>
>>> Suppose I send an edit-config with a=2. What is the result?
>>>
>>> 1) you get an error back
>>> 2) you get ok; the request to set a to 2 is silently dropped
>>> 3) something else
>>>
>> IMO YANG spec shouldn't deal with this kind of things in the first place. It
>> should be sufficient to define two validation levels, e.g. syntactic
>> (schema) and semantic validity. Stating what a protocol does if either of
>> these validity types is violated would then be up to the protocol spec, and
>> different protocols may use different approaches.
>>
>> That said, I like #1 best.
>>
>> Lada
>>
>>
>>>
>>>
>>>
>>> /martin
>>>
>>> _______________________________________________
>>> netmod mailing list
>>>
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/netmod
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>
>>
>>
>>
>> _______________________________________________
>> netmod mailing list
>>
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>>
>>
>
> --
> Balazs Lengyel Ericsson Hungary Ltd.
> Senior Specialist
> ECN: 831 7320
> Mobile: +36-70-330-7909 email:
> [email protected]
>
>
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
