_____________________________________
From: netmod <[email protected]> on behalf of Rob Wilton (rwilton)
<[email protected]>
Sent: 14 February 2020 10:14
To: Kent Watsen; [email protected]
My interpretation matches the one that Martin gives in
https://github.com/mbj4668/pyang/issues/559
<tp>
I was looking at
draft-boydseda- ipfix-psamp-bulk-data-yang-model
and see nine choice statements of which six have no case, two have a single
case and one has multiple case. The single case have a note to the effect that
they may be augmented, the others have no note. The no case do have multiple
container or leaf statements. It does make me curious.
Tom Petch
I.e. the short hand notation …
choice test {
container foo {
if-feature disabled-feature;
...
}
}
is equivalent to:
choice test {
case foo {
container foo {
if-feature disabled-feature;
...
}
}
}
Filing an issue in YANG.Next to clarify, or further discuss, this seems helpful
to me.
Thanks,
Rob
From: netmod <[email protected]> On Behalf Of Kent Watsen
Sent: 13 February 2020 14:49
To: [email protected]
Subject: [netmod] Implicit case statementa
RFC 7950 says:
As a shorthand, the "case" statement can be omitted if the branch
contains a single "anydata", "anyxml", "choice", "container", "leaf",
"list", or "leaf-list" statement. In this case, the case node still
exists in the schema tree, and its identifier is the same as the
identifier of the child node.
This seems clear, albeit incomplete, as inconsistencies [1] exist amongst
`pyang`and `yanglint` (I did not test with `yangson`) in how the “if-feature”
statement is handled, though I imagine other statements (e.g., “when”) may also
fall into this discussion as well.
Ultimately, the question is what Errata and/or YANG-next issue should be filed.
I’m okay either way, so long as it’s clear and can be implemented
consistently across tooling.
In the meanwhile, I recommend module designers avoid using the shorthand
notation, as there are no known issues with the “longhand” notation.
[1] https://github.com/mbj4668/pyang/issues/559
Kent // contributor
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
