Re: [netmod] Action and RPC statements
Martin Bjorklund <mbj@tail-f.com> Mon, 06 November 2017 13:19 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 6E4F413FC15 for <netmod@ietfa.amsl.com>; Mon, 6 Nov 2017 05:19:35 -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 knkV9n7KX_6L for <netmod@ietfa.amsl.com>; Mon, 6 Nov 2017 05:19:23 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7294113FC18 for <netmod@ietf.org>; Mon, 6 Nov 2017 05:19:23 -0800 (PST)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id E58321AE030A; Mon, 6 Nov 2017 14:19:20 +0100 (CET)
Date: Mon, 06 Nov 2017 14:19:24 +0100
Message-Id: <20171106.141924.996087392255055625.mbj@tail-f.com>
To: andy@yumaworks.com
Cc: phil@juniper.net, rwilton@cisco.com, kwatsen@juniper.net, netmod@ietf.org, randy_presuhn@alumni.stanford.edu
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <CABCOCHS+g45H7P8nZ7tUQeW5Q=xXQRm7kQJWwsfG8PrR-DERSQ@mail.gmail.com>
References: <CABCOCHRkpPQ7Udcd7AZDTwYvEP3BOOv8ec6GOUOf2_QZsZApEA@mail.gmail.com> <201711022116.vA2LGTB3044617@idle.juniper.net> <CABCOCHS+g45H7P8nZ7tUQeW5Q=xXQRm7kQJWwsfG8PrR-DERSQ@mail.gmail.com>
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/xIe9OAyaJVaqxu35cR2r_RQl_d4>
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 13:19:35 -0000
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] 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