Subject: Re: [netmod] XPath issues

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 01 Jun 2009 10:16:05 +0200

Andy Bierman píše v Pá 29. 05. 2009 v 10:41 -0700:
> 
> The path-stmt in a leafref identifies one or more conceptual
> nodes in the value tree, so there are no choice or case nodes
> and there can be predicates for list keys.

How about expressions like "foo//bar" or "foo/*/bar"? These are allowed
in XSD's restricted XPath, but for YANG leafrefs it could lead to
nodesets containing leaves of different data types.

> 
> The value of an instance-identifier is an absolute path
> expression representing one conceptual node in the value tree.

What is the value tree (= "data tree" in YANG terminology) if an i-i
leaf occurs in a notification or RPC?

I understand it is an analogy of MIB instance identifiers, but what are
actually their use cases in the context of NETCONF/YANG?

> The prefixes are relative, so comparing instance-identifiers
> is an implementation detail, i.e., not strcmp().
> 
> I find it much easier to conceptualize YANG by thinking
> of how it would be implemented.  Imagine a tree of
> all available objects (rpc, notification, data-def-stmt).
> Then imagine another 'mirror' tree, with zero or more instances
> of each object node.  It isn't really necessary to copy
> all the YANG defaults into the value tree, so some
> implementations don't.  (That's why we need with-defaults.)

Yes, I think it would help to use something like the model-view
paradigm. The model in our case would be the full data tree (including
all defaults) that allows for multiple views with different ways/levels
of default suppression. The model will then be a well-defined and
implementation-independent XML document that the XPath expressions
always refer to.

In particular, for the YANG fragment

container ccc {
    leaf foo {
        type int8;
        default 42;
    }
    leaf fooref {
        type leafref {
            path "../foo";
            require-instance true;
        }
    }
}

this will then be a valid configuration view:

<ccc><fooref>42</fooref></ccc>

(because "foo" exists in the model with the default value of 42). 

Lada

> 
> The <candidate> value tree doesn't have any config=false nodes in it,
> but the object tree has them, so implementing require-instance=false
> only requires some special code -- just a major XPath implementation
> requirement to process the internal object tree, not some
> XML instance document.  It would be really inefficient to
> process XPath by creating an XML document, so it is more
> likely the value tree will be processed directly anyway.
> 
> Then there is the issue of deleting invalid config leafrefs
> when the non-config pointed-at leaf changes value.
> This is a problem for implementors.  I was thinking it was OK
> to leave the invalid config leafref in <running>, but what
> about <startup>?  Either direct via <copy-config> or
> indirect via mirroring, the invalid leafref will end up
> in the <startup> config, causing a problem later.
> 
> Removing the leafref may cause more problems than leaving it there,
> due to must, when, mandatory, min-elements statements.
> 
> IMO, config leafrefs are not very important to have,
> except as foreign keys.  But the problem doesn't
> go away for foreign keys, so might as well support #4.
> 
> SMIv2 can have simple INDEX clause because all the leaf names
> must be unique.  YANG would need to specify the schema path
> as follows:
> 
>     container interfaces {
>        list interface {
>           key name;
>           leaf name { ... }
>           leaf ifIndex {
>             // what to do about read-only ifIndex?
>             // should that be supported? IMO, no
>           }
>           ...
>        }
>     }
> 
>     list oldIfEntry {
>        key "/interfaces/interface/ifIndex";
>        // no leaf-stmt for ifIndex
>        leaf foo {}
>     }
> 
>     list extOldIfEntry {
>        key "/interfaces/interface/ifIndex localIndex";
>        // no leaf-stmt for ifIndex
>        leaf localIndex {}
>        leaf foo {}
>     }
> 
> Note how a local key is also a valid path expression,
> consistent with the foreign keys?
> 
> IMO, this would eliminate the need for config leafrefs,
> and it is more direct.  The SMIv2 'copy-fooIndex"
> approach is too cut-and-paste.  If you want a foreign
> key, then it should be specified in the key-stmt.
> Mixing foreign and local keys from the same namespace
> would require some name collision checking, but
> the YANG compiler does that already.
> 
> 
> 
> >...
> 
> > Tom Petch
> >> /martin
> > 
> > 
> > 
> 
> Andy
> 
-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 01 Jun 2009 10:25:24 +0200 (CEST)

> nodesets containing leaves of different data types.

These are not allowed in 'path' (see 'path-stmt' in the grammar).

> leaf occurs in a notification or RPC?

