RE: sub-tree filtering proposals

["David Harrington" <dbharrington@comcast.net>]

Hi,

From a vendor-neutral application development standpoint (and presumably
from a vendor-neutral operations standpoint), a combination of
mandatory/optional filtering features will need to be supported to manage a
heterogeneuos network of devices, and it will be much simpler to support
full Xpath and a well-defined subset of Xpath than it would be to support
full Xpath plus another filtering mechanism. 

Would operators prefer to have two mechanisms to learn, or just one
mechanism with two well-defined variations?

Dave Harrington
dbharrington@comcast.net

> -----Original Message-----
> From: owner-netconf@ops.ietf.org 
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Frank Strauß
> Sent: Wednesday, June 09, 2004 4:35 PM
> To: j.schoenwaelder@iu-bremen.de
> Cc: netconf@ops.ietf.org
> Subject: Re: sub-tree filtering proposals
> 
> 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/>
> 



--
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/>