Re: [netmod] Action and RPC statements

[Andy Bierman <[e-mail]>]

On Mon, Nov 6, 2017 at 5:19 AM, Martin Bjorklund <[e-mail]> wrote:

> 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.
>
>
>

I prefer (A).

I do not see how this is transparent to non-NMDA clients that use actions
and/or rpcs.
The evaluation of config=true nodes change from <running> to <operational>.
This is a significant change that can break non-NMDA clients.

A non-NMDA client thinks the server is performing XPath evaluation according
to RFC 7950, sec. 6.4.1.


   o  If the XPath expression is defined in a substatement to an "input"
      statement in an "rpc" or "action" statement, the accessible tree
      is the RPC or action operation instance, all state data in the
      server, and the running configuration datastore.  The root node
      has top-level data nodes in all modules as children.
      Additionally, for an RPC, the root node also has the node
      representing the RPC operation being defined as a child.  The node
      representing the operation being defined has the operation's input
      parameters as children.

   o  If the XPath expression is defined in a substatement to an
      "output" statement in an "rpc" or "action" statement, the
      accessible tree is the RPC or action operation instance, all state
      data in the server, and the running configuration datastore.  The
      root node has top-level data nodes in all modules as children.
      Additionally, for an RPC, the root node also has the node
      representing the RPC operation being defined as a child.  The node
      representing the operation being defined has the operation's
      output parameters as children.



> /martin
>
>
>

Andy



>
>
> Andy Bierman <[e-mail]> wrote:
> > On Thu, Nov 2, 2017 at 2:16 PM, Phil Shafer <[e-mail]> 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 <[e-mail]>
> 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&lt;action&gt;=
> > > ></div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0&lt;top&gt;</div><div>=C2=A0
> > > =C2=A0 =
> > > >=C2=A0 =C2=A0 =C2=A0 &lt;list1&gt;</div><div>=C2=A0 =C2=A0 =C2=A0
> =C2=A0 =
> > > >=C2=A0 =C2=A0 =C2=A0&lt;key&gt;10&lt;/key&gt;</div><div>=C2=A0 =C2=A0
> > > =C2=
> > > >=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&lt;do-test&gt;</div><div>=C2=A0
> =C2=A0
> > > =C2=
> > > >=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &lt;datastore&gt;candidate&lt;
> > > /datas=
> > > >tore&gt;</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
> > > =C2=A0&lt;/do-=
> > > >test&gt;</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
> > > &lt;/list1&gt;</div><=
> > > >div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 &lt;/top&gt;</div><div>=C2=A0 =C2=A0
> > > &lt;/a=
> > > >ction&gt;</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 &lt;do-test&gt; 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
> > > &lt;action&gt; =
> > > >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">&lt;<a
> > > href=3D"mailt=
> > > >o:[e-mail]" target=3D"_blank">[e-mail]</a>&gt;</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>
> > > >&gt;ii) However, as far as I can see, it doesn&#39;t make sense for an
> > > acti=
> > > >on to<br>
> > > >&gt;directly affect the contents of any configuration datastore, that
> > > shoul=
> > > >d<br>
> > > >&gt;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
> > > &lt;candidate&gt=
> > > >;<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 &lt;candidate&gt;.<br>
> > > ><br>
> > > >Seems like &lt;startup&gt; might also be an interesting place to
> > > target<br>
> > > >actions, but I can&#39;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&#39;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 &lt;operational&gt;), but the &lt;action&gt;
> > > 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--
> > >
>