On Mon, Nov 2, 2015 at 5:28 PM, Russ White <7ri...@gmail.com> 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 > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs >
_______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs