Re: [netmod] Action and RPC statements

[Robert Wilton <[e-mail]>]

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