Juergen Schoenwaelder <[email protected]> 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)
I'm fine with this, but perhaps use "no" for notification data - "t"
means "true" in "ct".
Also, in a grouping like this:
grouping my-grouping {
leaf param { type string; }
}
pyang prints this as:
my-grouping
+---- param? string
i.e., w/o any flags.
> (And I think the oops leafs should have triggered an error.)
They did. To stderr.
/martin
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
