Jernej Tuljak je 6.10.2015 ob 11:22 napisal:
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.
Just ignore the last two sentences. Its covered.
Jernej
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
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
