Re: [netmod] Questions about namings and prefixes in leafrefs

[Paul Borman <[e-mail]>]

Thanks for the response and clarification, Lada.

> I am also trying to understand the prefixes used in XPath representations.
> > I have tried using --tree-prefix but that does not appear to accept any
> > prefixes.


> The "tree" plugin has no such option, RTFM.


Yes, clearly I meant --tree-path.  Sorry to have confused you.  Given the
chameleon aspect of groups, I take it that paths to a node in a data tree
(not the schema tree) do not have prefixes, and --tree-path takes a path in
the data tree (the documentation I read just says "Subtree to print").  I
am actually very happy to not have prefixes in the resulting data tree at
all.

>    - may optionally use the module's prefix for any element in a leafref
> >    path, no matter where the element is defined


> The prefix has to be present if the node is defined in another
> module. For example, a leafref in "base" pointing to
> "other-container-leaf1" would have



  path "/bother:other-container/bother:other-container-leaf1";


Interesting.  So a path in a leafref references the resulting data tree,
while the path provided to augment references the schema tree.  Re-reading
the "uses" description I see where it switches namespaces.

Since it appears, via empirical evidence with pyang, that the nodes of an
imported tree do not become part of the tree of the importing module.  What
does it mean to have a leafref reference a node in a tree other than its
own?  I will note that my example referred to a node within a grouping
defined in other but used in base, while your example refers to a node that
only exists in other.  So, my assertion about paths (they were all
relative) and prefix names was actually correct, but does not apply when
referencing a node in a different data tree (i.e., not part of the data
tree of the base module), which is what you gave an example of.

The "switching names spaces" aspect of uses explains why I cannot use the
bother prefix in relative paths, or even in paths rooted in base, that
include nodes from a grouping in other.  The satisfaction of types does
seem inconsistent with this, however.  I added some typedefs to base.yang
and other.yang (base-type and other-type, respectively), and then modified
the grouping in other.yang to have:

  grouping other-group {
    leaf other-group-leaf { type other-type; }
    leaf other-base-leaf { type base-type; }
    leaf other-bad-leaf { type bad-type; }
  }


When the other-group is used in base.yang, only bad-type is flagged as not
found (shouldn't other-type also be flagged as not found?), while when
other-group is used in other.yang, both base-type and bad-type are flagged
as not found (as I would expect).

Thanks,

    -Paul

On Thu, Jan 22, 2015 at 5:07 AM, Ladislav Lhotka <[e-mail]> wrote:

> Hi Paul,
>
> Paul Borman <[e-mail]> writes:
>
> > Hi, I am trying to understand RFC6020 without having had the benefit of
> > being in any of the discussions of the working group.  I have found the
> > discussion of path names unclear so I have used pyang to try and
> understand
> > what is expected.  It seems to me that a path in a leafref:
> >
> >    - may descend into submodule's containers
>
> yes
>
> >    - may descend into used groupings, no matter where the grouping is
> >    defined
>
> yes
>
> >    - may *not* ascend into the parent module
>
> Actually, I am not sure about this one.
>
> >    - may optionally use the module's prefix for any element in a leafref
> >    path, no matter where the element is defined
>
> The prefix has to be present if the node is defined in another
> module. For example, a leafref in "base" pointing to
> "other-container-leaf1" would have
>
>   path "/bother:other-container/bother:other-container-leaf1";
>
> >    - may optionally use the belongs-to-prefix in elements in paths
> inside a
> >    submodule
>
> yes
>
> >    - may *never* use the prefix for/from an imported module
>
> It must *always* use it.
>
> >
> > Some questions this raise are:
> >
> >    - are these observations correct (and intended)?
> >    - is there ever a time where a prefix is required in a leafref
> >    path?
>
> Yes, see above.
>
> I hope submodule rules will be significantly simplified in YANG 1.1, see
> issue Y49:
>
> https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-50
>
> ...
>
> >
> > I am also trying to understand the prefixes used in XPath
> representations.
> > I have tried using --tree-prefix but that does not appear to accept any
> > prefixes.
>
> The "tree" plugin has no such option, RTFM.
>
> >     // These next two ar invalid
> >     leaf base-container-badref1 {
> >       type leafref { path
> > ../other-group-container/bother:other-group-container-leaf1; }
>
> The prefix "bother" is wrong. It is because YANG groupings are
> "chameleons": nodes defined in a grouping receive the namespace of the
> module where the grouping is used, not the one in which it is
> defined. Sec sec. 7.12 in RFC 6020.
>
> Lada
>
> >     }
> >     leaf base-container-badref2 {
> >       type leafref { path
> > ../other-group-container/pother:other-group-container-leaf1; }
> >     }
> >   }
> > }
> >
> > // included by base.yang.
> > submodule sub {
> >   belongs-to base { prefix "sbase"; }
> >   container sub-container {
> >     leaf sub-container-leaf { type string; }
> >     container subsub {
> >       leaf sub-leafref {
> >         type leafref { path ../../sub-container-leaf; }
> >       }
> >       leaf sub-leafref1 {
> >         type leafref { path ../../sbase:sub-container-leaf; }
> >       }
> >       // the next two both fail trying to ascend into the parent
> >       leaf sub-badref2 {
> >         type leafref { path ../../../base-container/base-container-leaf;
> }
> >       }
> >       leaf sub-badref3 {
> >         type leafref { path
> > ../../../sbase:base-container/base-container-leaf; }
> >       }
> >     }
> >   }
> >   grouping sub-group {
> >     container sub-group-container {
> >       leaf sub-group-leaf { type string; }
> >     }
> >   }
> > }
> >
> > // imported by base.yang.
> > module other {
> >   namespace "uri:empty";
> >   prefix "otherp";
> >   container other-container {
> >     leaf other-container-leaf1 { type string; }
> >     leaf other-container-leaf2 { type string; }
> >   }
> >   grouping other-group {
> >     leaf other-group-leaf { type string; }
> >     container  other-group-container {
> >       leaf other-group-container-leaf1 { type string; }
> >       leaf other-group-container-leaf2 { type string; }
> >     }
> >   }
> > }
> > _______________________________________________
> > netmod mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netmod
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>