Subject: [netmod] XPath questions about revised datastores

From: Andy Bierman <[email-masked]>
Date: Wed, 14 Jun 2017 11:07:35 -0700

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 15 Jun 2017 14:27:16 +0200

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.

/js

> _______________________________________________
> netmod mailing list
> [email-masked]
> 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/>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 15 Jun 2017 08:09:03 -0700

> 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 { }
  }

 Correct: Will evaluate when-stmt against operational:

   augment /foo {
       container stats {
         config false;
         when "different condition";
       }
   }

Forcing the augmenting node to be the XPath context node impacts the
possible expressions.
I think the RD draft should make all this clear.

/js

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 15 Jun 2017 17:41:43 +0200 (CEST)

> WRONG: Will evaluate when-stmt against config

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.

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

> 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

---

From: Andy Bierman <[email-masked]>
Date: Thu, 15 Jun 2017 08:59:25 -0700

> the stats containter you have config false leafs?
no -- stats is a config false container

> (e.g. running), the stats container exists if "some condition" is true

no -- in my example the desire is to augment the operational state based on
the
operational value of a config=true leaf

> This is not different from how it works today wrt candidate vs running

no -- the datastore doesn't change based on the context node config-stmt
value
for candidate and running.

Andy

> > > > So if /foo-state is folded into /foo (because that is the intent --
> to
> > > get

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 15 Jun 2017 18:08:50 +0200 (CEST)

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

> operational value of a config=true leaf

Yes, that will happen in both cases.

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

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 15 Jun 2017 09:15:23 -0700

> is no mechanism to read data from a different datastore in the XPath

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.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 15 Jun 2017 21:03:24 +0200 (CEST)

> 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).

> to evaluate in the operational datastore.

No, see above.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 15 Jun 2017 12:23:09 -0700

On Thu, Jun 15, 2017 at 12:03 PM, Martin Bjorklund <[email-masked]> wrote:

> > > > no -- in my example the desire is to augment the operational state
> based
> > > on
> > > > the
Sec 5.1 of the RD draft does not mention config=true 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

Andy

> > > > > > > > So if /foo-state is folded into /foo (because that is the
> intent
> > > --
> > > > > to
> > > > > > > get
> > > > > > > > get applied to the operational value instead of the
> configured
> > > value?

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 15 Jun 2017 21:59:04 +0200 (CEST)

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

> The augment is a top-level statement in this example, so this text

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

---

From: Andy Bierman <[email-masked]>
Date: Fri, 16 Jun 2017 09:40:21 -0700

> ,,,,
This actually changes the behavior of YANG XPath.

  container foo {
      leaf A { type int8; }
      leaf B {
        when "../A > 3";
        type int8;
        config false;
      }
   }

It has always been OK for a config=false data node's XPath expression to
point at a config=true data node.
But this has always meant the configured value. RD changes this behavior
because the new opstate datastore
contains only the operational values of config=true nodes. Now there is no
way for such an XPath expression
to test the configured value.

> text doesn't mention augment either...

The text is misleading -- it should really be the config-stmt value of the
effective context node
that matters. A top-level augment has no config-stmt value.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 16 Jun 2017 18:51:27 +0200

> to test the configured value.

Having something in the operational state dependent on a configured
value that has not yet been applied is broken. If you set A in
<running> to 5 but the operationally used value of A is still 2, then
we believe B should not be there.

/js

---

From: Phil Shafer <[email-masked]>
Date: Fri, 16 Jun 2017 13:18:15 -0400

>to test the configured value.

The XPath will refer to the current operational value, which is
better defined and more consistent behavior.  During the lack when
data is flowing between <intended> and <operational> as system
components read and follow new incoming configuration data, the
operational value should be guiding the constraints, not the
unrealized incoming value.

The XPath continues to work in a backwards compatible manner, but
the outcome is more crisply defined and the <operational> datastore
will have better odds of being self-consistent.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Fri, 16 Jun 2017 10:24:19 -0700

The draft should make it clear that this change is being made.
Before there was no way to access the operational value.
Now there is only oerational value and no way to access the configured
value.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 16 Jun 2017 19:27:02 +0200

Andy,

in the past, there was the assumption that the operational value and
the configured value are always the same. This is not really a
'change' but much more a clarification what the expression means in
cases where the values differ.

/js