Balazs Lengyel <[email protected]> wrote:
> Hello,
> In RFC6020bis we write:
> "There MUST NOT be any circular dependencies in these "when"
> expressions."
> 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
>
> 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 protected]
>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
