----- Original Message ----- From: "Martin Bjorklund" <m...@tail-f.com> Sent: Tuesday, September 19, 2017 2:42 PM
> Lou Berger <lber...@labn.net> 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: > > >>>>>> > > >>>>>> 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. > > Either JSON or XML. > > > >> and this is one way to help convey (a) what is expected of server > > >> implementors and (b) what client implementors should expect. > > >> > > > Hence the > > >> current draft text: > > >> > > >> In describing the intended use of a module containing a mount point, > > >> it is helpful to show how the mount point would look with mounted > > >> modules. > > >> > > >> The whole point of trees is to facilitate understanding for those who > > >> are less familiar with a model than the authors, and IMO that's the > > >> paramount perspective in this discussion. > > > Fully agree! I would say that we have to make sure that the diagrams > > > can be understood by people less familiar with the technology than the > > > authors. Mixing schema and instance data does not help here. > > > > Can you propose an alternative? > > As I have written before, I think the "/" is not needed, so I would > remove that. I would also not list the nodes from "parent-references" > in the same tree ouput. It is not clear to me that this level of > detail is needed in the tree, and - as noted before - it isn't even > correct to list e.g. "interfaces" when the parent-reference in fact > selects a single interface. > > > The routing WG participants seem to > > find these useful, we can also ask there for broader input if you'd like. > > One approach is to add the union of eveything that some people find > useful. In the end we have to look for WG consensus. Several people > have said that they prefer a less cluttered format. A union is what might be termed the OSI approach to design, an approach that led to ... well, ISIS and that's about it. draft-ietf-isis-yang-isis-cfg-18 has some 10 pages of tree structure which are of little help to me in understanding the module. With draft-ietf-teas-yang-te-topo-12, the tree structure runs to over 35 pages and then I think that the tree structure has failed. Adding more symbols will not help. Less is More. Tom Petch > > >>> Since a parent > > >>> reference can be very specific, e.g. one specific interface, it isn't > > >>> really accurate to show: <snip> _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
