[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Call for censensus on path forward
I'd like to see the WG focus on Wes's draft and would enjoy participating towards the resolution of
the issues and refining the ideas that currently exist as "broad strokes" in the -eos-oops-01 draft
and was refraining from discussion until consensus was achieved for a path forward.
Having said that, there are quite a few aspects of filtering that need to be considered. For
example, snce the proposal is object-oriented, it may not make sense to try to attempt "join"
operations (e.g. fetch object A where A.x .gt. <val1> and object B where B.y .gt. <val2> and A.z
Filtering might also include a means to selectively omit certain components of an object (resp.
certain columns of a row) from the response PDU. so that applications may omit the attributes from
the response for which no interest exists.
Ellison Software Consulting, Inc.
Robert Moore wrote:
> First the business part: I think the WG should focus on Wes's draft as the
> base, and merge in any unique ideas (like logical filter expressions) from
> Dave's draft. If we're going to muck with the PDU structure at all, then
> we should try to do a reasonably complete job of it.
> Regarding Wes's question about how rich to make filtering, I have what I
> think is a logically prior question: can we do *any* filtering that will
> really be useful? I'll construct a strawman argument that reaches the
> conclusion that we can't, since I think it will be instructive for people
> to say where they think the argument breaks down. Here it is:
> 1. Filtering is being introduced to solve the performance problem of having
> to retrieve all the rows of a really big table (i.e., lots of rows, not
> lots of columns), in order to get a relatively small number of rows that
> we're really interested in. (My understanding of the requirement for
> 2. We want any filtering solution to work for tables in existing MIBs.
> (Any eos solution that worked only for new MIBs wouldn't be very
> 3. Where filtering is really needed is when a management application needs
> to poll the same table repeatedly, especially if the polling needs to be
> done frequently.
> 4. Polling, especially if it's frequent, is interested in state data from a
> table, not in configuration data that rarely changes.
> 5. A large percentage of the state data in existing MIBs is in the form of
> counters. (Superficial examination - I haven't tried to compare with any
> precision the mix of counters, gauges, and state enumerations in existing
> 6. A single value of a counter is meaningless - to derive any meaning from
> a counter, you've got to take the delta of two values. (SNMP orthodoxy.)
> 7. A filter can only compare an asserted value to the single current value
> of a MIB object. (Obvious.)
> ERGO: A filtering solution cannot select table rows based on comparisons
> with meaningful values of a large percentage of the state data in the rows.
> If we want to achieve the effect of filtering on counter values, we need
> some sort of Disman solution like the script MIB, rather than just a new
> filter element in the SNMP PDU.
> The discussion might proceed in either (or both!) of two directions here:
> - Your argument is wrong, because one of the premises is wrong, or because
> the logic itself is flawed.
> - Your argument is correct, but it's still useful to pursue filtering
> because even though they're rare, gauges and state enums are important
> enough in existing MIBs to make it worthwhile to add a discrimination
> capability that works only for them. If this is what we do, though, then
> we'd better be very clear about what filtering can do, and what it can't
> Glenn, I know this may be jumping the gun a bit, by diving down into a
> technical discussion. But, hey, Wes did it first :-)
> Bob Moore
> Advanced Design and Technology
> Application Integration Middleware Division
> IBM Software Group
> Wes Hardaker
> <email@example.com To: "Glenn Waters" <firstname.lastname@example.org>
> t> cc: email@example.com
> Sent by: Subject: Re: Call for censensus on path forward
> 09/20/2002 11:10
> >>>>> On Mon, 16 Sep 2002 10:51:32 -0400, "Glenn Waters"
> <firstname.lastname@example.org> said:
> Glenn> The working group needs to come to consensus around which
> Glenn> problems that should be solved and which of the solutions below
> Glenn> best addresses those problems.
> Glenn> I will announce the summary of the consensus call one week from
> Glenn> today (Monday, September 23) *unless* there is still active
> Glenn> discussion which would preclude being able to make a reasonable
> Glenn> decision at that time.
> The deadline is coming up rather fast, and I think we should be
> hearing more voices of people that have read the drafts (authors
> excluded, we know what you'd (we'd) vote for). This WG greatly needs
> to hear the opinions of interested parties if any work is to go
> Personally, I've read all the drafts and there is good merit in all of
> them. Obviously, I'm biased toward the solution which I think is
> right (mine, of course ;-) but all the drafts are well worth reading.
> I decided personally to leave out logic expressions from the filtering
> in my draft solely because I didn't want to complicate the agent
> processing any further. David Perkin's has logical expressions in his
> draft (&& || ...) and I'm very interested in hearing whether people
> think this is a good thing or a bad thing, as it's a question I've
> been meaning to ask the WG but was waiting until after a direction was
> picked. (I'd add logical expressions in a different manner than David
> did, but it's the concept I'm curious if people want or not.
> Currently, my draft has an implicit AND operation on all filtering
> "The trouble with having an open mind, of course, is that people will
> insist on coming along and trying to put things in it." -- Terry