On Wed, Oct 21, 2015 at 4:45 AM, Balazs Lengyel <[email protected]
> wrote:
> I would love to get rid of the autodelete feature. It really complicates
> things.
>
So how would when-stmt work?
It would be an error if a false when-stmt ever occurred?
leaf X { type int32; }
leaf Y { when "../X=3"; type int32; }
Let's say the client creates node in candidate:
create /X value=3
works OK
create /Y value=42
works OK
merge /X value=5
Is this an error because it would cause /Y to be deleted?
Or does it work like choice-stmt, and the new /X is accepted
and the old /Y is deleted?
Why would this scenario be treated differently then if the auto-delete
happens
on a node provided in the <config> payload?
regards Balazs
>
Andy
>
> On 2015-10-18 16:43, Ladislav Lhotka wrote:
>
>> On 18 Oct 2015, at 11:52, Juergen Schoenwaelder <
>>> [email protected]> wrote:
>>>
>>> On Thu, Oct 15, 2015 at 06:03:57PM +0200, Martin Bjorklund wrote:
>>>
>>>> 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
>>>>
>>>> Isn't the simplest to always make the changes that were requested in
>>> the rpc/action (e.g. edit-config) and then to validate the result and
>>> if it fails to validate to return an error? No magic addition or
>>> removal of nodes while trying to guess what the client wanted to
>>> achieve. I am likely missing details since I never implemented this
>>>
>> That would be the type of behaviour I'd prefer. The auto-deletion feature
>> also goes against the principle of least embarrassement - a trivial error
>> can inadvertently erase substantial parts of a data tree.
>>
>> Lada
>>
>> but having a processing logic that is simple to understand would be
>>> good and I think it is fair to expect that clients send edits that
>>> do not require the server to guess what should happen.
>>>
>>> /js
>>>
>>> --
>>> 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
>>> [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]
>
> _______________________________________________
> netmod mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod
>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
