Subject: [netmod] must-stmt for non-config nodes

From: Andy Bierman <[email-masked]>
Date: Fri, 16 Jan 2009 18:01:41 -0800

Hi,

I just noticed that the evaluation of must-stmts changed
from -02 to -03.

 From yang-03, sec. 7.5.3, para 6:

    o  If the context node represents configuration, the tree is the data
       in one of the datastores <startup/>, <running/>, or <candidate/>.
       The XPath root node has all top-level configuration data nodes in
       all modules as children.

IMO, this is an unacceptable change.
Which one of the datastores is it?
The <candidate> has no config=false nodes, unlike <running>.
The <startup> config is not even required to be accessible
with <get-config>, let alone <edit-config>.

If a DM designer writes an must expression, it needs to
work whether the target is <candidate> or <running>.
The rule above is not only too ambiguous, the XPath expr will
not work the same on different database targets,
which (IMO) is unacceptable.

The <startup> config cannot possibly have must statements
associated with it.  The <candidate> is a snapshot
of <running> and all the config=false nodes will
continue to change, regardless of any locks.
If <candidate> has non-config nodes, or <startup>
has non-config nodes, then we need to stop everything
and agree on a NETCONF architecture before continuing with YANG.

The previous rule made sense: If the node containing
the must-stmt is config=true, then the expression cannot
reference config=false nodes.  That actually works
for either standard database target.

Andy

_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Phil Shafer <[email-masked]>
Date: Sun, 18 Jan 2009 15:27:07 -0500

>The <candidate> has no config=false nodes, unlike <running>.

<running> is a config datastore, so it has no config=false nodes.

>with <get-config>, let alone <edit-config>.

But all must expressions (and other validity constraints) are
true for startup as well as running.

>work whether the target is <candidate> or <running>.

True.

>which (IMO) is unacceptable.

I don't follow you here (and maybe I'm not following you
anyways, but...).  The comment is meant to say that the
must expressions are applied to the portion of the config
data store rooted at the conceptual top, which is at the
top of the datastore, whether the datastore is <running/>,
<startup/>, or <candidate/>.  It doesn't mean that the
<running> element is the document element, if that's what
you are reading into it.

>associated with it.

Are you saying <startup> need not validate?

>The <candidate> is a snapshot

<candidate> is a workspace and may be completely
distinct from the contents of <running>.  Yes,
config=false nodes will continue to change, but
they are not part of the datastore.

>and agree on a NETCONF architecture before continuing with YANG.

<candidate> is a config datastore and so it cannot have non-config
nodes.  Similarly for <startup>.  Where did you get this idea
from?

I believe the intent is to put all "top-level" nodes in YANG
at the same level in that NETCONF world view, so my "/jnpr:foo"
and your "/ncx:foo" are siblings.

>for either standard database target.

Personally, I completely agree that the "cannot reference" rule
should remain, but the concensus was (I believe) to add this
odd "strict false" cruft, which breaks this rule.  This leasds
to config -> non-config references.

Or maybe I'm still not following you.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Sun, 18 Jan 2009 12:56:36 -0800

> Or maybe I'm still not following you.

IMO, that <startup> config may not validate.
What if the operator is updating the SW image
and the startup config at the same time,
and the new startup will not validate with
the current SW image, but it will with the new one.

module broken {

    namespace "broken";
    prefix b;

    container top {
      leaf a {
        type string;
        must "../b > 10";
      }

      leaf b {
        type uint32;
        config false;
      }
    }
}

candidate:

   <config>
      <top>
        <a>fred</a>
      </top>
   </config>

running:

   <config>
      <top>
        <a>fred</a>
        <b>100</b>
      </top>
   </config>

startup:

   <config>
      <top>
        <a>fred</a>
      </top>
   </config>

I do not agree that the <running> config has config=true
only nodes.

In either case, how is the must-stmt in leaf 'a' supposed
to evaluate the same on any database, not just <running>?

YANG modules that only work if the <edit-config> target
is <running> is broken.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 18 Jan 2009 22:42:13 +0100 (CET)

> to config -> non-config references.

No that's another thing.  The "cannot reference" was changed into this
text which states that the accessible tree (in which the must stmt is
evaluated) is made up of all config=true nodes for the config
datastores.  Thus, config=false nodes are never part of the accessible
tree for must expression on a config=true node.  But the new thing is
that it changed from a MUST NOT to this text.  The reason was brought
up by Andy, I believe.  If a non-config node is referenced, it will
evaluate to empty, just as if a non-existing node is referenced.
Consider this:

 container x {
     config true;
     leaf a {
         config false;
         type int32;
     }
     leaf b {
         config true;
         must "../a > .";   // (1)
         must "../z > .";   // (2)
         type int32;
     }
  }

Both (1) and (2) will always evaluate to false, since in (1) a is not
part of the accessible tree, and in (2), there is no such node z.

This is consistent with how XPath evaluators work on XML instance
documents.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 18 Jan 2009 22:46:39 +0100 (CET)

> I do not agree that the <running> config has config=true

So you think <get-config> on <running/> returns state data?

I think it's very clear from 4741 that the <running/> config contains
*config* only.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sun, 18 Jan 2009 14:02:18 -0800

> So you think <get-config> on <running/> returns state data?

No, <get-config> filters out the non-config nodes.
But <get> on <running/> returns all nodes, config or not.

It is just an implementation issue how the agent
constructs the <get> response.

The new CLR is confusing.
It means that must "//b";  and get(type=xpath, select="//b")
return different results.

According to the YANG module, the node is there.
(Both a and a are child nodes of x in your example.)

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sun, 18 Jan 2009 14:16:54 -0800

> part of the accessible tree, and in (2), there is no such node z.

So no problem then.
The YANG module contains a must expression that
always resolves to false.  Except that means
the startup config-load will always fail,
any edit-config to <running/> will always fail,
and any commit of <candidate/> will always fail.
If /x/b exists, then the agent stops working correctly.

IMO, that needs more than a warning.
Unless you have a use-case why must XPath expressions
that always resolve to false are needed.

Is the intent of the must-stmts above to prevent
the leaf /x/b from ever existing?  Consider an agent
that uses a continue-on-error startup load
(so /x/b will get tossed during the load),
or any edit to <running/> to create /x/b will fail,
or any commit containing /x/b will fail.
That is all these must-stmts will accomplish.

Does the draft even specify what an agent is supposed
to do if a must-stmt inside a config=false node occurs?
When is this detected?  When is the "I'm a buggy agent"
notification generated? ;-)

IMO, a must-stmt MUST NOT be a constant expression
which evaluates to false.

    leaf duh {
      type string;
      must "3 > 7";
    }

Same effect as above.  Legal XPath.  Broken YANG.

> ______

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sun, 18 Jan 2009 19:19:59 -0800

> evaluate to empty, just as if a non-existing node is referenced.

OK -- I think there is agreement that non-config nodes are
not present for config=true must tests.

The only issue is whether it is just a warning or an error.
It can be difficult to determine at YANG compile time
that a must-stmt result will always be false on every
(or any) agent.  Leaving it as a warning is OK because
the operation-failed must-violation from the agent
is the real determining factor, not the YANG compiler
messages.

I think there needs to be a clear warning in the draft
that must and when expressions will produce empty results
for any non-config nodes referenced in the expression.

> ___

Andy