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

["Xufeng Liu" <[e-mail]>]

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.

> -----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.


> 
> 
> 
> 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? Whether they are legal or not should be determined by the schema-mount draft, not by the displaying notation.

> 
> 
> /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