Ladislav Lhotka <[email protected]> wrote: > > > 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."
I agree with Andy. This is one of these cases where the feature might be complicated in theoretical corner-cases, but extremely useful in practice. People that use YANG try to capture real-world semantics. I have never seen anyone trying to refer to the conditional nodes in a when expression - simply b/c it doesn't make any sense. And anyway, changing this would be backwards incompatible, so I don't know how constructive this conversion is right now. At this point, it would be useful to focus on the text in 7.21.5 to make sure it captures the current semantics. /martin _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
