On 21/03/2017 10:49, Ladislav Lhotka wrote:
On 21 Mar 2017, at 11:25, Juergen Schoenwaelder
<j.schoenwael...@jacobs-university.de> wrote:
Hi,
if we want to standardize tree diagrams, we may want to take a more
critical look at them, in particular the flags (that were created
ad-hoc and in resemblance to MIB tree diagrams). pyang --tree-help
says:
<flags> is one of:
rw for configuration data
ro for non-configuration data
-x for rpcs and actions
-n for notifications
This is (a) incomlete and (b) somewhat confusing since ct does not
equate to readwrite. I am attaching a sample yang file and here is the
output pyang 1.7.1 produces:
module: tree-sample
+--rw config-true-container
| +--rw param? string
+--ro config-false-container
| +--ro value? string
+--rw inline-action
| +---x action
| +---- oops? string
| +---w input
| | +---w in? string
| +--ro output
| +--ro out? string
+--rw inline-notification
+---n notification
+---- duration? string
rpcs:
+---x rpc
+---w input
| +---w in? string
+--ro output
| +--ro out? string
+--ro oops? string
notifications:
+---n notification
+--ro boom? string
I think a better usage of two letter flags would have been this (since
it more naturally aligns with what the YANG definition says):
<flags> is one of:
ct for configuration data
cf for non-configuration data
x- for rpcs and actions
xi for rpc or action input
xo for rpc or action output
n- for notifications
nt for notification tree (this is I think the term 7950 uses)
Inside notifications and operations, "cf" carries no information and just clutters the output. My
suggestion is to use "ct" or just "c" for config=true data and nothing elsewhere.
Do, we also actually need the 'xi', 'xo', or 'nt' at all? Would these
be obvious from the paths anyway?
I think that having less symbols on the diagram may make it easier to
parse, and perhaps less likely for the lines to wrap.
So I am suggesting perhaps just having:
<flags> is one of:
c for configuration data
x for rpcs and actions
n for notifications
module: tree-sample
+--c config-true-container
| +--c param? string
+--- config-false-container
| +-- value? string
+--c inline-action
| +--x- action
| +--x input
| | +--x in? string
| +--x output
| +--x out? string
+--c inline-notification
+--n notification
+--n duration? string
etc.
Rob
Lada
module: tree-sample
+--ct config-true-container
| +--ct param? string
+--cf config-false-container
| +--cf value? string
+--ct inline-action
| +--x- action
| +--xi input
| | +--xi in? string
| +--xo output
| +--xo out? string
+--ct inline-notification
+--n- notification
+--nt duration? string
rpcs:
+--x- rpc
+--xi input
| +--xi in? string
+--ro output
+--xo out? string
notifications:
+--n- notification
+--nt boom? string
(And I think the oops leafs should have triggered an error.)
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
<tree-sample.yang>_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
.
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
