Subject: [i2rs] ephemeral RPC?

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 31 May 2016 12:33:43 -0400

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

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 31 May 2016 16:23:54 -0400

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:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Tuesday, May 31, 2016 12:34 PM
To: [email-masked]
Subject: [i2rs] ephemeral RPC?

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
[email-masked]
https://www.ietf.org/mailman/listinfo/i2rs

---

From: Joel Halpern Direct <[email-masked]>
Date: Tue, 31 May 2016 16:27:17 -0400

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

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 31 May 2016 17:58:02 -0400

Sue,

Rather than saying "ephemeral RPC", I suspect you mean an RPC that has
impact on ephemeral configuration or operational state.

Arguably, if the RPC in question only manifests as operational state for
that case the idea of ephemeral configuration in yang may become moot.

-- Jeff

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 31 May 2016 18:17:09 -0400

Jeff: 

Yes, this could be another way to look at it. 

Sue 

-----Original Message-----
From: Jeffrey Haas [mailto:[email-masked]] 
Sent: Tuesday, May 31, 2016 5:58 PM
To: Susan Hares
Cc: 'Joel M. Halpern'; [email-masked]
Subject: Re: [i2rs] ephemeral RPC?

Sue,

-- Jeff

On Tue, May 31, 2016 at 04:23:54PM -0400, 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
> 
> 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.
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 1 Jun 2016 08:34:11 +0200

On Tue, May 31, 2016 at 04:27:17PM -0400, Joel Halpern Direct wrote:
> 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

-- 
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/>