Subject: [netmod] Choice corner Cases -1

From: Balazs Lengyel <[email-masked]>
Date: Mon, 5 Oct 2015 17:35:15 +0200

Hello,
What do the mandatory statements mean in the following model ?

            choice scen8 {  // Embedded choices with multiple mandatory 
cases; invalid scenario
                case A {
                    choice subChoiceA {
                        mandatory true;
                        case A {
                            leaf scen8-num1 { type uint8; }
                        }
                        case B {
                            leaf scen8-num2 { type uint8; }
                        }
                    }
                }
                case B {
                    choice subChoiceB {
                        mandatory true;
                        case A {
                            leaf scen8-num1 { type uint8; }
                        }
                        case B {
                            leaf scen8-num2 { type uint8; }
                        }
                    }
                }
            }

Answers:
A1) They mean nothing because the case around subChoiceA/B might not 
exist, in which case its underlying statements are not valid.
A2) They mean that one case from both subChoiceA AND subchoiceB must 
exist leading to two cases in choice scen8 which is not allowed, hence 
this is an invalid model?

Generally I find choices embedded in choices to be so complicated that 
IMHO they SHOULD be immediately prohibited. If you think about all the 
variants of embedded choices with mandatory and default placed on some 
or a bunch of them, even understanding what they mean becomes a 
headache. BAD !!!! In the beginning YANG was about easy-understanding. 
However these combinations are unclear even after repeatedly reading the 
RFC :-(
  As the very least we SHOULD prohibit mandatory/default on the inside 
choice.

regards Balazs

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

---

From: Andy Bierman <[email-masked]>
Date: Mon, 5 Oct 2015 09:26:09 -0700

Hi,

It looks like neither 'mandatory' or 'default' has any effect in
this situation.  If the nested choices had sibling nodes
then these statements would be relevant.  Then selecting the
sibling would cause the mandatory or default choice to have meaning.

Andy

On Mon, Oct 5, 2015 at 8:35 AM, Balazs Lengyel <[email-masked]>
wrote:

> A2) They mean that one case from both subChoiceA AND subchoiceB must exist
> leading to two cases in choice scen8 which is not allowed, hence this is an
> invalid model?
>
> variants of embedded choices with mandatory and default placed on some or a
> bunch of them, even understanding what they mean becomes a headache. BAD
> !!!! In the beginning YANG was about easy-understanding. However these
> combinations are unclear even after repeatedly reading the RFC :-(
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 5 Oct 2015 19:13:11 +0200

> On 05 Oct 2015, at 17:35, Balazs Lengyel <[email-masked]> wrote:
> 
> Hello,
>           choice scen8 {  // Embedded choices with multiple mandatory cases; invalid scenario
>               case A {
>                   choice subChoiceA {
>                       mandatory true;
>                       case A {
> A1) They mean nothing because the case around subChoiceA/B might not exist, in which case its underlying statements are not valid.
> A2) They mean that one case from both subChoiceA AND subchoiceB must exist leading to two cases in choice scen8 which is not allowed, hence this is an invalid model?

In the first place, it should be an error because of colliding names - all the leaves defined in sub-cases have the same parent. However, pyang doesn't flag it as an error.

> 
> Generally I find choices embedded in choices to be so complicated that IMHO they SHOULD be immediately prohibited. If you think about all the variants of embedded choices with mandatory and default placed on some or a bunch of them, even understanding what they mean becomes a headache. BAD !!!! In the beginning YANG was about easy-understanding. However these combinations are unclear even after repeatedly reading the RFC :-(

Yes, it is quite complicated. Normally, such embedded choices shouldn't be needed but they can happen if, e.g. the internal choices are defined in groupings.

> As the very least we SHOULD prohibit mandatory/default on the inside choice.

I think it would be better to ignore them (and tools may issue a warning).

Lada 

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

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 6 Oct 2015 09:38:50 +0200

Hello,
Thanks for the comments.
I WANT some clarification of this issue in te RFC. Preferably 
prohibiting scenarios instead of explaining all the complexities :-(
The very least we should say in 6087: avoid embedded choices.
regards Balazs

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 6 Oct 2015 09:56:26 +0200

> On 06 Oct 2015, at 09:38, Balazs Lengyel <[email-masked]> wrote:
> 
> Hello,
> Thanks for the comments.
> I WANT some clarification of this issue in te RFC. Preferably prohibiting scenarios instead of explaining all the complexities :-(

Interestingly, choice was not allowed as a short-hand case statement in YANG 1.0 but it has been added in YANG 1.1 - see issue Y29:

https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-30

Lada

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 6 Oct 2015 10:03:25 +0200

The embedded choice is clearly a case of over-complicating YANG. It was 
a poor choice to allow such cases.
Sorry :-) couldn't resist.

But seriously, one reason we wanted to design a new modeling language 
instead of reusing e.g. XSD was because XSD is too complicated, and then 
we get embedded choice ?
Balazs

---

From: Jernej Tuljak <[email-masked]>
Date: Tue, 6 Oct 2015 11:22:02 +0200

Balazs Lengyel je 6.10.2015 ob 9:38 napisal:
> Hello,
> Thanks for the comments.
> I WANT some clarification of this issue in te RFC. 

Your mandatory constraints will never be enforced, due to 7.9.4.:

    The behavior of the constraint depends on the type of the choice's
    closest ancestor node in the schema tree which is not a non-presence
    container (seeSection 7.5.1 <https://tools.ietf.org/html/rfc6020#section-7.5.1>):

    o  If this ancestor is a case node, the constraint is enforced if any
       other node from the case exists.

    o  Otherwise, it is enforced if the ancestor node exists.

First bullet. Clear enough, IMO. Augmentation could change that, though.

BTW, do these bullets cover 1.1? The case node is no longer required due 
to shorthand choice. Note how the text assumes a case node.

Jernej

> Preferably prohibiting scenarios instead of explaining all the 
> complexities :-(
>>> exist leading to two cases in choice scen8 which is not allowed, 
>>> hence this is an invalid model?
>> In the first place, it should be an error because of colliding names 
>> - all the leaves defined in sub-cases have the same parent. However, 
>> pyang doesn't flag it as an error.
>>
>>> Generally I find choices embedded in choices to be so complicated 
>>> that IMHO they SHOULD be immediately prohibited. If you think about 
>>> all the variants of embedded choices with mandatory and default 
>>> placed on some or a bunch of them, even understanding what they mean 
>>> becomes a headache. BAD !!!! In the beginning YANG was about 
>>> easy-understanding. However these combinations are unclear even 
>>> after repeatedly reading the RFC :-(
>> Yes, it is quite complicated. Normally, such embedded choices 
>> shouldn't be needed but they can happen if, e.g. the internal choices 
>> are defined in groupings.
>>

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 06 Oct 2015 11:25:13 +0200 (CEST)

Jernej Tuljak <[email-masked]> wrote:
>    container (seeSection 7.5.1
>    <https://tools.ietf.org/html/rfc6020#section-7.5.1>):
> 
> BTW, do these bullets cover 1.1? The case node is no longer required
> due to shorthand choice. Note how the text assumes a case node.

Note that a case *node* always exists, even if the shorthand syntax is
used.

/martin

> >> In the first place, it should be an error because of colliding names -
> >> all the leaves defined in sub-cases have the same parent. However,
> >>> headache. BAD !!!! In the beginning YANG was about
> >>> easy-understanding. However these combinations are unclear even after
> >>> repeatedly reading the RFC :-(

---

From: Jernej Tuljak <[email-masked]>
Date: Tue, 6 Oct 2015 11:25:39 +0200

> due to shorthand choice. Note how the text assumes a case node.

Just ignore the last two sentences. Its covered.

Jernej

>>>> A1) They mean nothing because the case around subChoiceA/B might 
>>>> not exist, in which case its underlying statements are not valid.
>>>> A2) They mean that one case from both subChoiceA AND subchoiceB 
>>>> must exist leading to two cases in choice scen8 which is not 
>>>> allowed, hence this is an invalid model?
>>>> placed on some or a bunch of them, even understanding what they 
>>>> mean becomes a headache. BAD !!!! In the beginning YANG was about 
>>> shouldn't be needed but they can happen if, e.g. the internal 
>>> choices are defined in groupings.
>>>

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 6 Oct 2015 11:32:18 +0200

Hello Martin,
Does this mean the mandatory does have an effect, resulting in an 
invalid model according to A2?
regards Balazs

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 6 Oct 2015 11:48:08 +0200

> instead of reusing e.g. XSD was because XSD is too complicated, and then 

I think embedded choices were in YANG 1 and hence this is not a new
issue specific to YANG 1.1. Please correct me if I am wrong.

I am personally fine with embedded choices if the semantics are well
defined so that implementations interpret them the same way. Have you
tested different tools?

/js

PS: It is possible to write obfuscated code in almost all languages; I
    think the question is more whether the regular common use of the
    language is intuitive. A good language IMHO follows a set of
    simple general rules; attempts to rule out constructions that some
    people find obscure can turn a set of simple general rules into a
    complicated collection of special case constructions that make
    language maintenance and implementation a nightmare.

-- 
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: Balazs Lengyel <[email-masked]>
Date: Tue, 6 Oct 2015 11:57:14 +0200

Hello,
At least for naming conflicts within the deeper cases pyang and yangdump 
work differently.
Neither of them gave me a warning that some of my mandatory/default 
statements have no effect.
regards Balazs

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 06 Oct 2015 12:12:31 +0200 (CEST)

Balazs Lengyel <[email-masked]> wrote:
> Hello,
> At least for naming conflicts within the deeper cases pyang and
> yangdump work differently.

Tools may have bugs ;-)  The pyang bug was fixed some time ago.

> statements have no effect.

I don't think it is correct to say that they don't have effect.  As
Jernej pointed out, augmentations may add nodes to the case, so that
if the augmented node is created, the original leaf's default value is
in effect.

/martin

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 6 Oct 2015 13:47:43 +0200

So you say the augmenting module modifies how the augmented module 
works. This sounds like a side effect, that will only be understood by 
gurus.
Balazs