> On 19 Oct 2015, at 21:22, Andy Bierman <[email protected]> wrote: > > > > On Mon, Oct 19, 2015 at 12:04 PM, Juergen Schoenwaelder > <[email protected]> wrote: > 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. > > > Why? Returning an error seems fragile to me. > What if the client is using a template that creates some data structure. > The request says "add foo when X is true, add bar when Y is true). > Pruning the false when-stmt is what the client should expect. > Otherwise the template is very fragile and the client has to make a different > template for every possible permutation of the data structure with > and without false-when nodes.
I see it otherwise. If a client wants to delete existing configuration, he should do it explicitly, perhaps in the same transaction. With the complexity of "when" evalution, it is way too easy to mess up things. Especially when concurrent clients modify the configuration at the same time, the only correct server behaviour IMO is to return a validity error: "I don't accept your edit because another client did some edits in the mean time that are incompatible with your stuff." Lada > > > /js > > > Andy > > -- > 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/> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
