Subject: RE: sub-tree filtering proposals

From: "Glenn Waters" <[email-masked]>
Date: Fri, 4 Jun 2004 16:57:37 -0400

> -----Original Message-----
> From: Andy Bierman [mailto:[email-masked]]
> Sent: Friday, June 04, 2004 16:35
> To: Waters, Glenn [CAR:IO47:EXCH]
> Cc: Wes Hardaker; [email-masked]
> Subject: RE: sub-tree filtering proposals
> 
> At 01:23 PM 6/4/2004, Glenn Waters wrote:
> 
> >I guess the point around the XPath proposal has always been why don't we
> line up with an existing standard, even if we only select a subset of that
> standard. That way we get the best of both worlds -- we get just the
> features we want and we don't have to reinvent the wheel. Further, if at
> some point down the road we decide we want more powerful
> filtering/selection then we can go back to the trough and sip a bit more
> of the XPath juice.
> 
> There are two problems with this approach:
> 1) It might not be easy to get the WG to agree on a minimal subset

Like it's easy to get any IETF WG to agree to anything. Seriously, at least
with the XPath approach we have something that is already well defined to
select from. The current approach is us trying to define and understand
something new. Further, we have to "debug" the spec.

> 2) An "arbitrary" subset of Xpath isn't likely to be easily supported
>    by off-the-shelf Xpath tools

I suspect it will be easier to take open source and make it conform to the
NetConf "XPath" than it will be to create completely new code.

I've said my bit. If others are interested in the XPath approach then speak
up now. I also don't want to rehash the XPath discussion any more than I
just did in the last two emails.

Regards, /gww

---

From: "Glenn Waters" <[email-masked]>
Date: Tue, 8 Jun 2004 16:19:48 -0400

I'm happy with the set that is proposed. Provides enough power, is simple
enough, and it's in line with XPATH.

Regards, /gww 

> From: Juergen Schoenwaelder [mailto:[email-masked]]
> Sent: Saturday, June 05, 2004 07:46
> To: Andy Bierman
> Cc: [email-masked]
> Subject: Re: sub-tree filtering proposals
> 
> On Fri, Jun 04, 2004 at 01:34:55PM -0700, Andy Bierman wrote:
> 
> So here is a proposal. Netconf implementations must support filter
> expressions that are the following subset of XPATH expressions. The
> subset consists of the following features:
> 
> 1) Absolute and relative paths (where path elements are element
>    names):
> 
>    //users/user/name
>    /users/user/name
>    //name
> 
> 2) Element value selectors:
> 
>    //users/user/name
>    //users/user[name="fred"]
>    //users/user[name="fred"]/name
> 
> 3) Attributes selectors:
> 
>    //interface[@ifName="eth0"]
> 
> 4) Expressions may contain multiple path expressions, separated by
>    a | symbol
> 
>    //users/user[name="root"]/type | //interface[@ifName="eth0"]
> 
> This set of features covers all the examples Andy posted and thus seems
> to be sufficient. ;-) What it boils down to is to select stuff by path,
> element values and attribute values.
> 
> Sure, this needs to be written down more formally and in a way that is
> consistent with the XPATH specification. I am willing to give that a
> try if people can agree that this is indeed a reasonable XPATH subset
> that is easy to implement and serves our purpose.
> 
> /js
> 
> --
> Juergen Schoenwaelder		    International University Bremen
> <http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen,
> Germany
> 
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>

---

From: "Glenn Waters" <[email-masked]>
Date: Wed, 9 Jun 2004 13:48:14 -0400

> From: Phil Shafer [mailto:[email-masked]]
> Sent: Wednesday, June 09, 2004 12:59
> Cc: Andy Bierman; Frank Strauß; [email-masked]
> "Glenn Waters" writes:
> >It's not pointless. Some reasons that an XPath subset is useful are:
> >- compatability with full XPath which allows developers to learn one
> >set of filtering
> 
> ... and then be fustrated when the full xpath doesn't work....

I agree that they will be frustrated when the full XPath doesn't work. BUT,
will they be any less frustrated using a solution that we invent and that
has far fewer tools available?

Let's not call it XPath-lite then. Let's call it subtree filtering and it
will be an exact subset of the XPath spec that the NetConf group thinks is
useful. And, when we want to improve the subtree filtering in NetConf we go
back to the XPath spec and pick a few more interesting features to add to
the NetConf spec.

> >- a clean migration path from "XPath-lite" to "XPath-full"
> 
> I don't see this happening.  If you start with a subset and
> grow it over time, clients will never know what subset the
> device supports and will break on devices that don't match
> their requirements.  Given that high-end devices are likely
> to just pick up a full implementation (libxml2), the subset
> will be broken day one.  Even then, the ability of the
> device to implement arbitrary bits of XPath logic and
> expressions will be an immense and changing burden.  Unless
> we're all switching over to XML databases on the device,
> the act of doing something like:
> 
>    following-sibling::security-associations[preceding-sibling::sa-tunnel-
> information[1]/sa-tunnel-index=$xpath-tunnel-number]
> 
> won't be simple.

I don't believe that growing this over time is any more an issue than when
we make other protocol changes. We have rule and guidelines that we follow
when we change protocols (look at SNMP v1/2/3 for example). When we improve
the subtree filtering in a new revision of the protocol the protocol spec
will define exactly what you can do and will define how to differentiate
versions of the protocol. Oh yeah, the new subtree filtering will just
happen to look like a subset of XPath -- but we don't need to tell anyone
that.

> Thanks,
>  Phil

Regards, /gww