> -----Original Message-----
> From: Martin Bjorklund [mailto:[email protected]]
> Sent: Tuesday, September 26, 2017 2:37 AM
> To: [email protected]
> Cc: [email protected]; [email protected]
> Subject: Re: [netmod] Proposal to enhance the YANG tree output
>
> "Xufeng Liu" <[email protected]> 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:[email protected]] On Behalf Of Martin
> > > Bjorklund
> > > Sent: Monday, September 25, 2017 1:39 PM
> > > To: [email protected]
> > > Cc: [email protected]
> > > Subject: Re: [netmod] Proposal to enhance the YANG tree output
> > >
> > > "Acee Lindem (acee)" <[email protected]> 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)" <[email protected]> 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"
> > > > ><[email protected] on behalf of [email protected]> 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 <[email protected]>
> 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
> > > > >>> > [email protected]
> > > > >>> > https://www.ietf.org/mailman/listinfo/netmod
> > > > >>>
> > > > >>> _______________________________________________
> > > > >>> netmod mailing list
> > > > >>> [email protected]
> > > > >>> https://www.ietf.org/mailman/listinfo/netmod
> > > > >>--
> > > > >>Ladislav Lhotka
> > > > >>Head, CZ.NIC Labs
> > > > >>PGP Key ID: 0xB8F92B08A9F76C67
> > > > >>
> > > > >>_______________________________________________
> > > > >>netmod mailing list
> > > > >>[email protected]
> > > > >>https://www.ietf.org/mailman/listinfo/netmod
> > > > >
> > > >
> > > _______________________________________________
> > > netmod mailing list
> > > [email protected]
> > > https://www.ietf.org/mailman/listinfo/netmod
> >
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
