Hi I've been trying to understand the models here. To me what we are describing is a general case of 2 entities trying to configure a switch.
Consider one operator or user for short. A user may be able to write to the running config datastore some subset. A user may copy that to the config datastore (save config). (If they do not the copy the running subset is ephemeral) Also: A user may write to a candidate config datastore some subset. A user may verify/activate the candidate config. A user may commit that candidate config (once running) (save config). (If they do not commit that config subset is ephemeral). Some devices do not support all config operations. Then consider two users trying both to config the same device. A user may be blocked from changing config items that are currently ephemeral. A user may be allowed to override the config items that are ephemeral. The override may be priority based where user A with higher priority can override user B but not the reverse. So if the user A is i2rs agent and the user B is an operator where the config items may allow priority per item, doesn't this cover the bases for what is needed? Cheers, Don > -----Original Message----- > From: i2rs [mailto:[email protected]] On Behalf Of Joel M. Halpern > Sent: Thursday, November 13, 2014 10:06 PM > To: Joe Clarke; [email protected] > Subject: Re: [i2rs] Point about writable running > > I agree Joe. The challenge with using any of the existing stores is that if > someone says "commit" they need to get the NetConf / RestConf normal > changes to that, but not the I2RS changes. > > Yours, > Joel > > On 11/13/14, 9:57 PM, Joe Clarke wrote: > > During today's meeting Dean made a comment that we could use writable > > running as a way to do ephemeral state. I have a concern about this. > > I know it may seem like an implementation detail, but I feel that most > > vendors (and operators) assume that things in the running datastore > > _could_ become persistent. > > > > That is, if I write to the running data store, and my human user sees > > these I2RS ephemeral state in the "show running-config" (or the like), > > they might think those are persistent. There is no indication that > > they are ephemeral. On top of that, some NMS systems that use > > screen-scraping for config archive might grab this ephemeral config > > and later restore state that should not be restored. > > > > I just wanted to bring this up as I would rather see more of the panes > > of glass approach rather than try to override an existing datastore > > for this kind of thing. Or maybe I misunderstood Dean's comment... > > > > Joe > > > > > > _______________________________________________ > > 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
