I believe this question is a general question, not particular to the way we realize ephemeral data. If I2RS injects state that is not consistent with config, then that state is likely ignored (at least this is what I understood when we touched this point last week).
Conceptually, with the shadowing approach, there is a 'merge' operation between the config datastore and ephemeral datastores. If the merge fails, then (as far as I recall last weeks discussion) it is expected that a notification is emitted to the I2RS system(s) involved. I2RS seems to seek for high transaction rates. And NETCONF people love to keep the config datastore self-consistent. If changes to the config datastore invalidate I2RS content, then this needs to be signalled to I2RS clients to take action. I think it would be wrong to reject an otherwise valid config change because it creates a conflict with ephemeral state the config system may not even be aware of. /js On Wed, Sep 24, 2014 at 11:30:51AM -0400, Jeffrey Haas wrote: > In the proposed overlay model, presume that we have ephemeral data from a > model that lives within an augmentation to a local config model. In other > words, the ephemeral nodes are children of the local config nodes. > > Presume, per discussion, that the local config lives in the "config" data > store and that the ephemeral config - the augmenting nodes above - live in > the ephemeral data store. > > If we delete the container in the local config that the epehemeral config is > augmenting, is there any expectation that such a deletion should carry > through to the ephemeral config? > > Per the netmod interim discussion, probably not. It's in a separate > datastore. But it does lead to integrity issues since we now have orphaned > state. In this particular example, permitting the deletion to carry through > to the ephemeral datastore at least provides one additional level of > consistency. > > ----- > > My second thought is would we ever want to provide filtering in the > conditional checks (must/when) in the ephemeral datastore based on the > underlying source of the data? Since local config would be shadowed into > the ephemeral datastore, do we want the ability to match on the source of > the node set under evaluation? > > -- Jeff > > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs -- 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
