Re: sub-tree filtering proposals

[Frank Strauß <strauss@ibr.cs.tu-bs.de>]

On 09. Jun 2004, at 15:42, Juergen Schoenwaelder wrote:

> [...]
> First, I believe a subset of XPATH (not an adapted subset) is still 
> better
> than something homegrown.

I agree.

> (The most vocal members of the WG do not seem
> to buy full XPATH as a requirement.)

Maybe the reason is, that there are still not many operators and 
developers
of manager software raising their voice. (I'm just guessing.)

>  Personally, I believe that the
> operators using netconf will ask for full XPATH anyway, so the subset
> requirement will likely not be a real issue in practice.

However, a netconf standard should have the purpose to come to a common
sense on what agents support and what managers can rely on. If we have
reasons to assume that operators and others will ask for full XPath (and
I do think so, too) we should address this need *now* (and BTW not in a
subsequent revision as long as we did not even find rough consensus for
the initial revision).

> I think the general idea is that boxes announce whether they do 
> support full
> XPATH or just a reduced subset. I do not see that there is anything 
> wrong
> with this.

In general, I agree.

> The alternative, a home grow filter format which implementations are
> required to support, seems worse to me. Bottom line is that either
> (a) the netconf WG makes a decision to require XPATH full stop, or
> (b) the WG makes a decision to support XPATH and require a subset of 
> it, or
> (c) the WG makes a decision to support XPATH and to require another
>     home-grown filter format.
>
> Since (a) does not seem to be getting WG consensus, I believe (b) is 
> the
> best we can do.

First to say, my preference would be (a). If there are reasons against 
(a)
(I guess, I missed a discussion on this), I would also favor (b) over 
(c).


On 09. Jun 2004, at 18:22, Juergen Schoenwaelder wrote:

> > The advantages of the proposal above are:
> >   - subtree filtering is easy to implement on agents;
> >     only XML parser needed, not XML and Xpath parsers
>
> Come on, parsing Xpath expression is really not that complicated. I am
> really wondering on which basis you calculate how much you save on
> embedded boxes...

I would also like to see a clear reasoning, not just on the pure code
size. These aspects come to my mind:

- We should take into account that many XPath implementations exist.
  My expectation would be that deriving a subset implementation would
  need some time (not much, but more that just picking an existing
  full implementation) just to shrink the code size for a small
  percentage.
- An XPath subset would most probably *not* reduce CPU load compared
  to full XPath.
- Building a new XPath (subset) implementation from scratch could be
  required by some vendors' policies. A full implementation would fit
  in the idea of reusability, while a netconf subset would be limited
  netconf only.
- Same is true for a home-grown filtering mechanism.
- A less powerful filtering mechanism would cause more network traffic
  and thus increase network and CPU load, since managers would have
  to retrieve more data than required if the required filtering cannot
  be done on the agent side.

Furthermore, nowadays even the cheapest APs, switches and other devices
come with an HTTP server, SSH, SNMP, syslog, and much more stuff. 
Firmware
resides in relatively large, however cheap enough flash memory. The ease
of usability and manageability through such features often makes it an
attractive and successful product. This generally weighs more than the
costs to develop and build such features. At least, this is my 
impression.


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>