On Sun, Oct 18, 2015 at 08:22:25AM -0700, Andy Bierman wrote: > On Sun, Oct 18, 2015 at 7:43 AM, Ladislav Lhotka <[email protected]> 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. > > > > > This goes against the Postel Principle, > You can make your code as fragile as possible if you want. > I have always written servers that try to figure out what the client is > doing. > > It seems obvious to me that when-stmt is applied after edits are applied, > just like a choice-stmt. > > The server should not be guessing that valid edits from the client > are really programming errors. >
To me, auto-deletion feels fragile. /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
