Re: [netmod] Action and RPC statements
Lou Berger <lberger@labn.net> Mon, 06 November 2017 13:33 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 4E7F413FC1D for <netmod@ietfa.amsl.com>; Mon, 6 Nov 2017 05:33:12 -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 hAdBW9hYCEDe for <netmod@ietfa.amsl.com>; Mon, 6 Nov 2017 05:33:05 -0800 (PST)
Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) (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 6071C13FB09 for <netmod@ietf.org>; Mon, 6 Nov 2017 05:33:05 -0800 (PST)
Received: from CMOut01 (unknown [10.0.90.82]) by gproxy10.mail.unifiedlayer.com (Postfix) with ESMTP id 258281404BA for <netmod@ietf.org>; Mon, 6 Nov 2017 06:33:04 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id WdZ01w00B2SSUrH01dZ3XV; Mon, 06 Nov 2017 06:33:04 -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=xskcdSivAAAA:8 a=OUXY8nFuAAAA:8 a=48vgC7mUAAAA:8 a=qjV_LLvqQDixxDVRnr0A:9 a=-MjPFmNV3SJqGFfT:21 a=CjuIK1q_8ugA:10 a=SkebfZ6J2Mmvk2rLHZle: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=h8lYsIEO2egpe6zVGJXJeYQZlCv1Y8cLqwJ2KAKbkcU=; b=ZX7qyHhOYSjxh0gHKqt6nKgE0O K4NuOwWhjRpyWhBNVjTa+m9e51CoJqGpmY5n2qWfsM2ydb68kcbIEBiVMwEGBXoh3yRfEI2qY9tnw AxT9Z1hHlQMIfeVmi3n8XFSpq;
Received: from [172.58.185.143] (port=64616 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 1eBhWN-004O66-Un; Mon, 06 Nov 2017 06:33:00 -0700
From: Lou Berger <lberger@labn.net>
To: Martin Bjorklund <mbj@tail-f.com>, andy@yumaworks.com
CC: netmod@ietf.org
Date: Mon, 06 Nov 2017 08:32:58 -0500
Message-ID: <15f9188b728.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
In-Reply-To: <20171106.141924.996087392255055625.mbj@tail-f.com>
References: <CABCOCHRkpPQ7Udcd7AZDTwYvEP3BOOv8ec6GOUOf2_QZsZApEA@mail.gmail.com> <201711022116.vA2LGTB3044617@idle.juniper.net> <CABCOCHS+g45H7P8nZ7tUQeW5Q=xXQRm7kQJWwsfG8PrR-DERSQ@mail.gmail.com> <20171106.141924.996087392255055625.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: 1eBhWN-004O66-Un
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: ([IPV6:2607:fb90:651f:7cb3:0:45:9f72:9f01]) [172.58.185.143]:64616
X-Source-Auth: lberger@labn.net
X-Email-Count: 6
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/rUUqfDJkGNSBehLUJyl4HSE1LGo>
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:33:12 -0000
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 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