Re: [netmod] Action and RPC statements
Lou Berger <lberger@labn.net> Mon, 06 November 2017 15:03 UTC
Return-Path: <lberger@labn.net>
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 2E67313FC2F for <netmod@ietfa.amsl.com>; Mon, 6 Nov 2017 07:03:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
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 KOQS3MusQpeZ for <netmod@ietfa.amsl.com>; Mon, 6 Nov 2017 07:03:41 -0800 (PST)
Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B35F13FC2C for <netmod@ietf.org>; Mon, 6 Nov 2017 07:03:38 -0800 (PST)
Received: from CMOut01 (unknown [10.0.90.82]) by gproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id 9E9C11E0B99 for <netmod@ietf.org>; Mon, 6 Nov 2017 08:03:37 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id Wf3Z1w00a2SSUrH01f3c5d; Mon, 06 Nov 2017 08:03:37 -0700
X-Authority-Analysis: v=2.2 cv=K4VSJ2eI c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=sC3jslCIGhcA:10 a=u07AKapRAAAA:8 a=wU2YTnxGAAAA:8 a=xskcdSivAAAA:8 a=OUXY8nFuAAAA:8 a=48vgC7mUAAAA:8 a=FIGp5oMs-BBKaa9VkXwA:9 a=-MjPFmNV3SJqGFfT:21 a=CjuIK1q_8ugA:10 a=SkebfZ6J2Mmvk2rLHZle:22 a=Yz9wTY_ffGCQnEDHKrcv:22 a=B8SJYIqRPU5_XtF5Z38x:22 a=cAcMbU7R10T-QSRYIcO_:22 a=w1C3t2QeGrPiZgrLijVG:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject: References:In-Reply-To:Message-ID:Date:CC:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=SWS9BNrjKcOMiXg4A4vvIj9EGSoF5/3/PBhDb5wuX2w=; b=o7adLTklu8E1YeaH/UVswaoK7W aryBLQ6iDgx89u22xK7HHbtjMHIcGMQC5W2b7VrljQ5StMXo2BCuk3zYX6WYflBF6g/3YzAgE8GdX 627TWHE1PCDSvmCgIGXp9rKI6;
Received: from [172.58.185.143] (port=19148 helo=[IPV6:2607:fb90:651f:7cb3:0:45:9f72:9f01]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from <lberger@labn.net>) id 1eBiw0-000Js5-W2; Mon, 06 Nov 2017 08:03:33 -0700
From: Lou Berger <lberger@labn.net>
To: Martin Bjorklund <mbj@tail-f.com>
CC: andy@yumaworks.com, netmod@ietf.org
Date: Mon, 06 Nov 2017 10:03:30 -0500
Message-ID: <15f91db9dd0.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
In-Reply-To: <20171106.154913.1683303692062360930.mbj@tail-f.com>
References: <CABCOCHS+g45H7P8nZ7tUQeW5Q=xXQRm7kQJWwsfG8PrR-DERSQ@mail.gmail.com> <20171106.141924.996087392255055625.mbj@tail-f.com> <15f9188b728.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20171106.154913.1683303692062360930.mbj@tail-f.com>
User-Agent: AquaMail/1.11.0-568 (build: 101100004)
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="us-ascii"
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 172.58.185.143
X-Exim-ID: 1eBiw0-000Js5-W2
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: ([IPV6:2607:fb90:651f:7cb3:0:45:9f72:9f01]) [172.58.185.143]:19148
X-Source-Auth: lberger@labn.net
X-Email-Count: 1
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/a4U3lI3bBA9OW1rY8fAJh70N0WQ>
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 15:03:44 -0000
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 <mbj@tail-f.com> wrote: > 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