Re: [netmod] XPath questions about revised datastores

Martin Bjorklund <mbj@tail-f.com> Thu, 15 June 2017 15:41 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 2916B128D2E for <netmod@ietfa.amsl.com>; Thu, 15 Jun 2017 08:41:50 -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 zAIoBEQsKjhn for <netmod@ietfa.amsl.com>; Thu, 15 Jun 2017 08:41:47 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 22E81127876 for <netmod@ietf.org>; Thu, 15 Jun 2017 08:41:47 -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 172191AE0352; Thu, 15 Jun 2017 17:41:44 +0200 (CEST)
Date: Thu, 15 Jun 2017 17:41:43 +0200
Message-Id: <20170615.174143.206077667263578256.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: <CABCOCHR4C16nJeizcCdmM966OEvid6zjzxL69QSaTriAZa67Xw@mail.gmail.com>
References: <CABCOCHS1oFGZMzDRANhdRrH1S+75RNbgdDggqW84ee7uwd5fbQ@mail.gmail.com> <20170615122716.GB58434@elstar.local> <CABCOCHR4C16nJeizcCdmM966OEvid6zjzxL69QSaTriAZa67Xw@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/dQQ5EqgHPHB29HVUwpMHXFw5qbU>
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 15:41:50 -0000

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?

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.

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.


/martin



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