Subject: [netmod] The when-choice loop

From: Balazs Lengyel <[email-masked]>
Date: Thu, 15 Oct 2015 13:59:05 +0200

Hello,
In RFC6020bis we write:
"There MUST NOT be any circular dependencies in these "when" expressions."
How about a circular when-choice loop?

         leaf a1 {
             type boolean;
             when not(../a2);
         }
         choice c2 {
             default case2;
             case case1 {
                 when not(a1);
                 leaf b1 {type int8;}
             }
             case case2 {
                 leaf a2 {
                     type boolean;
                     default true;
                 }
             }
         }

Initial state: a1=false, b1=5;
- Set a1=true
- case1 and b1 disapears
- case2 and a2=false are set as default
- a1 disappears
- if there is no a1 why did we delete case1/b1?
Did I miss something, is this really what happens?

Even if someone can come up with the correct solution, operators will be 
100% sure to mess this up. Usability=0 !!!

I want some of this multistep when/when, choice/choice, when/choice 
scenarios prohibited in RFC 6020 or 6087. Or state in 6020 that the 
order of evaluation is implementation dependent: that would make it 
unusable, so practically prohibiting then while maintaining backward 
compatibility :-)

I attached an even more complicated example, so go ahead have fun 
understand it!
regards Balazs

PS: Why did we make YANG so complicated?

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
ECN: 831 7320
Mobile: +36-70-330-7909              email: [email-masked]

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 15 Oct 2015 14:27:00 +0200 (CEST)

> How about a circular when-choice loop?

Good catch.  choice/case can (more or less) be seen as a syntactic
sugar for a special form a when expressions; or rather, choice/case
can be rewritten with when:

  choice a {
    case c1 {
      node n11;
      ...
      node n1N;
    }
    case c2 {
      node n21;
      ...
      node n2N;
    }
    ...  
    case cM {
      node nM1;
      ...
      node nMN;
    }
 }

can (sort of) be rewritten as:

  node n11 {
    when not(n21 or .. n2N or ..  nM1 or nMN);
  }
  node n1N {
    when not(n21 or .. n2N or ..  nM1 or nMN);
  }
  node n21 {
    when not(n11 or .. n1N or n31 or n3N ...);
  }
  node n22 {
    when not(n11 or .. n1N or n31 or n3N ...);
  }
  ...

So, if you expand your example, there is actually a loop in the when
expressions.

/martin

> Even if someone can come up with the correct solution, operators will
> be 100% sure to mess this up. Usability=0 !!!
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 15 Oct 2015 14:53:26 +0200

Hi Balazs,

one lesson taken from early XML schema languages (DTD) was that modifying the validated document during validation easily leads to nasty race conditions. That's why RELAX NG avoids changing the XML infoset like plague.

I've already got tired reiterating (and providing examples) that "when" statement is inherently broken - the schema should not depend on evaluating arbitrary expressions in the context of an instance document that is supposed to be validated with the schema. The standard disclaimer is that it works for simple cases, and more complicated corner cases are "garbage in - garbage out".

Lada

P.S. Note that XPath expressions like "not(../a2)" evaluate to false if ../a2 exists, even if its content is "false". So you'd need expressions like "not(../a2 = 'true')".

> On 15 Oct 2015, at 13:59, Balazs Lengyel <[email-masked]> wrote:
> 
> Hello,
> In RFC6020bis we write:
> Even if someone can come up with the correct solution, operators will be 100% sure to mess this up. Usability=0 !!!
> 
> I want some of this multistep when/when, choice/choice, when/choice scenarios prohibited in RFC 6020 or 6087. Or state in 6020 that the order of evaluation is implementation dependent: that would make it unusable, so practically prohibiting then while maintaining backward compatibility :-)
> 
> I attached an even more complicated example, so go ahead have fun understand it!
> regards Balazs
> 
> <choice-when-interaction.yang>_______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

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

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 15 Oct 2015 15:17:31 +0200

Hello Lada,
So can we start gathering support for limiting when/choice to the simple 
cases by one of the 3 methods:
1) prohibit them (backward incompatible)
2) create a guideline not to use them in 6087, (easy to do, better then 
nothing, but does not protect the application)
3) declaring them as implementation dependent, thus making them backward 
compatible, but unusable

Complicated: In my view anytime a when or choice depends on another when 
or choice it is complicated. So use the simple cases only.
regards Balazs

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 15 Oct 2015 16:08:42 +0200

> On 15 Oct 2015, at 15:17, Balazs Lengyel <[email-masked]> wrote:
> 
> Hello Lada,
> So can we start gathering support for limiting when/choice to the simple cases by one of the 3 methods:

I would personally restrict the use of "when" only as a substatement of "augment". This would solve most issues, including Y18 (missing context node). I other cases, "must" can be often used instead of "when" with the same effect - at least for validation purposes. I am not sure that benefits of "when" outweigh the complexity - both in YANG spec and server implementation.

I also think servers should not automatically delete nodes whose "when" expression becomes false.

Lada

> 2) create a guideline not to use them in 6087, (easy to do, better then nothing, but does not protect the application)
> 3) declaring them as implementation dependent, thus making them backward compatible, but unusable
> 
> Complicated: In my view anytime a when or choice depends on another when or choice it is complicated. So use the simple cases only.
> regards Balazs
>

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 15 Oct 2015 17:59:21 +0200

Limiting when to augment doesn't really solve the issues, as you can 
augment in all the strange constructs instead of defining them locally. 
My ideas would be:

- when MUST NOT be dependent on a data node controlled by another when 
or choice statement
- choice SHOULD NOT be contained under a choice as the aggregate 
construct is hard to understand for a human user

Anything more complicated is too hard to understand. As we know 50% of 
all downtime in a network is caused by operator erroros. So DO NOT ake 
it complicated!!!!
regards Balazs