Re: [netmod] Proposal to enhance the YANG tree output

[Martin Bjorklund <[e-mail]>]

"Xufeng Liu" <[e-mail]> wrote:
> To a user of the schema-mount, it is important to be able to visualize
> all key elements of the mounting mechanism: mount-point, mounted
> schema module, and parent-reference. The details can be worked out,
> but if any of these elements were not useful in the presentation, it
> would be questionable whether it had well-specified in the schema
> mount draft.

We agreed that we probably don't want to list all enums in the tree.
Does that imply that enumerations are not well-specified in YANG?

> > -----Original Message-----
> > From: netmod [mailto:[e-mail]] On Behalf Of Martin
> > Bjorklund
> > Sent: Monday, September 25, 2017 1:39 PM
> > To: [e-mail]
> > Cc: [e-mail]
> > Subject: Re: [netmod] Proposal to enhance the YANG tree output
> > 
> > "Acee Lindem (acee)" <[e-mail]> wrote:
> > > Martin, Lada, et al,
> > >
> > > While I don’t think we need additional annotations that Joe had
> > > prototyped (at least not as the default), I strongly believe we need
> > > to keep the ‘@‘ and ‘/‘ in the tree output for schema mount.
> > 
> > Can you explain what information "/" gives the reader?  Compare these
> > two
> > trees:
> > 
> >   +--mp vrf-root
> >      +--rw rt:routing/
> >         +--rw rt:router-id
> > 
> > and
> > 
> >   +--mp vrf-root
> >      +--rw rt:routing
> >         +--rw rt:router-id
> > 
> > What did the "/" in the first tree tell me that I don't see in the
> > second tree?
> 
> [Xufeng] Because the schema mount draft allows an augmenting module
> not to be listed in the mounted schema list. The following two
> examples show two different configurations:
> 
>   +--mp root
>      +--rw rt:routing/
>      |  +--rw router-id?                 yang:dotted-quad
>      |  +--rw control-plane-protocols
>      |     +--rw control-plane-protocol* [type name]
>      |        +--rw ospf:ospf/
> 
> where ospf augments rt, and has been listed in the mounting schema
> list.
> 
>   +--mp root
>      +--rw rt:routing/
>      |  +--rw router-id?                 yang:dotted-quad
>      |  +--rw control-plane-protocols
>      |     +--rw control-plane-protocol* [type name]
>      |        +--rw ospf:ospf
> 
> where ospf augments rt, and has not been listed in the mounting schema
> list.

If the ospf module is NOT listed in the yang library data for the
mount point, then it will not be present in the tree.  So in this case
the tree will be:

   +--mp root
      +--rw rt:routing
      |  +--rw router-id?                 yang:dotted-quad
      |  +--rw control-plane-protocols
      |     +--rw control-plane-protocol* [type name]
             // no ospf here

[Think about it the other way around; if we were to show all nodes
from all modules that are NOT mounted, our tree would be inifinitely
big...]

If the ospf module *is* listed in the yang library data for the
mount point, then the tree can be:

   +--mp root
      +--rw rt:routing
      |  +--rw router-id?                 yang:dotted-quad
      |  +--rw control-plane-protocols
      |     +--rw control-plane-protocol* [type name]
      |        +--rw ospf:ospf

No need for a '/'.


> > Then consider:
> > 
> >   +--ro if:interfaces@
> > 
> > and
> > 
> >   +--ro if:interfaces
> >      +-- if:interface@
> > 
> > and
> > 
> >   +--ro if:interfaces@
> >      +-- if:interface@
> > 
> > 
> > Which ones are legal, and what do they mean?
> > 
> [Xufeng] The display shows the result of the XPath, right?

I don't know what it shows; I'm not proposing this notation.  Also
note that the result of the XPath is a node set of *instance data*,
but the tree shows the *schema*, and mixing the two is confusing.

Hopefully by looking at the trees above, the reader will understand
what's behind this notation.  So I ask again, what do the notations
above mean?

> Whether
> they are legal or not should be determined by the schema-mount draft,
> not by the displaying notation.

The schema mount draft does not specify the rules for the '@' in the
tree output.

--

My points are that:

  (1)  "/" is redundant and not needed.  The same information can be
       conveyed w/o "/".

  (2)  "@" is under specified, and it mixes schema and instance data.



/martin






> 
> > 
> > 
> > /martin
> > 
> > While the former enhancement
> > > provided details, the schema mount tree designations are every bit as
> > > important as knowing, for example, whether or not a schema leaf is a
> > > presence node.
> > >
> > > Thanks,
> > > Acee
> > >
> > >
> > > On 9/15/17, 9:56 AM, "Acee Lindem (acee)" <[e-mail]> wrote:
> > >
> > > >+1 - Also it is hard enough to format the tree output to fit in a
> > > >+draft
> > > >w/o further annotations (even with —-tree-line-length).
> > > >Thanks,
> > > >Acee
> > > >
> > > >
> > > >On 9/15/17, 6:21 AM, "netmod on behalf of Ladislav Lhotka"
> > > ><[e-mail] on behalf of [e-mail]> 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.
> > > >>
> > > >>Lada
> > > >>
> > > >>>
> > > >>>
> > > >>> Andy
> > > >>>
> > > >>>
> > > >>> On Thu, Sep 14, 2017 at 8:33 AM, Joe Clarke <[e-mail]> 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
> > > >>> > [e-mail]
> > > >>> > https://www.ietf.org/mailman/listinfo/netmod
> > > >>>
> > > >>> _______________________________________________
> > > >>> netmod mailing list
> > > >>> [e-mail]
> > > >>> https://www.ietf.org/mailman/listinfo/netmod
> > > >>--
> > > >>Ladislav Lhotka
> > > >>Head, CZ.NIC Labs
> > > >>PGP Key ID: 0xB8F92B08A9F76C67
> > > >>
> > > >>_______________________________________________
> > > >>netmod mailing list
> > > >>[e-mail]
> > > >>https://www.ietf.org/mailman/listinfo/netmod
> > > >
> > >
> > _______________________________________________
> > netmod mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netmod
>