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

[Ladislav Lhotka <[e-mail]>]

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