> On 06 Oct 2015, at 09:38, Balazs Lengyel <balazs.leng...@ericsson.com> 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 > The very least we should say in 6087: avoid embedded choices. > regards Balazs > > On 2015-10-05 19:13, Ladislav Lhotka wrote: >>> On 05 Oct 2015, at 17:35, Balazs Lengyel <balazs.leng...@ericsson.com> >>> wrote: >>> >>> 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? >> 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 >> >>> regards Balazs >>> >>> -- >>> Balazs Lengyel Ericsson Hungary Ltd. >>> Senior Specialist >>> ECN: 831 7320 >>> Mobile: +36-70-330-7909 email: balazs.leng...@ericsson.com >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> >> >> >> >> > > -- > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > ECN: 831 7320 > Mobile: +36-70-330-7909 email: balazs.leng...@ericsson.com -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
