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

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

> -----Original Message-----
> From: Martin Bjorklund [mailto:[e-mail]]
> Sent: Tuesday, September 26, 2017 2:37 AM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: Re: [netmod] Proposal to enhance the YANG tree output
> 
> "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,

[Xufeng] I think that draft-ietf-netmod-schema-mount has the distinction between yang library data and schema-mounts/schema list. Do you mean the latter?

> 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 '/'.
> 
[Xufeng] What if the user does want to see all nodes in the system, whether they are mounted or un-mounted, is it possible?

Also, there is another case: I think that draft-ietf-netmod-schema-mount does not prohibit the mount-point container from containing other sub-containers. How can we tell these sub-containers are not from mounted modules?

   +--mp root
      +--rw rt:routing
      |  +--rw router-id?                 yang:dotted-quad
      |  +--rw control-plane-protocols
      |     +--rw control-plane-protocol* [type name]
      |        +--rw ospf:ospf
      +--rw other:other-container  // augmented by module "other"
      |  +--rw other-leaf?                 int32

> 
> > > 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.
[Xufeng] I agree that we should have "@" fully specified, but I'd hope that it won't get dropped so that there won't be a convenient way to tell whether a node is a parent-reference or not.

Thanks,
- Xufeng

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