Hi Alex, Tom, Joel, et al. (top-posting) In the initial I2RS framework, we had the ideal of different data lifetimes as well as being able to have written state be permanent or ephemeral. The I2RS WG consensus was very clear that I2RS should only support ephemeral state and that is reflected in the architecture.
In the architecture, the configuration interacts with an I2RS Agent based on the relative priorities of the configuration and the I2RS client that wrote the state. An easy example - certainly what I'd assume to occur while gaining initial experience - is that the configuration always overrules I2RS Clients. If state is written by an I2RS client that depends on configuration and the configuration is deleted, then the I2RS client's state is also deleted and the client is notified. This is what would happen if it were another I2RS client that caused the change as well. I'm quite happy to see focused discussion on how we can actually use YANG for I2RS in the nitty-gritty details, but I am concerned that what we end up with is what I2RS is rather than a different animal. no-hats Alia On Wed, Oct 1, 2014 at 12:03 AM, Alexander Clemm (alex) <[email protected]> wrote: > Hi, one reply inline, <Alex>. > --- Alex > > -----Original Message----- > From: i2rs [mailto:[email protected]] On Behalf Of Jeffrey Haas > Sent: Monday, September 29, 2014 8:03 AM > To: Joel M. Halpern > Cc: [email protected]; 'Martin Bjorklund'; Eric Voit (evoit); Alexander Clemm > (alex); 'Andy Bierman'; 'Jeffrey Haas'; Susan Hares > Subject: Re: [i2rs] Two thoughts on an ephemeral data store > > On Sun, Sep 28, 2014 at 12:20:36AM -0400, Joel M. Halpern wrote: > > If I am reading you correctly, you are saying taht if an I2RS client > > is manipulating data that is stored in the underlying golden store, > > you want that golden store changed. > > I think that won't work for the requirements. As far as I can tell > > from your proposal, this would result in I2RS changes being stored > > when someone on the CLI does a commit. Which is not what is wanted. > > I agree with you, Joel. This doesn't match the semantics the I2RS WG > wanted. > > <ALEX> Your understanding is correct. These are the semantics of the > proposal. When the data in the golden store is changed, it is changed. It > is the authoritative copy; the changes will be visible in the other > datastores that reference it / mount it and there is no question which > values/settings are in effect. It's not "panes of glass" semantics where > which setting is in effect is computed from overlays of the same object > instance across different datastores. The semantics are simpler. If you > want to have settings that go into effect when something in another > datastore is deleted etc, you can still achieve that, but you will need to > reflect that explicitly in the model. Whether that's a tradeoff you're > willing to make is I guess subject for discussion. > </ALEX> > > > > Conversely, a read-through model would seem to work. Objects which > > have been created / modified in the I2RS store, when read from the > > I2RS store have their I2RS value. If you attempt to read or reference > > a value that has not been modified in I2RS, you read-through to the > > underlying data store, and see its value. > > Hopefully my most recent example shows this. > > -- Jeff > > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs > > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs >
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
