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
> 
> On 6/1/16 2:34 AM, Juergen Schoenwaelder wrote:
> > On Tue, May 31, 2016 at 04:27:17PM -0400, Joel Halpern Direct wrote:
> > > 
> > > I think this may be following the paradigm in Juergen's draft, where
> > > accessing data <get...> and <set...> in different data stores uses 
> > > different
> > > RPCs?  Is that your intent?
> > > 
> > 
> > Joel,
> > 
> > which part of my I-D made you believe this is the case? Several core
> > NETCONF RPCs do take a datastore as an argument and this is just fine.
> > 
> > /js
> > 
> 
> _______________________________________________
> 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

Reply via email to