Hi,
Trying to summarize this issue.
The problem is which datastore is used to:
1a. evaluate action ancestor nodes
1b. evaluate action input/output parameter leafref,
instance-identifier, must, when
2. evaluate rpc input/output parameter leafref,
instance-identifier, must, when
(Note that the side effects of an action/rpc is not part of this
issue)
I think it would be very weird if 1a and 1b were treated differently,
so I just label them as 1 below.
Possible solutions:
A. Always use <operational> for 1 and 2.
(This is what the current nmda draft says).
B. Let the client specify the datastore for 1, and use <operational>
for 2.
(Note that this is trivial in RESTCONF (since the datastore is
part of the URL), but would require a new parameter for NETCONF
(or a new <action2>).
C. Let the client specify the datastore for 1 and 2.
This would require a new generic parameter for how RPCs are
invoked in both NETCONF and RESTCONF.
D. Like B, but let the description of the "rpc" statement optionally
override this.
I prefer B and then D.
/martin
Andy Bierman <[email protected]> wrote:
> On Thu, Nov 2, 2017 at 2:16 PM, Phil Shafer <[email protected]> wrote:
>
> > 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.
> >
> >
> Totally agree guessing is bad.
> Did you see the <action2> proposal in a previous email?
> That is exactly what I proposed, except I do not want to
> overload <action> so the new template would be a different name.
>
> I realize the expanded name of the datastore element prevents it from
> being confused with top-level YANG nodes, but the conformance
> is more clear with a new name.
>
>
>
>
> > Thanks,
> > Phil
> >
>
> Andy
>
>
> >
> >
> > 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
