Re: [netmod] XPath questions about revised datastores
Martin Bjorklund <mbj@tail-f.com> Thu, 15 June 2017 19:03 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 A13CA127078 for <netmod@ietfa.amsl.com>; Thu, 15 Jun 2017 12:03:28 -0700 (PDT)
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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 FZW7thumyAg2 for <netmod@ietfa.amsl.com>; Thu, 15 Jun 2017 12:03:26 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id CD00D127866 for <netmod@ietf.org>; Thu, 15 Jun 2017 12:03:25 -0700 (PDT)
Received: from localhost (h-13-81.A165.priv.bahnhof.se [155.4.13.81]) by mail.tail-f.com (Postfix) with ESMTPSA id 793F01AE0352; Thu, 15 Jun 2017 21:03:24 +0200 (CEST)
Date: Thu, 15 Jun 2017 21:03:24 +0200
Message-Id: <20170615.210324.866114685910056800.mbj@tail-f.com>
To: andy@yumaworks.com
Cc: j.schoenwaelder@jacobs-university.de, netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <CABCOCHTqQ-fi7cr9ZPmjbxCtTAe+X+=yLyWOotwdyfL5qL2pyg@mail.gmail.com>
References: <CABCOCHTN8x8=h4McG5Rf+m+XjO6YmwUaR-JfwhecL=CdbEGfag@mail.gmail.com> <20170615.180850.1310683464764148583.mbj@tail-f.com> <CABCOCHTqQ-fi7cr9ZPmjbxCtTAe+X+=yLyWOotwdyfL5qL2pyg@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/nNsyRVb0Ft9fze2PMIXTX45LlzQ>
Subject: Re: [netmod] XPath questions about revised datastores
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: Thu, 15 Jun 2017 19:03:29 -0000
Andy Bierman <andy@yumaworks.com> wrote: > On Thu, Jun 15, 2017 at 9:08 AM, Martin Bjorklund <mbj@tail-f.com> wrote: > > > Andy Bierman <andy@yumaworks.com> wrote: > > > On Thu, Jun 15, 2017 at 8:41 AM, Martin Bjorklund <mbj@tail-f.com> > > wrote: > > > > > > > Andy Bierman <andy@yumaworks.com> wrote: > > > > > On Thu, Jun 15, 2017 at 5:27 AM, Juergen Schoenwaelder < > > > > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > > > > > > > Andy, > > > > > > > > > > > > section 5.1 of draft-ietf-netmod-revised-datastores-02.txt > > discusses > > > > > > the XPath context. An xpath expression in a config-false container > > > > > > will resolve to the operational state. > > > > > > > > > > > > > > > > > > > > > > So the usual method of "augment when" is broken: > > > > > > > > > > WRONG: Will evaluate when-stmt against config > > > > > > > > > > augment /foo { > > > > > when "some condition"; > > > > > container stats { } > > > > > } > > > > > > > > Do you mean that stats is a config true container? And presumably in > > > > the stats containter you have config false leafs? > > > > > > > > > > > no -- stats is a config false container > > > > Ok. Well, then this is also ok. The stats container will exist if > > "some condition" is true in the operational state datastore. > > > > > > I think this works as expected. In a conventional datastore > > > > (e.g. running), the stats container exists if "some condition" is true > > > > in that datastore. > > > > > > > > > > > > > no -- in my example the desire is to augment the operational state based > > on > > > the > > > operational value of a config=true leaf > > > > Yes, that will happen in both cases. > > > > > > In the operational state, the stats container exists if "some > > > > condition" is true in that the operational state datastore. > > > > > > > > > Correct: Will evaluate when-stmt against operational: > > > > > > > > > > augment /foo { > > > > > container stats { > > > > > config false; > > > > > when "different condition"; > > > > > } > > > > > } > > > > > > > > In this case the stats container will never exist in any conventional > > > > datastore, since it is config false. > > > > > > > > In the operational state, the stats container exists if "different > > > > condition" is true in that the operational state datastore. > > > > > > > > > Forcing the augmenting node to be the XPath context node impacts the > > > > > possible expressions. > > > > > I think the RD draft should make all this clear. > > > > > > > > This is not different from how it works today wrt candidate vs running > > > > for example. > > > > > > > > > > no -- the datastore doesn't change based on the context node config-stmt > > > value > > > for candidate and running. > > > > The datastore doesn't change with NMDA either - an XPath expression is > > always evaluated in a particular datastore, just like before. There > > is no mechanism to read data from a different datastore in the XPath > > expressions. > > > > > > > > But in the first example the when-stmt is evaluated in the context of /foo > which is config=true. > Doesn't that mean the configuration values will be used? No, the values of these nodes in the operational state datastore will be used (these are the "applied configuration" values). > The config=false nodes added if the when-stmt is true are not the context > nodes in the first form. > Authors need to be careful to put the when-stmt in a config=false context > node in order > to evaluate in the operational datastore. No, see above. /martin > > > > > /martin > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > /js > > > > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > On Wed, Jun 14, 2017 at 11:07:35AM -0700, Andy Bierman wrote: > > > > > > > Hi, > > > > > > > > > > > > > > I don't know if getting rid of /foo-state is such a great idea, > > > > > > > especially wrt/ counters and other objects that are not > > > > > > > related to intended config vs. applied config. > > > > > > > > > > > > > > Q1) how does a client know the difference between an > > auto-generated > > > > > > > foo-state.yang and a real foo-state.yang? Seem like a YANG > > extension > > > > > > > is needed to flag an auto-generated foo-state.yang > > > > > > > > > > > > > > Q2) How does XPath reference an operational node if the > > /foo-state > > > > > > > subtree has been moved to the /foo config subtree? > > > > > > > > > > > > > > module foo { > > > > > > > > > > > > > > container foo { > > > > > > > leaf stat-collect-type { > > > > > > > type enumeration { > > > > > > > enum stat-set1; > > > > > > > enum stat-set2; > > > > > > > } > > > > > > > } > > > > > > > } > > > > > > > > > > > > > > container foo-state { > > > > > > > config false; > > > > > > > leaf stat-collect-type { > > > > > > > type enumeration { > > > > > > > enum stat-set1; > > > > > > > enum stat-set2; > > > > > > > } > > > > > > > } > > > > > > > container stat-set1 { > > > > > > > when "../stat-collect-type = 'stat-set1'"; > > > > > > > ... > > > > > > > } > > > > > > > container stat-set2 { > > > > > > > when "../stat-collect-type = 'stat-set2'"; > > > > > > > ... > > > > > > > } > > > > > > > } > > > > > > > } > > > > > > > > > > > > > > In this example, there is a request stat collect type > > > > > > /foo/stat-collect-type > > > > > > > and there is an operational value (what the server/device is > > capable > > > > > > > of collecting -- e.g. client requests stat-set2 knowing the > > server > > > > > > > will change it to stat-set1 if set2 not supported) > > > > > > > > > > > > > > So if /foo-state is folded into /foo (because that is the intent > > -- > > > > to > > > > > > get > > > > > > > rid of this extra stat-collect-type leaf), then how do the > > when-stmts > > > > > > > get applied to the operational value instead of the configured > > value? > > > > > > > The same issue applies if the when-stmts are within an > > augment-stmt > > > > > > > > > > > > > > WANT: > > > > > > > > > > > > > > augment /foo-state { > > > > > > > when "stat-collect-type = 'stat-set1'"; > > > > > > > container stat-set1 { > > > > > > > ... > > > > > > > } > > > > > > > } > > > > > > > > > > > > > > RD Provides: > > > > > > > > > > > > > > augment /foo { > > > > > > > when "stat-collect-type = 'stat-set1'"; > > > > > > > container stat-set1 { > > > > > > > config false; > > > > > > > ... > > > > > > > } > > > > > > > } > > > > > > > > > > > > > > There is no way to use when-stmt to reference the operational > > value. > > > > > > > This is a rather common usage of the when-stmt, so it should not > > > > > > > be removed if RD is used. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > _______________________________________________ > > > > > > > netmod mailing list > > > > > > > netmod@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > > > > > > > > > > > -- > > > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > > Germany > > > > > > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> > > > > > > > > > > > >
- [netmod] XPath questions about revised datastores Andy Bierman
- Re: [netmod] XPath questions about revised datast… Juergen Schoenwaelder
- Re: [netmod] XPath questions about revised datast… Andy Bierman
- Re: [netmod] XPath questions about revised datast… Martin Bjorklund
- Re: [netmod] XPath questions about revised datast… Andy Bierman
- Re: [netmod] XPath questions about revised datast… Martin Bjorklund
- Re: [netmod] XPath questions about revised datast… Andy Bierman
- Re: [netmod] XPath questions about revised datast… Martin Bjorklund
- Re: [netmod] XPath questions about revised datast… Andy Bierman
- Re: [netmod] XPath questions about revised datast… Martin Bjorklund
- Re: [netmod] XPath questions about revised datast… Andy Bierman
- Re: [netmod] XPath questions about revised datast… Juergen Schoenwaelder
- Re: [netmod] XPath questions about revised datast… Phil Shafer
- Re: [netmod] XPath questions about revised datast… Andy Bierman
- Re: [netmod] XPath questions about revised datast… Juergen Schoenwaelder