On Sun, Oct 11, 2015 at 9:11 AM, Juergen Schoenwaelder < [email protected]> wrote:
> 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? > config=true nodes only. Some way is needed to specify I2RS conformance for a given YANG module, unless every persistent config leaf is expected to also be supported as ephemeral data. If not, a YANG "ephemeral-stmt" is probably needed, since config=true is insufficient to support I2RS conformance. > > 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. > > One ephemeral datastore. No client panes. That was to support caching, but the architecture forbids caching, so that was taken out. One ephemeral pane that overrides the running datastore > > > > 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? > I think a real keyword is needed not an extension. Otherwise YANG groupings cannot be utilized w/ statements that are refined in the uses-stmt to set the ephemeral flag. NETCONF has no edit ordering or ability to return a partial error. IMO only RESTCONF is needed. Proposals to improve NETCONF editing to support YANG Patch have already been made, and the WG had higher priorities. I don't see why 2 protocols are needed instead of 1. > > /js > > Andy > -- > 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 >
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
