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