Juergen, On Wed, Jun 01, 2016 at 11:19:53AM +0200, Juergen Schoenwaelder wrote: > On Tue, May 31, 2016 at 04:27:51PM -0400, Susan Hares wrote: > > How does ephemeral sitting next to the <applied> data store provide > > the ability to augment configuration with ephemeral configuration or > > operational state with ephemeral operational state? > > At the schema level, you will augment the schema tree. If the current > separation of /foo and /foo-state would go away, this will likely get > simpler (but this is orthogonal to the question how an <ephemeral> > datastore conceptually interacts with the other datastores). > > At the data tree level, there is a magic merging (+) function involved > that takes configuration data from a configuration datastore and data > from an ephemeral data store and produces the resulting operational > state. The idea was to not further detail how this is achieved and > instead treat an ephemeral datastore pretty much like any other > control plane interface interacting with <operational state>.
While such a solution-space seems mostly right, I had been under the impression that the interactions necessary for validation meant that ephemeral needed to move up closer to the top of your diagram. Note that I'm not saying I2RS requires validation, however the lack of validation has been a contentious point in prior discussions. To confirm my understanding, ephemeral configuration state in the model you're proposing above is treated as operational state (the output of the netconf <get> operation for config true elements)? -- Jeff _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
