Re: [netmod] Action and RPC statements
Martin Bjorklund <mbj@tail-f.com> Mon, 06 November 2017 14:49 UTC
Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F73E13FC2C for <netmod@ietfa.amsl.com>; Mon, 6 Nov 2017 06:49:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id br1f7OWFZU-1 for <netmod@ietfa.amsl.com>; Mon, 6 Nov 2017 06:49:12 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 07E2E13F698 for <netmod@ietf.org>; Mon, 6 Nov 2017 06:49:12 -0800 (PST)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 0783A1AE030A; Mon, 6 Nov 2017 15:49:09 +0100 (CET)
Date: Mon, 06 Nov 2017 15:49:13 +0100
Message-Id: <20171106.154913.1683303692062360930.mbj@tail-f.com>
To: lberger@labn.net
Cc: andy@yumaworks.com, netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <15f9188b728.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
References: <CABCOCHS+g45H7P8nZ7tUQeW5Q=xXQRm7kQJWwsfG8PrR-DERSQ@mail.gmail.com> <20171106.141924.996087392255055625.mbj@tail-f.com> <15f9188b728.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/hZdH77hQBnKZXkPrawpEEn_hixw>
Subject: Re: [netmod] Action and RPC statements
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Nov 2017 14:49:14 -0000
Lou Berger <lberger@labn.net> 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 <mbj@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 <andy@yumaworks.com> wrote: > >> On Thu, Nov 2, 2017 at 2:16 PM, Phil Shafer <phil@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 <phil@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:phil@juniper.net" target=3D"_blank">phil@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 > > > >
- [netmod] augment YANG 1.0 with YANG 1.1 OK? Andy Bierman
- Re: [netmod] augment YANG 1.0 with YANG 1.1 OK? Martin Bjorklund
- Re: [netmod] augment YANG 1.0 with YANG 1.1 OK? Andy Bierman
- Re: [netmod] augment YANG 1.0 with YANG 1.1 OK? Juergen Schoenwaelder
- Re: [netmod] augment YANG 1.0 with YANG 1.1 OK? Andy Bierman
- Re: [netmod] augment YANG 1.0 with YANG 1.1 OK? Andy Bierman
- Re: [netmod] augment YANG 1.0 with YANG 1.1 OK? Juergen Schoenwaelder
- Re: [netmod] augment YANG 1.0 with YANG 1.1 OK? Juergen Schoenwaelder
- Re: [netmod] augment YANG 1.0 with YANG 1.1 OK? Andy Bierman
- Re: [netmod] augment YANG 1.0 with YANG 1.1 OK? Robert Wilton
- Re: [netmod] augment YANG 1.0 with YANG 1.1 OK? Andy Bierman
- Re: [netmod] augment YANG 1.0 with YANG 1.1 OK? Juergen Schoenwaelder
- Re: [netmod] augment YANG 1.0 with YANG 1.1 OK? Andy Bierman
- Re: [netmod] augment YANG 1.0 with YANG 1.1 OK? Juergen Schoenwaelder
- Re: [netmod] augment YANG 1.0 with YANG 1.1 OK? Andy Bierman
- Re: [netmod] augment YANG 1.0 with YANG 1.1 OK? Robert Wilton
- Re: [netmod] augment YANG 1.0 with YANG 1.1 OK? Martin Bjorklund
- Re: [netmod] augment YANG 1.0 with YANG 1.1 OK? Andy Bierman
- Re: [netmod] augment YANG 1.0 with YANG 1.1 OK? Andy Bierman
- Re: [netmod] augment YANG 1.0 with YANG 1.1 OK? Martin Bjorklund
- Re: [netmod] augment YANG 1.0 with YANG 1.1 OK? Andy Bierman
- Re: [netmod] augment YANG 1.0 with YANG 1.1 OK? Andy Bierman
- Re: [netmod] augment YANG 1.0 with YANG 1.1 OK? Martin Bjorklund
- [netmod] Action and RPC statements [was Re: augme… Robert Wilton
- Re: [netmod] augment YANG 1.0 with YANG 1.1 OK? Robert Wilton
- Re: [netmod] Action and RPC statements [was Re: a… Randy Presuhn
- Re: [netmod] Action and RPC statements [was Re: a… Andy Bierman
- Re: [netmod] Action and RPC statements [was Re: a… Randy Presuhn
- Re: [netmod] Action and RPC statements Martin Bjorklund
- Re: [netmod] Action and RPC statements Robert Wilton
- Re: [netmod] Action and RPC statements Juergen Schoenwaelder
- Re: [netmod] Action and RPC statements Kent Watsen
- Re: [netmod] Action and RPC statements Robert Wilton
- Re: [netmod] Action and RPC statements Juergen Schoenwaelder
- Re: [netmod] Action and RPC statements Robert Wilton
- Re: [netmod] Action and RPC statements Andy Bierman
- Re: [netmod] Action and RPC statements Randy Presuhn
- Re: [netmod] Action and RPC statements Andy Bierman
- Re: [netmod] Action and RPC statements Alexander Clemm
- Re: [netmod] Action and RPC statements Phil Shafer
- Re: [netmod] Action and RPC statements Robert Wilton
- Re: [netmod] Action and RPC statements Robert Wilton
- Re: [netmod] Action and RPC statements Juergen Schoenwaelder
- Re: [netmod] Action and RPC statements Andy Bierman
- Re: [netmod] Action and RPC statements Alexander Clemm
- Re: [netmod] Action and RPC statements Alexander Clemm
- Re: [netmod] Action and RPC statements Juergen Schoenwaelder
- Re: [netmod] Action and RPC statements Phil Shafer
- Re: [netmod] Action and RPC statements Andy Bierman
- Re: [netmod] Action and RPC statements Martin Bjorklund
- Re: [netmod] Action and RPC statements Lou Berger
- Re: [netmod] Action and RPC statements Juergen Schoenwaelder
- Re: [netmod] Action and RPC statements Martin Bjorklund
- Re: [netmod] Action and RPC statements Lou Berger
- Re: [netmod] Action and RPC statements Robert Wilton
- Re: [netmod] Action and RPC statements Lou Berger
- Re: [netmod] Action and RPC statements Robert Wilton
- Re: [netmod] Action and RPC statements Lou Berger
- Re: [netmod] Action and RPC statements Juergen Schoenwaelder
- [netmod] Reset tags RPC [was Re: Action and RPC s… Robert Wilton
- Re: [netmod] Action and RPC statements Lou Berger
- Re: [netmod] Action and RPC statements Andy Bierman
- Re: [netmod] Action and RPC statements Juergen Schoenwaelder
- Re: [netmod] Action and RPC statements Robert Wilton
- Re: [netmod] Action and RPC statements Lou Berger
- Re: [netmod] Action and RPC statements Robert Wilton
- Re: [netmod] Action and RPC statements Lou Berger
- Re: [netmod] Action and RPC statements t.petch