On Sep 24, 2014:11:34 AM, at 11:34 AM, Jeffrey Haas <[email protected]> wrote:
> On Wed, Sep 24, 2014 at 07:35:47AM -0400, Thomas D. Nadeau wrote: >> On Sep 24, 2014:3:10 AM, at 3:10 AM, Juergen Schoenwaelder >> <[email protected]> wrote: > [...] >>> >>> +-----------------+ >>> | | >>> +--- (+) ---+ | >>> ^ ^ v >>> +---+ +---+ +---+ >>> | | | | | | >>> |(1)| | | | | >>> | | | | | | >>> +---+ +---+ +---+ >>> >>> NC config ephemeral operational >>> datastore datastore state >>> >>> (1) The complete NC config datastore is at certain synchronization >>> points made persistent >>> >>> (+) Priority resolution, priorities may be per datastore or per >>> user or per 'application' or even per data node >> >> These are precisely the qualities I and some others were thinking of >> when we started i2rs. The idea is quite simple, as you have said above and >> really needs not be complicated more. > > It has its own complications. > > Do we permit more than one ephemeral datastore? If so, this simplifies data > object priority when resolving the operational state. But this also > complicates operational state integrity when you have multiple cross I vote for keeping this simple for starters. Lets get an implementation or two of a single ephemeral data store. This avoids having multiple priorities too; its just 1. --Tom > references. > > -- Jeff >
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
