Subject: [netmod] Circular dependency in 'when'

From: Vladimir Vassilev <[email-masked]>
Date: Wed, 07 Sep 2016 14:09:16 +0200

Hi,

Is there any practical value of 'when' statements with circular 
dependency to the value of the parent (in case it is a leaf) or any 
children of the parent?

   container circular-dependency-when {
       leaf a {
           when "(. + ../b) = 100";
           type uint16 {
               range "0 .. 100";
           }
       }
       leaf b {
           type uint16 {
               range "0 .. 100";
           }
       }
   }

I notice none of the tools  known to me complain about this example 
model however some will not allow the user to interactively configure 
'a' (even if he intends to use value which would make the 'when' 
statement evaluate as "true").

Did not find any 'when' statements depending on the value of their 
parent or the value of children of that parent in the standard and draft 
models known to me but this is valid YANG according to the YANG RFC text.

I believe if there is consensus this indeed qualifies as circular 
dependency and it has no value to allow such cases it can at least give 
a signal to model designers they should avoid using such 'when' 
statements until this is explicitly noted in a follow up YANG version.

Vladimir

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 07 Sep 2016 14:18:25 +0200 (CEST)

Hi,

Your example is not circular, and it is legal.  However, the 'when'
expression refers to the node in which the when expression is defined.
Note that this expression will always evaluates to 'false' (see the
third bullet in 7.21.5 in RFC 7950).

Take a step back and consider what the 'when' statement means - it is
used to indicate if the node can be present or not.  As such, it
doesn't make any sense to refer to the node itself in the xpath
expression.

In your case, you probably want to use a 'must' expression.  This is
evaluated once the node is present, in order to enforce some
constraint.

/martin

Vladimir Vassilev <[email-masked]> wrote:
> parent or the value of children of that parent in the standard and
> draft models known to me but this is valid YANG according to the YANG
> RFC text.
> 
> dependency and it has no value to allow such cases it can at least
> give a signal to model designers they should avoid using such 'when'
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Vladimir Vassilev <[email-masked]>
Date: Wed, 07 Sep 2016 19:44:02 +0200

> third bullet in 7.21.5 in RFC 7950).
This is true for YANG 1.1 due to that 3rd bullet in 7.21.5.

However it should be noted that in YANG 1.0 nothing says the data node 
for which the "when" statement is defined will be replaced with dummy 
node without a value so that this expression always evaluates to 
'false'. In YANG 1.0 the expression can evaluate to 'true' when a+b=100.

> evaluated once the node is present, in order to enforce some
I agree. I think the conclusion can be generalized to: there is no point 
in using "when" expressions directly depending on the value of the data 
node for which the "when" statement is defined or its children when the 
parent is not 'augment', 'uses', 'case' or 'choice' statement in YANG 
1.1 because the 'when' statement will always evaluate to 'false' and the 
data node will never exist.

Would be helpful if model validation tools could issue at least warning 
in such cases.

Vladimir

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 7 Sep 2016 20:21:45 +0200

> On 07 Sep 2016, at 19:44, Vladimir Vassilev <[email-masked]> wrote:
> 
> However it should be noted that in YANG 1.0 nothing says the data node for which the "when" statement is defined will be replaced with dummy node without a value so that this expression always evaluates to 'false'. In YANG 1.0 the expression can evaluate to 'true' when a+b=100.

Using "when" expressions that refer to the context node or its descendants could easily lead to deadlocks in YANG 1.0, so this part was underspecifed and ill-defined. The new 1.1 procedure for evaluating "when" expressions is thus a bug fix. Although it is somewhat tricky and sometimes (as in your example) counter-intuitive at first sight, it leads to unambiguous and stable results. 

> I agree. I think the conclusion can be generalized to: there is no point in using "when" expressions directly depending on the value of the data node for which the "when" statement is defined or its children when the parent is not 'augment', 'uses', 'case' or 'choice' statement in YANG 1.1 because the 'when' statement will always evaluate to 'false' and the data node will never exist.

Not necessarily. The following expression is always true:

leaf foo {
    when ".";
    ...
} 

> 
> Would be helpful if model validation tools could issue at least warning in such cases.

This is rather difficult to detect in general. XPath is a complicated beast.

Lada

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Wed, 7 Sep 2016 11:39:23 -0700

On Wed, Sep 7, 2016 at 11:21 AM, Ladislav Lhotka <[email-masked]> wrote:

> for which the "when" statement is defined will be replaced with dummy node
> without a value so that this expression always evaluates to 'false'. In
> YANG 1.0 the expression can evaluate to 'true' when a+b=100.
>
> Using "when" expressions that refer to the context node or its descendants
> could easily lead to deadlocks in YANG 1.0, so this part was underspecifed
> and ill-defined. The new 1.1 procedure for evaluating "when" expressions is
> thus a bug fix. Although it is somewhat tricky and sometimes (as in your
> example) counter-intuitive at first sight, it leads to unambiguous and
> stable results.
>
> >>
> parent is not 'augment', 'uses', 'case' or 'choice' statement in YANG 1.1
> because the 'when' statement will always evaluate to 'false' and the data
> node will never exist.
>
I think it helps that "real" YANG developers are attempting to create
operationally useful data structures.  This is much different than a tool
developer
trying to construct a test case for a YANG compiler.

The when-stmt says "add foo to bar when XXX is true"
It seems obvious to real developers that XXX has to do with testing the
values in bar, not foo,

> Lada

Andy

---

From: "Jernej Tuljak" <[email-masked]>
Date: Thu, 8 Sep 2016 10:40:49 +0200

> -----Original Message-----
> From: netmod [mailto:[email-masked]] On Behalf Of Ladislav
> Lhotka
> Sent: Wednesday, September 7, 2016 8:22 PM
> To: Vladimir Vassilev <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [netmod] Circular dependency in 'when'
> 
> 
> node
> and ill-defined. The new 1.1 procedure for evaluating "when" expressions
> is thus a bug fix. Although it is somewhat tricky and sometimes (as in
> your example) counter-intuitive at first sight, it leads to unambiguous
> and stable results.
> 
> >>

We've implemented partial evaluation of XPath expressions that operates on an "accessible tree skeleton" (schema of the accessible tree as defined by modules in scope). 

For the example given by Vladimir, our compiler would complain with:

WARNING; test@2016-09-07:8; when: XPath construct '.' (at 2) references the initial context node or one of its descendants in a when expression

since it is referring to the "leaf" for which the "when" statement is defined and this was discouraged by one of the 6087bis drafts. It would detect this (and other issues) no matter how "obfuscated" the expression is.

Implementing it was mostly problematic due to poorly defined accessible trees or initial context nodes in some cases (YANG 1).
 
Jernej