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.

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.

Thanks,
 Phil

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to