On Fri, Oct 09, 2015 at 04:13:03PM -0400, Susan Hares wrote: > The 10/7/2015 interim discussed the ephemeral portion of the protocol > > > > 1) Ephemeral state is not unique to zI2RS > > 2) The ephemeral datastore is a datastore holds > > configuration that is intended to not survive a reboot. >
Configuration as YANG config true or a subset thereof? > 3) The ephemeral datastore is never locked. > > 4) I2RS is using a 2 panes of glass mechanisms > > Pane 1: normal configuration > > Pane 2: ephemeral state > > > > The I2RS agent and configuration software on > > the node must handle this complexity. So is there one ephemeral datastore or are there multiple? Some slides say one per client, others seem to indicate one for all clients. > > 5) The key word "ephemeral" can be used to identify > > Identities which are ephemeral in data models. > > Does anyone have any concerns with adding this to > Yang? Identities? I assume you mean schema nodes, do you? Adding by defining an YANG extension such as i2rs:ephemeral true? How does such an i2rs:ephemeral true interplay with config true/false? What about contexts for must/when expressions? Or is the idea to settle on RESTCONF and to work with YANG patch? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
