Martin: I agree [4] and [5] provide possible architectures that ephemeral could fit into as part of choice [B].
Sue -----Original Message----- From: i2rs [mailto:[email protected]] On Behalf Of Martin Bjorklund Sent: Wednesday, June 08, 2016 1:40 PM To: [email protected] Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: [i2rs] [Rtg-yang-coord] Fwd: [netmod] Opstate solutions discussions: update and request for WG input Hi Sue, "Susan Hares" <[email protected]> wrote: > In [4], the author states: > > "o The model foresees ephemeral datastores that are by definition not > part of the persistent configuration of a device. These ephemeral > datastores are considered to interact with the rest of the system > like any other control-plane mechanisms (e.g., routing protocols, > discovery protocols). [XXX Note that this is different from what > is described in some of the I2RS documents. XXX]" [...] > Therefore, the result of I2RS WG spending 2 years writing requirements > for the ephemeral data store that both option 2 documents "do not > match" the I2RS ephemeral requirements set. [4] lumps ephemeral with > operational state. I don't think this last sentence is correct. Admittedly, the details about ephemeral in [4] are not worked out (by design). But the idea was not to "lump ephemeral and operational state". The idea was rather that the content of ephemeral datastore(s) would interact with the applied config to produce the resulting operational state. If the WG agrees that B is the right way to go, we'll need to work out all the details about how the ephemeral datastore(s) work. The main point is that [4] (and [5]) provides an architecture into which ephemeral datastores can fit. /martin _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
