Subject: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-yang-xpath-extensions-00.txt

From: Martin Bjorklund <[email-masked]>
Date: Fri, 18 Oct 2013 20:54:49 +0200 (CEST)

Hi,

I have posted a draft that introduces a YANG extension statement to
define new XPath functions.  It also defines a couple of XPath
functions, for some built-in YANG types.  Specifically, it solves the
problem of comparing identities in must/when expressions.

/martin

Subject: New Version Notification for draft-bjorklund-netmod-yang-xpath-extensions-00.txt
From: [email-masked]
To: Martin Bjorklund <[email-masked]>
Date: Fri, 18 Oct 2013 11:52:03 -0700

A new version of I-D, draft-bjorklund-netmod-yang-xpath-extensions-00.txt
has been successfully submitted by Martin Bjorklund and posted to the
IETF repository.

Filename:	 draft-bjorklund-netmod-yang-xpath-extensions
Revision:	 00
Title:		 YANG XPath Extensions
Creation date:	 2013-10-18
Group:		 Individual Submission
Number of pages: 20
URL:             http://www.ietf.org/internet-drafts/draft-bjorklund-netmod-yang-xpath-extensions-00.txt
Status:          http://datatracker.ietf.org/doc/draft-bjorklund-netmod-yang-xpath-extensions
Htmlized:        http://tools.ietf.org/html/draft-bjorklund-netmod-yang-xpath-extensions-00

Abstract:
   This document introduces new YANG extension statements for defining
   XPath functions.  These functions can be used in XPath expressions in
   YANG modules and in NETCONF XPath filters.  A set of YANG-specific
   XPath functions are also defined.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Andy Bierman <[email-masked]>
Date: Fri, 18 Oct 2013 16:37:04 -0700

Hi,

I really like this draft.
I think more powerful XPath would make writing
must/when/select expressions less error-prone, and easier to read.

I thought there was going to be more XPath functions defined.
We have a couple:

   boolean module-supported(string)  // module-name

   boolean feature-supported(string, string) // module-name, feature-name

Andy

On Fri, Oct 18, 2013 at 11:54 AM, Martin Bjorklund <[email-masked]> wrote:

> ---------- Forwarded message ----------
> Cc:
> Subject: New Version Notification for
> draft-bjorklund-netmod-yang-xpath-extensions-00.txt
>
> URL:
> http://www.ietf.org/internet-drafts/draft-bjorklund-netmod-yang-xpath-extensions-00.txt
> Status:
> http://datatracker.ietf.org/doc/draft-bjorklund-netmod-yang-xpath-extensions
> Htmlized:
> http://tools.ietf.org/html/draft-bjorklund-netmod-yang-xpath-extensions-00
>
>
> Abstract:
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 25 Oct 2013 16:09:32 +0200

> must/when/select expressions less error-prone, and easier to read.

Indeed, this is a very useful work.

>    boolean feature-supported(string, string) // module-name, feature-name

Hmm, XPath generally works with a concrete XML document, so it would be better to expose this info as standard state data - ietf-netconf-monitoring can already give supported modules, right?

I think the example in sec. 2.2 uses wrong namespace for the "reverse" function, it should be "ex1" and not "ex2".

If the server doesn't advertise the "ietf-yang-xpath-extensions" module, can other advertized modules still use new XPath functions in "must" and "when", if they import that module?

Lada

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

---

From: Andy Bierman <[email-masked]>
Date: Fri, 25 Oct 2013 07:51:03 -0700

On Fri, Oct 25, 2013 at 7:09 AM, Ladislav Lhotka <[email-masked]> wrote:

> Hmm, XPath generally works with a concrete XML document, so it would be
> better to expose this info as standard state data - ietf-netconf-monitoring
> can already give supported modules, right?
>
>
The ietf-netconf-monitoring module is optional to implement.
There are no features listed in that data structure, and writing XPath
to match against <capability> strings is difficult (also optional to
implement).

> I think the example in sec. 2.2 uses wrong namespace for the "reverse"
> function, it should be "ex1" and not "ex2".
>
> If the server doesn't advertise the "ietf-yang-xpath-extensions" module,
> can other advertized modules still use new XPath functions in "must" and
> "when", if they import that module?
>
> Lada
>
> >
> >
> > Andy
> >
> >
>

