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