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

[Ladislav Lhotka <[e-mail]>]

> On 22 Jan 2015, at 18:43, Paul Borman <[e-mail]> wrote:
> 
> 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.

Sometimes they are needed, even in JSON encoding that tries to suppress them as much as possible.
 
> 
> >    - 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

That’s right, augments modify the schema tree.

>  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

That’s correct, the importing module only gets access to top-level groupings, typedefs, identities and features.

>  tree other than its own?  I will note that my example referred to a node within a grouping defined in

The information about the set of modules that comprise the data model has to be supplied by other means. In NETCONF it is the hello message, and in pyang you can either provide a hello message as an XML document (with the --hello option), or simply put all modules on the command line. In your case it could be

$ pyang -f tree base.yang other.yang

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

This is not what I get: 

$ pyang base.yang other.yang 
other.yang:15: error: type "base-type" not found in module other
other.yang:16: error: type "bad-type" not found in module other

This is correct because types and everything else in a grouping are resolved in the context of the module where the grouping is defined, only reusable data nodes defined by the grouping receive the namespace of the module where the grouping is used. In your case, “base-type” is not known in “other”.

In the “base” module you could refer to “other-type” but only with the prefix:

type bother:other-type

This is because “base” imports “other”.

Lada

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

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C