Andy

> >> A new version of I-D,

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 25 Oct 2013 17:01:54 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> Hmm, XPath generally works with a concrete XML document, so it would be better
> to expose this info as standard state data - ietf-netconf-monitoring can
> already give supported modules, right?
> 

Right, and the function is actually called string-reverse.  I have
fixed this.

> If the server doesn't advertise the "ietf-yang-xpath-extensions" module, can
> other advertized modules still use new XPath functions in "must" and "when", if
> they import that module?

Yes.  Note that all XPath expressions are conceptual.  If a server
claims that it implements a module that uses such an xpath function,
it must implement the contraint somehow.  It doesn't have to use an
XPath evaluator; it can be implemented in code - just like ane
constraints defined in description statements.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 25 Oct 2013 18:15:45 +0200

> constraints defined in description statements.

Yes, but one has to be careful with revisions - sec. 10 in RFC 6020 allows new extensions in an updated module, but I think in this case it could be dangerous because the server cannot easily ignore unknown functions appearing in XPath expressions.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 25 Oct 2013 19:24:45 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> Yes, but one has to be careful with revisions - sec. 10 in RFC 6020 allows new
> extensions in an updated module, but I think in this case it could be dangerous
> because the server cannot easily ignore unknown functions appearing in XPath
> expressions.

You typcially do not just load a new module into a server; it needs
some instrumentation to be useful.  So a new revison that uses some
new XPath functions or not needs an implemention effort in the
server.

But maybe I misunderstood your concern?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 25 Oct 2013 11:33:42 -0700

On Fri, Oct 25, 2013 at 10:24 AM, Martin Bjorklund <[email-masked]> wrote:

> > >> other advertized modules still use new XPath functions in "must" and
> "when",
> > >> if
> > >> they import that module?
> > >
A YANG compiler that checks XPath can understand the  xpath-function
statement
and validate the XPath, even without instrumentation.

Some more comments:

sec 2 is a bit thin. It should say the entire normative deefinition
is in the YANG module, not sec. 2.

The document order of the xpath-argument statement is significant,
since XPath functions are passed an ordered parameter list.

IMO the extension statements should be in a separate module
because they will be stable.  The library of external xpath-function\
statements is not likely to be stable.

This document has the mandatory set of XPath functions,
so WG consensus will be needed. The current set is somewhat limited.

I am not sure this example does what it says:

   leaf mgmt-interface {
         type leafref {
             path "/interface/name";
         }
         must 'yangxp:deref(.)/../enabled = "true"' {
             error-message
                 "The management interface cannot be disabled.";
         }
     }

The must-expr says that at least 1 interface (derived from the nodeset
of /interface/name leafs) must be enabled. It does not say the interface
indicated by the value of mgmt-interface must be enabled.
The path-expr is "/interface/name" not "/interface/name[.=current()]".

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 25 Oct 2013 21:06:48 +0200

> But maybe I misunderstood your concern?

Sec. 6.3.1 says:

If a YANG compiler does not support a particular extension, which appears in a YANG module as an unknown-statement (see Section 12), the entire unknown-statement MAY be ignored by the compiler.

So my point here is that while ignoring extensions is easy because they are self-contained, it is not the case for extensions in XPath expressions. But maybe it is not an issue.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 31 Oct 2013 20:00:37 +0100 (CET)

Hi,

> is in the YANG module, not sec. 2.

Ok.

> since XPath functions are passed an ordered parameter list.

Yes, this should be clarified.

> statements is not likely to be stable.

Hopefully the function set defined here will be quite stable; it is
intended to define functions for core YANG features.  Functions
related to other features should be defined in specific modules.

> so WG consensus will be needed. The current set is somewhat limited.

This was intentional...

> "/interface/name[.=current()]".

So I have to explain this better.  The idea is that deref(X) follows
whatever X points to.  If 'mgmt-interface' is "eth0",
deref(mgmt-interface) returns the node set with the node
/interface[name="eth0"].

I also now realize that this example is a bit too simplistic; deref()
makes more sense when these are multiple connected leafrefs.

deref() is actually just syntactic sugar; the same thing can be done
with normal path expressions, but it can become pretty complex.  I
will try to explain this better in the draft, and add another example.

/martin