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
