Re: [netmod] XPath questions about revised datastores

Martin Bjorklund <mbj@tail-f.com> Thu, 15 June 2017 19:59 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 D8DE0127869 for <netmod@ietfa.amsl.com>; Thu, 15 Jun 2017 12:59:08 -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 BM0AkSA7waNv for <netmod@ietfa.amsl.com>; Thu, 15 Jun 2017 12:59:06 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8046A1201F2 for <netmod@ietf.org>; Thu, 15 Jun 2017 12:59:06 -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 B410E1AE03CA; Thu, 15 Jun 2017 21:59:04 +0200 (CEST)
Date: Thu, 15 Jun 2017 21:59:04 +0200
Message-Id: <20170615.215904.29472750939400252.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: <CABCOCHQ6nxqES=qjRBjBwQv+L+LgH9AUzuq9sDCG_80YTe0_xw@mail.gmail.com>
References: <CABCOCHTqQ-fi7cr9ZPmjbxCtTAe+X+=yLyWOotwdyfL5qL2pyg@mail.gmail.com> <20170615.210324.866114685910056800.mbj@tail-f.com> <CABCOCHQ6nxqES=qjRBjBwQv+L+LgH9AUzuq9sDCG_80YTe0_xw@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/ZkK6wtMdJXgfzDfsj6U5e8dXDf0>
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:59:09 -0000

Andy Bierman <andy@yumaworks.com> wrote:
> On Thu, Jun 15, 2017 at 12:03 PM, Martin Bjorklund <mbj@tail-f.com> wrote:
> 
> > 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.
> >
> >
> Sec 5.1 of the RD draft does not mention config=true nodes.

The operational state datastore's schema is all config true and all
config false nodes.

> 
>    augment /foo {
> 
>        when "blah";
> 
>    }
> 
> The XPatch context node for this when-stmt is /foo, which is a config=true
> node.
> Sec 5.1 says
> 
>   o If the XPath expression is defined in a substatement to a data
> 
>       node that represents system state, the accessible tree is all
>       operational state in the server.  The root node has all top-level
>       data nodes in all modules as children.
> 
> 
> The augment is a top-level statement in this example, so this text
> does not apply

Ok, so is your point that this text needs to mention augment as well?
This text was copied (and modified) from 6.4.1 of RFC 7950, and that
text doesn't mention augment either...


/martin