On Tue, Oct 20, 2015 at 1:09 AM, Martin Bjorklund <[email protected]> wrote:
> 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. > > +1 The false-when deletion has been there from the start, and works just like the remove-old-case-stmt if the client selects a new case from a choice-stmt. The 'shared candidate without a lock' argument does not apply at all. That is fragile with or without when-stmts. The argument "the client might not know what it is doing" is also really weak. How does the server know that? 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 > Andy
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
