Subject: [Netconf] XPath in RFC 4741

From: Andy Bierman <[email-masked]>
Date: Wed, 26 Nov 2008 07:42:09 -0800

Hi,

The details on XPath filtering in 8.9.5.1 are not
that clear.

There is only a request in the example, but no reply:

      <rpc message-id="101"
           xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
        <get-config>
          <source>
            <running/>
          </source>
          <!-- get the user named fred -->
          <filter type="xpath" select="top/users/user[name='fred']"/>
         </get-config>
      </rpc>

Note the bug in the example -- the select string should start
with an absolute-path (/top instead of top).  Note the lack of
namespace declarations also.

Is this the correct reply?  Does the node-set result get
expanded back to root (A), or just encoded as a node-set (B)?

(A)

    <rpc-reply message-id="101"
           xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
        <data>
            <top>
                <users>
                    <user>
                        <name>fred</user>
                        <address>...</address>
                        <email>...</address>
                    </user>
                </users>
            </top>
        </data>
    </rpc-reply>

(B)

    <rpc-reply message-id="101"
           xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
        <data>
            <user>
                <name>fred</user>
                <address>...</address>
                <email>...</address>
            </user>
        </data>
    </rpc-reply>

What about something like select="//name"?

(B)
    <rpc-reply message-id="102"
           xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
        <data>
            <name>fred</name>
            <name>barney</name>
            <name>eth0</name>
            <name>eth1</name>
        </data>
    </rpc-reply>

Andy

_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 26 Nov 2008 16:59:55 +0100 (CET)

Andy Bierman <[email-masked]> wrote:
> with an absolute-path (/top instead of top).

Hmmm.. while I agree that the example should use "/top/...", I think
it is legal to do "top/..." - this will then be evaluated relative to
the context node which is the conceptual <config> node.

> Note the lack of

Yes, now added to our list of things to fix.

> expanded back to root (A), or just encoded as a node-set (B)?

IMO and IMI (in my implementation) it must be A.  We want the xpath
notation to work as the subtree filter, and we want the returned
instance document to be a proper subset of the complete get-config
output.  (imagine what the XSD to validate (B) would look like...)

>            xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

With (A) you'd get:

  <data>
    <top>
      <users>
        <user>
          <name>fred</name>
        </user>
        <user>
          <name>barney</name>
        </user>
      </users>
    </top>
    <interfaces>
      <interface>
        <name>eth0</name>
      </interface>
      <interface>
        <name>eth1</name>
      </interface>
    </interfaces>
  </data>

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 26 Nov 2008 16:59:55 +0100 (CET)

With (A) you'd get:

  <data>
    <top>
      <users>
        <user>
          <name>fred</name>
        </user>
        <user>
          <name>barney</name>
        </user>
      </users>
    </top>
    <interfaces>
      <interface>
        <name>eth0</name>
      </interface>
      <interface>
        <name>eth1</name>
      </interface>
    </interfaces>
  </data>

/martin

---

From: Tomasz Mikolajczyk <[email-masked]>
Date: Wed, 26 Nov 2008 17:11:24 +0100

Hi,

>           xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

Such response is inconsistent with the subtree filtering rules and
rather should be:

Regards,
Tomasz Mikolajczyk

The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s).
Please direct any additional queries to: [email-masked].
Thank You.
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Tomasz Mikolajczyk <[email-masked]>
Date: Wed, 26 Nov 2008 17:11:24 +0100

Hi,

Regards,
Tomasz Mikolajczyk

---

From: Andy Bierman <[email-masked]>
Date: Wed, 26 Nov 2008 09:12:28 -0800

> Such response is inconsistent with the subtree filtering rules and

Where does it say in 4741 that XPath filtered output
looks the same as subtree-filtered output?

RFC 4741 seems to say "use XPath and do what XPath
says to do".  That was the intent of the WG at the
time it was written.

It seems to me that XPath 1.0 does not return all
the ancestor nodes in a node-set result, but rather
the requested nodes.

The RFC does not say what to do if the select expression
is not a node-set, but another result type (string, boolean
or number).  I assume an empty response will be given in those
cases.

IMO, this is a serious issue.
One could argue that off-the-shelf XPath tools
are rendered useless if the agent returns (A)
instead of (B).  I can see how most

XPath is intended to be used in some application context,
where something is being done to the result nodes.
The natural NETCONF application is 'xedit':

    path = "/interfaces/interface[name='fred']/mtu"
    confignode = xget(select=path)
    if confignode < 1518:
        confignode = 1518
        xedit(select=path, operation='replace', value=confignode)

In this hypothetical application, it makes much more sense to
do what XPath says instead of making up rules about returning
all the ancestor nodes.

The xedit syntax does not have to be aligned with
the XPath filtered retrieval output, but it makes code easier
for some things (and harder for others). XPath set is another
power saw that must be used really carefully:

   xedit(select="/interfaces/interface/mtu", value=1518)

Or even:

   lockid = partial-lock(select="/interfaces/interface/mtu")
   if lockid:
       xedit(select="/interfaces/interface/mtu", value=1518)
       partial-unlock(lock-id)

Andy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 26 Nov 2008 09:12:28 -0800

Or even:

Andy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 26 Nov 2008 10:37:34 -0800

> output.  (imagine what the XSD to validate (B) would look like...)

Then this needs to be documented in 4741-bis

Andy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 26 Nov 2008 10:37:34 -0800

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 26 Nov 2008 21:32:23 +0100 (CET)

> looks the same as subtree-filtered output?

