On Mon, Nov 2, 2015 at 6:05 PM, Joel Halpern Direct < [email protected]> wrote:
> What we side with regard to the atomicity of collisions was that the model > needed to specify that. So if the model writer concludes that the leaves A > and B in your example are so closely coupled that bad things will happen if > different people write different parts, then they can say the container is > the granularity. Usually, I would expect the leaf to be the granularity. > We do not expect the I2RS agent (or the underlying system) to guess the > granularity. > > OK -- so it is part of the data model definition. Good. These are the details wrt/ "first wins" that need to be understood. The WG and proto-dt needs to think about what YANG extensions would be needed to describe these boundaries in machine-usable form. Yours, > Joel > > Andy > On 11/2/15 9:02 PM, Andy Bierman wrote: > >> >> >> On Mon, Nov 2, 2015 at 5:28 PM, Russ White <[email protected] >> <mailto:[email protected]>> wrote: >> >> >> > For example, if state gets over-ridden, but preserved, then even >> though it >> is >> > not doing any good, the client which installed the state must still >> monitor for >> > any related dependenecies so as to not leave incorrect pending >> state. >> > Which also means that a client has to be able to remove state it >> has >> created, >> > even though that state has been over-ridden. And probably has to >> be able >> > to create state which won't take effect. Which in turns means >> that you >> need >> > to be able to read your own effects and the current state >> separately. >> >> I would think this should be a client specific implementation >> detail... I >> don't see why, from a protocol level, it should be disallowed, when >> the >> changes involved would be minor (or at least it seems to me?). >> >> >> I am not sure I understand edit collision processing. >> The proposals is that the ephemeral datastore contains data >> from 1 or more clients. The data from different clients is >> non-overlapping >> (for some definition of that). >> >> I will avoid running config + ephemeral leaf-override for now. >> Assume the data model is entirely for I2RS: >> >> container foo { >> leaf A { type int32; } >> leaf B { type int32; } >> } >> >> 1) client-worst set /foo/A to 42 { "foo": { "A":42 } } >> >> 2) client-best sets /foo/B to 7 { "foo": { "B":7 } } >> >> 3) Is client-best going to knock out data owned by client-worst? >> what happens to /foo/A? >> >> Q1) Is this a collision because /foo is written by both clients? >> if not, does client-best own /foo and /foo/A, and client-worst owns >> /foo/B? >> If yes, then step (2) is effectively a PUT, no matter what method is >> really used >> >> Q2) what notifications are sent to client-worst, if any (depending on >> answer to Q1) >> (client-worst either lost ownership of /foo or /foo and /foo/A) >> >> Consider that A and B can be arbitrary subtrees, not just leafs. >> >> How are the edit collision boundaries specified? >> Simple YANG overlap will cause lots of deletions. >> More granular/complex boundary specification would help >> avoid such deletions where the 2 clients could actually co-exist. >> >> >> :-) >> >> Russ >> >> >> >> Andy >> >> _______________________________________________ >> i2rs mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/i2rs >> >> >>
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
