Andy Bierman <[email protected]> writes: > 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?
No, it is an error because the resulting data tree is invalid. > 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? I don't advocate auto-deleting anything in <config> payload either. Lada > > > > 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 >> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
