Subject: [netmod] leafref type in a typedef

From: Andy Bierman <[email-masked]>
Date: Sat, 25 Jan 2014 09:35:02 -0800

Hi,

I have been discussing a leafref issue with Martin offline.
I think the RFC needs more clarification wrt/ a typedef
for a leafref.

Consider 2 modules (leafref-typ and leafref):

module leafref-typ {
    namespace "http://example.com/ns/leafref-typ";
    prefix "lrt";
    revision 2014-01-25;

    typedef abs-typ {
      type leafref {
        path "/mylist/X";
      }
    }

    typedef rel-typ {
      type leafref {
        path "../mylist/X";
      }
    }

    list mylist {
       key A;
       leaf A { type string; }
       leaf X { type int32; }
    }
}

module leafref {
    namespace "http://example.com/ns/leafref";
    prefix "lr";
    import leafref-typ { prefix lrt; }
    revision 2014-01-25;

    leaf abs-ref {
      type lrt:abs-typ;
    }

    leaf rel-ref {
      type lrt:rel-typ;
    }
}

The path statement section does not account for typedef,
in which no context node exists yet.

RFC 6020, sec. 9.9.2, para 5:

   The "path" XPath expression is conceptually evaluated in the
   following context, in addition to the definition in Section 6.4.1:

   o  The context node is the node in the data tree for which the "path"
      statement is defined.

   The accessible tree depends on the context node:

   o  If the context node represents configuration data, the tree is the
      data in the NETCONF datastore where the context node exists.  The
      XPath root node has all top-level configuration data nodes in all
      modules as children.

   o  Otherwise, the tree is all state data on the device, and the
      <running/> datastore.  The XPath root node has all top-level data
      nodes in all modules as children.

This text seems to say the path-stmt is evaluated in the context of the
leaf statements in the leafref module,

Sec 6.4.1:

   All YANG XPath expressions share the following XPath context
   definition:

   o  The set of namespace declarations is the set of all "import"
      statements' prefix and namespace pairs in the module where the
      XPath expression is specified, and the "prefix" statement's prefix
      for the "namespace" statement's URI.

   o  Names without a namespace prefix belong to the same namespace as
      the identifier of the current node.  Inside a grouping, that
      namespace is affected by where the grouping is used (see
      Section 7.12).

Q: Which namespace is the default for the path-stmts in module leafref-typ?

Q: what is the context node for the path-expr in the rel-typ typedef?

IMO, some bullets above are incomplete and need to be fixed somehow.
Hoping the WG can agree how to do that.

Andy

---

From: Jernej Tuljak <[email-masked]>
Date: Tue, 28 Jan 2014 10:59:14 +0100

> Q: Which namespace is the default for the path-stmts in module 

The namespace should be that of the typedef defining module. From module 
leafref perspective, paths are in this form: "/lrt:mylist/lrt:X" and 
"../lrt:mylist/lrt:X". Similar to the value/position statement issue, 
again "the identifier of the current node" seems ambiguous (6.4.1.).

"Inside a typedef, that namespace is the same as that of the identifier 
of the typedef (applies only to path statement, see Section 9.9.2.)." or 
something similar could be added after the grouping exception.

> Q: what is the context node for the path-expr in the rel-typ typedef?

The context node should be the lr:rel-ref leaf. One could argue that it 
already represents "the data node in the data tree for which the path 
statement is defined" even with current text. Would be better to be more 
specific though.

"If the path statement is defined within a used typedef, the context 
node is the leaf or leaf-list data node ancestor of the type statement 
which references the used typedef." or something similar could be added.

> Hoping the WG can agree how to do that.

I agree.

P.S.: However, IMO, any grouping or typedef should be reusable anywhere 
in their respective usage scope (whether top-level or local). A typedef 
or a grouping that can only be used in a specific way (like lrt:rel-typ) 
should be made illegal in favor of promoting reuse - the main purpose of 
both statements. Any XPath expression in YANG, not just path 
expressions, should respect this inherent property of typedefs and 
groupings. It's a shame this was not considered in the original text. 
Probably requires YANG 2.0 to fix.

Jernej

>
> Andy
>
>
>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Andy Bierman <[email-masked]>
Date: Tue, 28 Jan 2014 07:58:09 -0800

On Tue, Jan 28, 2014 at 1:59 AM, Jernej Tuljak <[email-masked]>wrote:

>  Dne 25.1.2014 18:35, piše Andy Bierman:
>
> Hi,
>
> "../lrt:mylist/lrt:X". Similar to the value/position statement issue, again
> "the identifier of the current node" seems ambiguous (6.4.1.).
>
> "Inside a typedef, that namespace is the same as that of the identifier of
> the typedef (applies only to path statement, see Section 9.9.2.)." or
I agree the compiler always has to bind modules to QNames inside the module
containing
the path-stmt.  That seems to be clear from 6.4.1. (Current node is really
current statement,
not a data node).

> "If the path statement is defined within a used typedef, the context node
> is the leaf or leaf-list data node ancestor of the type statement which
> references the used typedef." or something similar could be added.
>
>

Our compiler tries to validate the path-stmt in the typedef, using the
document
root as the context node.  Then it is evaluated again in the leaf, using the
real context node.  Relative path expressions should be avoided in typedefs
but they are allowed.

> P.S.: However, IMO, any grouping or typedef should be reusable anywhere in
> their respective usage scope (whether top-level or local). A typedef or a
> grouping that can only be used in a specific way (like lrt:rel-typ) should
> be made illegal in favor of promoting reuse - the main purpose of both
> statements. Any XPath expression in YANG, not just path expressions, should
> respect this inherent property of typedefs and groupings. It's a shame this
> was not considered in the original text. Probably requires YANG 2.0 to fix.
>
>
I agree the relative path-expr is dangerous to use.
It could be covered with a YANG guideline.
We have guidelines like mandatory top-level nodes are legal,
but not allowed in IETF modules. We can force IETF modules
to use absolute path-expr in typedefs.  A relative path-expr
in a grouping that refers to something in the grouping is OK.

Jernej

Andy