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. > > It is 1 thing to just declare this feature in the architecture and quite another to get it to work with real YANG. In fact, there is no 1 "data model". There is an ever-growing set of modules, with various forms and degrees of inter-dependence. Dean's draft does a good job of explaining these module types: https://tools.ietf.org/html/draft-bogdanovic-netmod-yang-model-classification-05 We cannot just assume that data nodes in different modules do not interact and cause a conflict. Quite the opposite, since a common data modeling practice is to create a framework and a set of augmenting modules for that framework. It is OK if there are different levels of interoperability expectations. Some details can be mandatory, some left for future work, some specifically left to the server implementation. This level of detail is still very TBD. 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
