On 03/05/2018 01:50 PM, Juergen Schoenwaelder wrote:
I prefer that the choice/case nodes do not have any flags since they
are not having a config true/false property on their own. And less
clutter is better.
'choice' statements have 'config' substatement while 'case' do not. I
myself figured that out while I was implementing tree diagrams support.
I would prefer the current pyang output and a change to the yang-tree
document to specify that nodes without config substatement do not have
<flags>.
Vladimir
/js
On Mon, Mar 05, 2018 at 12:26:27PM +0100, Martin Bjorklund wrote:
Hi,
Lifting this issue to its own thread.
With this snippet:
choice subnet {
case prefix-length {
leaf prefix-length {
type uint8;
}
}
case netmask {
leaf netmask {
type yang:dotted-quad;
}
}
}
pyang prints choice/case nodes like this:
+--rw (subnet)?
+--:(prefix-length)
| +--rw prefix-length? uint8
+--:(netmask)
+--rw netmask? yang:dotted-quad
With the syntax defined in the yang-tree document:
<status>--<flags> <name><opts> <type> <if-features>
it means that the choice node has <flags> just like any other node (in
this case "rw"), but the case node has "" as <flags>, and no space
after the "--".
This is clearly inconsistent, and something needs to be fixed.
The current yang-tree document doesn't say that choice/case should be
treated differently than other nodes.
Alternatives:
1) The document is correct, this is a bug in pyang, the output
should be:
+--rw (subnet)?
+--rw :(prefix-length)
| +--rw prefix-length? uint8
+--rw :(netmask)
+--rw netmask? yang:dotted-quad
2) Since the choice/case nodes are not present in the data tree,
they should not have any flags. The document should be fixed to
allow empty flags so we have:
+-- (subnet)?
+-- :(prefix-length)
| +--rw prefix-length? uint8
+-- :(netmask)
+--rw netmask? yang:dotted-quad
Note that the document is currently in AUTH48.
Something needs to be done in the document though, b/c it shows the
current pyang output in an example.
/martin
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
