Sorry, if I wasn't clear. I meant the <datastore> element would be directly under <action>, so the system knows where to start looking for data. Guessing is bad.
Thanks, Phil Andy Bierman writes: >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 <[email protected]> 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 >> > >--001a11411b0ad2d58d055cee96cb >Content-Type: text/html; charset="UTF-8" >Content-Transfer-Encoding: quoted-printable > ><div dir=3D"ltr">Hi,<div><br></div><div>So a server will be required to gue= >ss the correct datastore until it</div><div>finds the right one that matche= >s the action instance?</div><div><br></div><div>=C2=A0 =C2=A0<action>= ></div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0<top></div><div>=C2=A0 =C2=A0 = >=C2=A0 =C2=A0 =C2=A0 <list1></div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = >=C2=A0 =C2=A0 =C2=A0<key>10</key></div><div>=C2=A0 =C2=A0 =C2= >=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<do-test></div><div>=C2=A0 =C2=A0 =C2= >=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <datastore>candidate</datas= >tore></div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</do-= >test></div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </list1></div><= >div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </top></div><div>=C2=A0 =C2=A0 </a= >ction></div><div><br></div><div>The server will guess the datastore in s= >ome proprietary order and parse</div><div>instances of /top/ and /top/list1= >.=C2=A0 Then it finds the <do-test> action</div><div>and parses the i= >nput to get to the datastore and find out the real datastore</div><div>to u= >se.=C2=A0 If the server guessed wrong, then it reparses the <action> = >against</div><div>the requested datastore.=C2=A0 Hopefully the schema trees= > match up.</div><div><br></div><div>Will vendors do all the extra work requ= >ired to support this sort of thing?</div><div>I doubt it.</div><div><br></d= >iv><div><br></div><div>Andy</div><div><br></div><div><br></div><div><br></d= >iv><div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, O= >ct 31, 2017 at 11:36 PM, Phil Shafer <span dir=3D"ltr"><<a href=3D"mailt= >o:[email protected]" target=3D"_blank">[email protected]</a>></span> wrote= >:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le= >ft:1px #ccc solid;padding-left:1ex">Robert Wilton writes:<br> >>ii) However, as far as I can see, it doesn't make sense for an acti= >on to<br> >>directly affect the contents of any configuration datastore, that shoul= >d<br> >>be done via a purpose built rpc (like edit-config).<br> ><br> >An example action would be to retrieve the=C2=A0 fingerprint of an ssh<br> >key.=C2=A0 I might want to get the fingerprint of a key in <candidate>= >;<br> >before I commit it.<br> ><br> >Or I could have an action that sets the SNMPv3 auth key to a random<br> >value, and I want to invoke that action against <candidate>.<br> ><br> >Seems like <startup> might also be an interesting place to target<br> >actions, but I can't think of a good example.<br> ><br> >There are always scenarios where something is useful, and the problem<br> >with ruling it out is that it becomes needed at some later point.<br> >We've a habit of ruling out things and later wishing we had them.<br> ><br> >Is the easy fix to just put a datastore leaf under rpc/action and<br> >have it default to operational?=C2=A0 Any specific RPC can define its<br> >own datastore leaf of hard-code the database in the description<br> >(explicitly or implicitly <operational>), but the <action> RPC = >only<br> >gets this if we make a new parameter for it.<br> ><br> >Thanks,<br> >=C2=A0Phil<br> ></blockquote></div><br></div></div></div> > >--001a11411b0ad2d58d055cee96cb-- _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
