> On 20 Oct 2015, at 10:09, 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.
Note that this also applies to cases of a plain choice. If user A adds case C1 and user B (who is not aware of A's changes) then adds case C2, I don't want the server to automatically nuke A's changes. It's the same as in source code management systems - if there is a conflict, it is left to human users to resolve it. > > And anyway, changing this would be backwards incompatible, so I don't > know how constructive this conversion is right now. This is not true, if we stick to the YANG 1.1 constraints that are in the charter - no 1.0 module becomes invalid. Lada > > 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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
