Hello Jeff, just one brief reply/comment to point (b) in your summary, inline
Thanks --- Alex -----Original Message----- From: i2rs [mailto:[email protected]] On Behalf Of Jeffrey Haas Sent: Monday, September 29, 2014 8:01 AM To: Alexander Clemm (alex) Cc: Jeffrey Haas; [email protected]; Martin Bjorklund; Eric Voit (evoit); Andy Bierman Subject: Re: [i2rs] Two thoughts on an ephemeral data store ... > (b) It needs to be clear who owns the "golden copy" of an object. I needs > to be clear which objects are "authoritatively owned" by a datastore vs which > ones are reference. This is the datastore where the object is maintained, > updated, created; this is where conditions and constraints are evaluated, etc. This seems obvious, but there are a few potentially conflicting scenarios. If objects that are always intended to be ephemeral are never going to conflict (but may lie on top of) local config, there is never a conflict. There is simply referential integrity issues if the underlying local config is deleted and ephemeral config remains. If the objects are always disjoint, there is never a conflict. But if you permit an ephemeral object to override a local config one within the schema, we have this issue. Our options would appear to be: - Do not permit such overrides. Design your models so that when it is desired to configure the same underlying operational state from multiple sources, it is through disjoint pieces of the model. An example would be for static routes to have a local-config mechanism and a completely separate ephemeral config model. This is the "easy" option. - Permit such overrides as long as the semantics are "clear". <ALEX> Yes, and the third option is the one in which you treat the datastores as separate entities in which references and dependencies as well as what constititutes the "golden copy" are explicitly exposed instead of being implicitly manged. Of course there are some constraints that need to be imposed on the model and what's allowed, such as not allowing a "local" object to be contained in and existentially depend on a "remote" object owned by a different datastore, due to the referential integrity issues that you point out. I would consider such constraints features, not limitations of the model. </ALEX> ... _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
