Re: [i2rs] ephemeral RPC?

I think this is an aspect of how we describe our requirements.

Our requirement is that we need RPC operations that manipulate (fetch, 
deposit, ...) ephemeral configuration information.

Whether those are new RPCs (ephemeral RPCs) or extensions to existing 
RPCs to indicate that the target is ephemeral information (data store), 
or some other mechanism, does not really matter to I2RS.
Juergen has indicated that some RPCs take data store as an argument. 
For any of those that are relevant to us, that RPC would seem to work 
unmodified with an ephemeral data store.

Yours,
Joel

On 6/1/16 7:17 AM, Susan Hares wrote:
> Joel:
>
> I am simply stating that
>
> I2RS RIB data model is an ephemeral-only data model, and uses an rpc to do
> rib add/delete, route add/delete, nexthop add/delete.   The rpc function
> must handle ephemeral datastore information.   The authors utilized the
> input capabilities of the rpc.  For a ephemeral-only model, it does not
> matter if the rpc is "ephemeral" or "non-ephemeral".   However, in a mixed
> model (see my example of the bgp-global-config changes), this constraints
> the functionality.
>
> The  <get-config> and <edit-config> is a separate function from rpc.  The
> protocol-strawman indicates these need to be changed to handle ephemeral
> datastore.
>
> Sue
>
>
> -----Original Message-----
> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel Halpern Direct
> Sent: Tuesday, May 31, 2016 4:27 PM
> To: Susan Hares; i2rs@ietf.org
> Subject: Re: [i2rs] ephemeral RPC?
>
> This may well be just me leaping to assumptions about function structuring.
> My apologies for raising a red herring if so.
>
> 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?
>
> Until I read Juergen's draft, it had never occurred to me that one would do
> it that way.  I had expected that one would perform an operation, and target
> it at a data store.
>
> But if indeed we use different RPCs for the different data stores, then I
> guess we do need versions of <get...> and <set...> that point at ephemeral.
>
> Yours,
> Joel
>
> On 5/31/16 4:23 PM, Susan Hares wrote:
>> Joel:
>>
>> I2RS data model is a ephemeral-only data model, and uses an rpc to do
>> rib add/delete, route add/delete, nexthop add/delete.  Therefore, we
>> need ephemeral rpc support.
>>
>>
>> Sue
>>
>> -----Original Message-----
>> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel M. Halpern
>> Sent: Tuesday, May 31, 2016 12:34 PM
>> To: i2rs@ietf.org
>> Subject: [i2rs] ephemeral RPC?
>>
>> We have agreed that non-ephemeral data must not reference ephemeral data.
>>
>> However, we have, up till now, not had the notion of ephemeral RPCs.
>> I see that the recent ephemeral requirements draft, as a side-effect
>> of improving clarity, creates the notion of an ephemeral RPC.
>>
>> What is an ephemeral RPC, and why do we have it?
>> We have been, up till now, assuming that we could use normal NetConf
>> RPCs to set and get the ephemeral information.
>>
>> Thank you,
>> Joel
>>
>> _______________________________________________
>> i2rs mailing list
>> i2rs@ietf.org
>> https://www.ietf.org/mailman/listinfo/i2rs
>>
>
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
>