Re: [netmod] Action and RPC statements

[Lou Berger <[e-mail]>]

On November 6, 2017 10:21:19 AM Robert Wilton <[e-mail]> wrote:

> Hi Lou,
>
> All of proposed solutions (A through D) allow the action or the RPC to
> perform whatever behaviour that it wants.
>
> This issue is only about which datastore is used to evaluate and check
> that the parameters for the action/rpc are valid.  E.g. if the
> parameters use when, must, leaf-ref, or instance-identifier.
>
> So, to take option "A" for example: "A.  Always use <operational> for 1
> and 2."
>
> One can still define a RPC that modifies another datastore ("edit-data"
> in the NETCONF NMDA  draft is one such example).  But to check whether
> the edit-data request can be performed, any input parameter constraints
> would be evaluated against <operational>.  However, given that the input
> parameters to edit-data don't contain any when, must, leaf-ref, or
> instance-identifier statements then it makes absolutely no functional
> difference which the datastore the parameters are evaluated in, since
> the result will always be the same regardless.  But perhaps it just
> feels a little odd that they are conceptually evaluated against
> operational, even though the RPC only even affects one of the editable
> configurable datastores.
>


Yes, which is why I've been assuming we'd end up with c.

Thanks,

Lou
> Thanks,
> Rob
>
>
> On 06/11/2017 15:03, Lou Berger wrote:
>> So i guess this comes down to D listed below.  While i was expecting
>> C, i think D is probably workable. How would you envision the override
>> would be expressed?
>>
>> Lou
>>
>>
>> On November 6, 2017 9:49:49 AM Martin Bjorklund <[e-mail]> wrote:
>>
>>> Lou Berger <[e-mail]> wrote:
>>>> Martin,
>>>>
>>>> If I have an RPC or action that changes state, how would the
>>>> persistence of that state be indicated with an NMBA data stores.  I
>>>> expected it to be related to the data store, but I read your mail
>>>> below as saying otherwise
>>>
>>> The side effects of executing an rpc or action is described in the
>>> rpc/action itself.  This is not a problem.  For example, see the
>>> definition of <edit-config>.  So with NMDA, this continues to work
>>> like before.
>>>
>>>
>>> /martin
>>>
>>>
>>>
>>>
>>>> Thanks,
>>>> Lou
>>>>
>>>>
>>>> On November 6, 2017 8:20:12 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.
>>>> >
>>>> >
>>>> > /martin
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > 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--
>>>> >> >
>>>> >
>>>> > _______________________________________________
>>>> > netmod mailing list
>>>> > [e-mail]
>>>> > https://www.ietf.org/mailman/listinfo/netmod
>>>> >
>>>>
>>>>
>>>
>>
>>
>> _______________________________________________
>> netmod mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netmod
>> .
>>
>
>