It doesn't but note that you use the term "filtered output".  There
are two ways to *filter* the output.  Subtree and XPath.  I think the
result should look the same regardless of which filter mechanism was used.

[I know that this exact issue has been discussed on the ML, but I
could not find a reference right now.]

> the ancestor nodes in a node-set result, but rather

Absolutely.  Note that it returns the *nodes* in the tree only.  XPath
itself does not - by design - talk about what to do with these nodes.
That it is up to the application which uses XPath to define.  The
application in our case is NETCONF.

[...]

> where something is being done to the result nodes.

So you say the same thing as I did above.

> do what XPath says instead of making up rules about returning

But XPath doesn't say anything about what to do with these nodes!

If you use XPath filters to search the data store for matching
instances, you definitely need the entire path including key values.
For example:

# netconf-console --get-config \
      --xpath '/aaa/authentication/users/user[gid="100"]'/gid

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
  <data>
    <aaa xmlns="http://example.com/aaa">
      <authentication>
        <users>
          <user>
            <name>admin</name>
            <gid>100</gid>
          </user>
          <user>
            <name>oper</name>
            <gid>100</gid>
          </user>
        </users>
      </authentication>
    </aaa>
  </data>
</rpc-reply>

This is much easier to do in scripts that constructing the equivalent
subtree filter.  And XPath can of course do much more than subtree
filters anyway.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 26 Nov 2008 21:32:23 +0100 (CET)

[...]

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 26 Nov 2008 14:12:23 -0800

Martin Bjorklund wrote:
>> In this hypothetical apFrom [email-masked]  Wed Nov 26 14:12:31 2008
Date: Wed, 26 Nov 2008 14:12:23 -0800
From: Andy Bierman <[email-masked]>
To: Martin Bjorklund <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] XPath in RFC 4741
Sender: [email-masked]

Martin Bjorklund wrote:
>> In this hypothetiplication, it makes much more sense to

Right.  So NETCONF has to say what to do with them
for <get> and <get-config>.  All ancestor nodes
need to be returned,  and for all ancestor-or-self nodes that
represent a list with a key, all key leafs must be present
as child nodes of each list.

>       --xpath '/aaa/authentication/users/user[gid="100"]'/gid

There are searches that the bare node-set would be fine,
since the manager knows what it asked for.  There are lots
of searches (like your example) that can have multiple
hits, so the path to root is better.

> subtree filter.  And XPath can of course do much more than subtree

This is fine -- just document it in the NETCONF standard.
This is what I planned to implement until reading the XPath spec
several times, which made me think I should follow those rules
instead.

Andy

cal application, it makes much more sense to
> But XPath doesn't say anything about what to do with these nodes!

Right.  So NETCONF has to say what to do with them
for <get> and <get-config>.  All ancestor nodes
need to be returned,  and for all ancestor-or-self nodes that
represent a list with a key, all key leafs must be present
as child nodes of each list.

>       --xpath '/aaa/authentication/users/user[gid="100"]'/gid

There are searches that the bare node-set would be fine,
since the manager knows what it asked for.  There are lots
of searches (like your example) that can have multiple
hits, so the path to root is better.

> subtree filter.  And XPath can of course do much more than subtree

This is fine -- just document it in the NETCONF standard.
This is what I planned to implement until reading the XPath spec
several times, which made me think I should follow those rules
instead.

Andy

---

From: Washam Fan <[email-masked]>
Date: Thu, 27 Nov 2008 11:10:43 +0800

Hi,
> >           <filter type="xpath" 
> select="top/users/user[name='fred']"/>>          </get-config>
> >       </rpc>
> > 
The section 5.2 in RFC4741 says "NETCONF carries configuration data inside the <config> element that is spFrom [email-masked]  Wed Nov 26 19:11:28 2008
Date: Thu, 27 Nov 2008 11:10:43 +0800
From: Washam Fan <[email-masked]>
To: Martin Bjorklund <[email-masked]>
Priority: normal
Cc: [email-masked]
Subject: Re: [Netconf] XPath in RFC 4741
Sender: [email-masked]

Hi,
> >           <filter type="xpath" 
> select="top/users/user[name='fred']"/>>          </get-config>
> >       </rpc>
> > 
The section 5.2 in RFC4741 says "NETCONF carries configuration data inside the <config> element that is specificecific to device's data model." Shouldn't all configuration data be children of <config> element?

Washam

 to device's data model." Shouldn't all configuration data be children of <config> element?

Washam

---

From: Tomasz Mikolajczyk <[email-masked]>
Date: Thu, 27 Nov 2008 10:34:17 +0100

Hi,

> says to do".  That was the intent of the WG at the

Nowhere. NETCONF RFC is not precise in many places. Can you see any
advantages of such behavior when a server returns different output
format depending on the filter mechanism? IMO, this makes a client much
more complicated.

> or number).  I assume an empty response will be given in those

Please consider the following XML request:

<filter type="subtree">
    <top xmlns="http://example.com/schema/1.2/config">
        <users>
            <user>
                <name>fred</name>
                <surname/>
            </user>
        </users>
    </top>
</filter>

Assuming that it means asking about an surname attribute, an
application is requested only for this attribute and returns only its
value (for instance "Flinston") instead of the whole XML. There is no
need at all that server sends to the application the whole XML and the
application returns ready XML response. It's the NETCONF server task to
opaque the response according to the request (data model) and NETCONF
filtering rules. The device shouldn't know anything about the NETCONF
format.

>> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

Tomasz

---

From: Tomasz Mikolajczyk <[email-masked]>
Date: Thu, 27 Nov 2008 10:34:17 +0100

Hi,

<filter type="subtree">

Tomasz