Yes, it needs to be specified.  The intention is that such an
instance-identifier refers to state or config data.

> actually their use cases in the context of NETCONF/YANG?

When you need a reference to some unknown data in the tree.  An
example from an RPC is <error-path>.  In a data model you might use it
in an access control model.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 01 Jun 2009 11:37:19 +0200

> These are not allowed in 'path' (see 'path-stmt' in the grammar).

I see, but the text is less precise, so it should refer to the ABNF.

Are the equality tests supposed to be performed as in XPath or using
value-space values?

I still think it would make sense to use XPath 1.0 or even XPath 2.0
expressions (but in each case exactly following the spec) for 'must' and
'when' and have YANG-specific path expressions for the rest, because the
latter is in fact a very limited subset of XPath but on the other hand
introduces certain syntactic and semantic differences (or such
differences would be useful). Also, the "YPath" expressions can be made
mandatory for all implementations whereas general XPath needn't.

Interestingly, the upcoming XSD 1.1 spec introduces assertions, a
concept quite similar to 'must' - they are XPath 2.0 expressions but can
only see the subtree of the node where they are specified.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 02 Jun 2009 16:41:31 +0200

> in an access control model.

Another example is the partial-lock reply or the data-model in the monitoring about partial-lock.

Also I think we SHOULD have a mechanism to address/reference an arbitrary bit of YANG data, and 
store this reference in a compact way.

Balazs

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 04 Jun 2009 10:09:37 +0200

Hello,
I really liked Andy's varbind idea. Can we have this for notifications? It is simple, elegant 
and solves a real use-case. It will result in much less confusion then understanding leafrefs 
in notifications, it is also much more compact especially for lists with multiple keys or lists 
within lists.

Balazs

Andy Bierman wrote:
> (Think I posted this 2 or 3 times already.
> 
> 
>   notification foo {
> 
>     varbind a {
>         // 5 clauses, path mandatory, showing the defaults
>         path "/interfaces/interface/ifMtu";
>         status current;
>         description "this is like an SMIv2 OBJECTS entry";
>         reference "...";
>         mandatory false;
>     }
> 
>     varbind b {
>         path "/interfaces/interface/ifInOctets";
>         mandatory true;
>     }
> 
>     leaf local-var {
>         description
>           "this is likse an SMIv2 a notify-only data definition.";
>         type string;
>     }
>   }
> 
>   <notification>
>      <foo xmlns:if="...">
>         <eventTime>...</eventTime>
>         <a>
>            <name>
>              /if:interfaces/if:interface[if:name='eth0']/if:ifMtu
>            </name>
>            <value>1500</value>
>         </a>
>         <b>
>            <name>
>              /if:interfaces/if:interface[if:name='eth0']/if:ifInOctets
>            </name>
>            <value>38765552</value>
>         </b>
>         <local-var>
>             interface eth0 status string inserted here
>         </local-var>
>      </foo>
>   </notification>
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 4 Jun 2009 12:44:12 +0200

On Thu, Jun 04, 2009 at 10:09:37AM +0200, Balazs Lengyel wrote:

> I really liked Andy's varbind idea. Can we have this for
> notifications? It is simple, elegant and solves a real use-case. It
> will result in much less confusion then understanding leafrefs in
> notifications, it is also much more compact especially for lists
> with multiple keys or lists within lists.

There are many questions that need to be asked about this new feature
(and let us be clear that this is a new feature), such as:

a) Can the path point to arbitrary nodes or just leafs?

b) Can this new feature be used in other contexts, e.g., operation
   (unfortunately called rpcs), perhaps even in the data tree?

c) What are the reason for allowing/disallowing this feature in
   different YANG contexts?

d) Is it possible to define a grouping using existing YANG constructs
   that essentially provides you the name/value pair you are looking
   for with existing mechanisms? If not, why not and can this be
   fixed?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 04 Jun 2009 12:49:37 +0200 (CEST)

> (and let us be clear that this is a new feature), such as:

Yes, and as we think more and try to document it (and implement it!)
we will find new questions.  I strongly prefer to postpone this new
feature.  If we keep the current leafref and later find a beautiful
way to handle notifications, well the worst thing that happened is
that we get a deprecated use case for leafrefs.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 04 Jun 2009 05:18:46 -0700

> that we get a deprecated use case for leafrefs.

We can leave this out, and wait until later.
That doesn't mean leafref is going to work
for notifications.  Leafref is a mess.

Andy