Re: [netmod] XPath questions about revised datastores

Andy Bierman <andy@yumaworks.com> Thu, 15 June 2017 16:15 UTC

Return-Path: <andy@yumaworks.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 DF6E71200CF for <netmod@ietfa.amsl.com>; Thu, 15 Jun 2017 09:15:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
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 G4shHErdCbc5 for <netmod@ietfa.amsl.com>; Thu, 15 Jun 2017 09:15:26 -0700 (PDT)
Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8470F126C22 for <netmod@ietf.org>; Thu, 15 Jun 2017 09:15:25 -0700 (PDT)
Received: by mail-wm0-x231.google.com with SMTP id n195so3710465wmg.1 for <netmod@ietf.org>; Thu, 15 Jun 2017 09:15:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HpbMQ4z8ZsoBw/n6MQ9y6O3kK0UngiOuq82bvBS8vN8=; b=U2+jNcN7rDx9MfG48vkP9ncYMRmpI+z2JJ4xyaS0Q9dtJwykM6/ShM9467E3GMckQb KdzX5Lhjg3hGS7LsDREPmv87G9p7UxMHq9HOMkt0fhBIAjbDJDHltEGyRDrjM2/XTs+9 BmRh5wOD/CPuMJXMq0uLZ9BMkAV5DkCCTuvtLPjH8s0abP0Iw79ak6GUB7tvu2bsT0i6 ZZoXVOCICPPpY8ngKxZgz8aH+4OFsWxSAxOp1XbSRchguYvrRkxl+2ZhEuaZ7Tqce1RY 66uLodlWv6WFBneU0bHUTzaJ/qAZL92zCumEaRH0NtNKxO9cAVp7w1AAhn8nH6QfYEie 6b9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HpbMQ4z8ZsoBw/n6MQ9y6O3kK0UngiOuq82bvBS8vN8=; b=nVY3U4QQfOudJUXc8TZ7qhAlSxpstxABuvccirDijayuzYtSa99MXr2dzcgAmspvIL Un0FfIT9/7cFQNqCzNza2YhcThsHWj0yBEzIKagZTgYQOaGY8AcOAJ2nGviSVB3lvULy u/aQyfJKgHJJy6iYJUNFQdecrVaAx1uFLwAhbDdLWDJboKxyLwSVY6SD+Cp3cOw+CPMD b3RpepFat91TNO68b4yTDOsqiZikYbLB6ShKn+MafBjCaQl/JUdqFEwpeswcGD4URU8F dcTeHgt20OA2ZH+2wZKnCskW0iSoJSzKRSmSygh8eZEHk+99bPwfmq+sDKHF8IsMTMy/ LwgA==
X-Gm-Message-State: AKS2vOzvlUWKxjMnHvYeCHC6uK4nkP7ZZ2C4iL6hSdpHKvnwylTUfCsf 7pnpVHtXdSFtCz6evZfxR5yDjVM09sob
X-Received: by 10.28.181.201 with SMTP id e192mr4257975wmf.48.1497543323898; Thu, 15 Jun 2017 09:15:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.182.173 with HTTP; Thu, 15 Jun 2017 09:15:23 -0700 (PDT)
In-Reply-To: <20170615.180850.1310683464764148583.mbj@tail-f.com>
References: <CABCOCHR4C16nJeizcCdmM966OEvid6zjzxL69QSaTriAZa67Xw@mail.gmail.com> <20170615.174143.206077667263578256.mbj@tail-f.com> <CABCOCHTN8x8=h4McG5Rf+m+XjO6YmwUaR-JfwhecL=CdbEGfag@mail.gmail.com> <20170615.180850.1310683464764148583.mbj@tail-f.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Thu, 15 Jun 2017 09:15:23 -0700
Message-ID: <CABCOCHTqQ-fi7cr9ZPmjbxCtTAe+X+=yLyWOotwdyfL5qL2pyg@mail.gmail.com>
To: Martin Bjorklund <mbj@tail-f.com>
Cc: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, "netmod@ietf.org" <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="f403045f55e2db6e1e055201f95f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/dp0-4_R4d38sn-znQZ0rVVZ-5F0>
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 16:15:29 -0000

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?

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.



> /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/>
> > > > >
> > >
>