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:[email protected]] On Behalf Of Joel Halpern Direct
Sent: Tuesday, May 31, 2016 4:27 PM
To: Susan Hares; [email protected]
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:[email protected]] On Behalf Of Joel M. Halpern
Sent: Tuesday, May 31, 2016 12:34 PM
To: [email protected]
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
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
