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 "@".  Since a parent
reference can be very specific, e.g. one specific interface, it isn't
really accurate to show:

                  +--mp vrf-root
                     +--rw rt:routing/
                     |  ...
                     +--ro if:interfaces@

And the trailing "/" on rt:routing doesn't add any information we
don't already know.  Since vrf-root is a mount point, it follows that
its children are mounted.

Also, what is mounted under a mount point is not defined in the
schema, so a tool cannot generate this from the YANG modules.


So maybe we should remove "/" and "@", and just keep "mp".

> I definitely think that "x" is a bit confusing since it both means
> "RPC" and also "status deprecated" depending on where it is.

Possibly.  "x" for "deprecated" comes from smidump.  "x" for "execute"
(rwx) is of course common.  So if we should change something it is
probably "x" for "deprecated".  But "x" looks better than "d"...


/martin



> 
> Thanks,
> Rob
> 
> 
> >
> > Lada
> >
> >>
> >> Andy
> >>
> >>
> >> On Thu, Sep 14, 2017 at 8:33 AM, Joe Clarke <jcla...@cisco.com> wrote:
> >>> I've been hacking on pyang, and I changed tree.py to add the enum
> >>> values
> >>> for enumeration types and identiyref bases for identityref types.
> >>> Here
> >>> is an example:
> >>>
> >>> module: yang-catalog
> >>>      +--rw catalog
> >>>         +--rw modules
> >>>         |  +--rw module* [name revision organization]
> >>>         |     +--rw name                     yang:yang-identifier
> >>>         |     +--rw revision                 union
> >>>         |     +--rw organization             string
> >>>         |     +--rw ietf
> >>>         |     |  +--rw ietf-wg?   string
> >>>         |     +--rw namespace                inet:uri
> >>>         |     +--rw schema?                  inet:uri
> >>>         |     +--rw generated-from?          enumeration [mib, code,
> >>> not-applicable, native]
> >>>         |     +--rw maturity-level?          enumeration [ratified,
> >>> adopted, initial, not-applicable]
> >>> ...
> >>>                                 +--rw protocols
> >>>                                 |  +--rw protocol* [name]
> >>>                                 |     +--rw name
> >>> identityref -> protocol
> >>> ...
> >>>
> >>> My questions are:
> >>>
> >>> 1. Is this useful?
> >>>
> >>> 2. If so, can this be added to pyang (happy to submit a PR) and
> >>> draft-ietf-netmod-yang-tree-diagrams?
> >>>
> >>> 3. What changes to the output format would you recommend?
> >>>
> >>> Thanks.
> >>>
> >>> Joe
> >>>
> >>> _______________________________________________
> >>> 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
> 
> _______________________________________________
> 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

Reply via email to