Hi,
So a server will be required to guess the correct datastore until it
finds the right one that matches the action instance?
<action>
<top>
<list1>
<key>10</key>
<do-test>
<datastore>candidate</datastore>
</do-test>
</list1>
</top>
</action>
The server will guess the datastore in some proprietary order and parse
instances of /top/ and /top/list1. Then it finds the <do-test> action
and parses the input to get to the datastore and find out the real datastore
to use. If the server guessed wrong, then it reparses the <action> against
the requested datastore. Hopefully the schema trees match up.
Will vendors do all the extra work required to support this sort of thing?
I doubt it.
Andy
On Tue, Oct 31, 2017 at 11:36 PM, Phil Shafer <p...@juniper.net> 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.
>
> 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
