On 19/09/2017 14:28, Lou Berger wrote:

On 9/19/2017 7:29 AM, Martin Bjorklund wrote:
Lou Berger <lber...@labn.net> wrote:
Martin,

Speaking as a contributor:


On 9/15/2017 7:40 AM, Martin Bjorklund wrote:
Robert Wilton <rwil...@cisco.com> wrote:
On 15/09/2017 11:21, Ladislav Lhotka wrote:
Andy Bierman píše v Čt 14. 09. 2017 v 08:43 -0700:
Hi,


Actually I liked the early pyang output that was concise and easy to
remember.
The current format gets very cluttered and there are too many little
symbols
to remember them all.
I agree.
Me too.  The current draft adds three new magic symbols: "mp" "@" and
"/".

"mp" is for a mount point, and it can be generated directly from the
YANG modules.

Directly under a "mp", "/" and "@" are used to indicate that a node is mounted
or available through a parent reference, respectively.

I actually question the usability of "/" and "@".
I agree that / and @ are something new, and enabled by schema mount.
There have been repeated comments in the RTG WG that there needs to be
some way for vendors to convey what they have implemented with Schema
mount
If that's the requirement, using the tree diagram is probably not the
best way.  The tree diagram is intended to provide an overview of a
given (set of) YANG module(s).

A perhaps better way to convey the information is to create a file
with an instantiated /schema-mounts tree.
using what syntax?  JSON and XML really isn't that easy for the (human)
reader to parse.
Perhaps there needs to be multiple versions of the generated tree output?

1) A normative tree diagram that shows the structure of the model.
2) A subsequent example that demonstrates what it looks like with the schema mounted modules.  Within the confines of a text document, the tree format still seems like a reasonable way to illustrate this, and I would say it is preferable to the verbosity of JSON or XML.

I note that RFC 8022 includes an overview tree model in section 4 with some branches pruned, and then the complete representation in an appendix, which seems like a pragmatic approach.

Thanks,
Rob

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to