On 01/11/2017 06:36, Phil Shafer wrote:
Robert Wilton writes:
ii) However, as far as I can see, it doesn't make sense for an action to
directly affect the contents of any configuration datastore, that should
be done via a purpose built rpc (like edit-config).
An example action would be to retrieve the fingerprint of an ssh
key. I might want to get the fingerprint of a key in <candidate>
before I commit it.
Or I could have an action that sets the SNMPv3 auth key to a random
value, and I want to invoke that action against <candidate>.
Seems like <startup> might also be an interesting place to target
actions, but I can't think of a good example.
There are always scenarios where something is useful, and the problem
with ruling it out is that it becomes needed at some later point.
We've a habit of ruling out things and later wishing we had them.
Yes, I have this concern.
Is the easy fix to just put a datastore leaf under rpc/action and
have it default to operational? Any specific RPC can define its
own datastore leaf of hard-code the database in the description
(explicitly or implicitly <operational>), but the <action> RPC only
gets this if we make a new parameter for it.
I think that an action/rpc statement should indicate in the schema where
its input/output arguments are resolved against. I.e. "configuration",
"state", or "client-provided". This would be specified by a new
optional "resolve-to" YANG sub-statement to action/rpc, that defaults to
"state" if not specified.
(i) Actions/rpcs that "resolve-to state" would resolve against
<operational> (the default behaviour).
(ii) Actions/rpcs that "resolve-to configuration" would probably resolve
against <intended>.
(iii) Actions/rpcs that "resolve-to client-provided" would require that
an explicit datastore be specified as an input parameter to the action/rpc.
Actions of type "resolve-to client-provided" would be required to be
invoked with a new <datastore-action> RPC that has a new target
datastore input parameter.
RPCs of type "resolve-to client-provided" would be required to have an
input parameter named "datastore" that is a leafref to a datastore.
Finally, I would propose that we defer defining the new "resolved-to"
YANG statement and <datastore-action> RPC to YANG/NETCONF/RESTCONF 2.0,
so that for the moment actions/rpcs always resolve against <operational>
because that will be the default behaviour today, but with the
understanding that this could be extended in future.
Thanks,
Rob
Thanks,
Phil
.
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
