Thanks,
Lou
On November 6, 2017 8:20:12 AM Martin Bjorklund <m...@tail-f.com>
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 <a...@yumaworks.com> wrote:
>> On Thu, Nov 2, 2017 at 2:16 PM, Phil Shafer <p...@juniper.net>
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 <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
>> > >>
>> > >
>> > >--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:p...@juniper.net"
target=3D"_blank">p...@juniper.net</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
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
