[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: sub-tree filtering proposals



Title: RE: sub-tree filtering proposals

> -----Original Message-----
> From: Phil Shafer [mailto:phil@juniper.net]
> Sent: Wednesday, June 09, 2004 12:59
> To: Waters, Glenn [CAR:IO47:EXCH]
> Cc: Andy Bierman; Frank Strauß; netconf@ops.ietf.org
> Subject: Re: sub-tree filtering proposals
>
> "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