Jernej Tuljak <[email protected]> wrote: > 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.
Note that a case *node* always exists, even if the shorthand syntax is used. /martin > > Jernej > > > Preferably prohibiting scenarios instead of explaining all the > > complexities :-( > > 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 <[email protected]> > >>> 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: [email protected] > >>> > >>> _______________________________________________ > >>> netmod mailing list > >>> [email protected] > >>> https://www.ietf.org/mailman/listinfo/netmod > >> -- > >> Ladislav Lhotka, CZ.NIC Labs > >> PGP Key ID: E74E8C0C > >> > >> > >> > >> > >> > > > _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
