Hello Martin,
Does this mean the mandatory does have an effect, resulting in an
invalid model according to A2?
regards Balazs
On 2015-10-06 11:25, Martin Bjorklund wrote:
Jernej Tuljak <jern...@mg-soft.si> 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 <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
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
