Juergen, An older rev of the ephemeral state requirements covered part of this point. The suggestion in there was that <get> may require some ability to do filtering operations based on where the information was from:
https://tools.ietf.org/html/draft-ietf-i2rs-ephemeral-state-00 See "filter-ephemeral". I don't believe the I2RS working group has any particular opinion on what the mechanism looks like, but we are in agreement that some solution will be needed for this problem. -- Jeff On Wed, Jun 01, 2016 at 05:01:06PM +0200, Juergen Schoenwaelder wrote: > Oh, I see. The story line, however, is that <get> assumes it is > possible to merge operational state with <running> configuration > datastore content and this ultimately lead to the /foo and /foo-state > data model design pattern, which a number of people find cumbersome. > So the idea is to deprecate operations like <get> that assume > datastores can be merged because the models have been design to use > different branches. We then need a new operation that can be used to > retrieve state data and likely (perhaps as a feature) operations that > can retrieve data from multiple datastores (without assuming the > underlying data models avoid overlapping branches). Perhaps calling > the former <get-state> is misleading people, I can see that. > > /js > > On Wed, Jun 01, 2016 at 09:41:02AM -0400, Joel M. Halpern wrote: > > The deprecation of <get> and the addition of <get-state> lead me to conclude > > that you were moving to a paradigm of different RPCs for different data > > stores, rather than a paradigm of a datastore parameter for the RPC. > > > > I may well have over-generalized from what I read. > > Yours, > > Joel > > _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
