Re: Call for censensus on path forward

HI Bob,

Thanks for the observations. Just like Wes, I came to a different
conclusion than you because I believe that one of your assumptions
is incorrect. Note, however, I do believe that filters allow
REALLY BAD (and dangerous) management apps to be written. And
will allow clueless management app developers to point a finger
of blame, when it is themselves who have the responsibility.

Comments inline below...
At 12:56 PM 9/20/2002 -0400, 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.
Can you and others tell us why. Is it because of the use of the title
"Object oriented PDUs", or is it some technical reason? Is it because
it includes SETs? Is it because it allows the iteration of rows in a
table to be done without regard to lexical ordering of index values?
Is it because the index values are returned separately instead of
encoded as an OID fragement?

>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
>filtering.)
Yes, that is it! Rows, not columns.

>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
>interesting.)
Yes!

>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.
No, I believe that filtering is needed only when
"values of items in a table changes very infrequently, and/or
instances are created or deleted infrequently". Plus, there is
no correlation that can be used to determine those instances.
I don't remember if you have heard me talk about the expected
lifetime of a value of management information. There is presently
no literature that I'm aware of on this topic. (If you know of
some, please send a pointer.) Simplified, one of the characteristics
of management info is what causes it to change values, and
the predictability and patterns of those changes. If you can
know those characteristics, then you can design your management
applications to retrieve data only after it changes. This has
very desirable consequences!

>4. Polling, especially if it's frequent, is interested in state data from a
>table, not in configuration data that rarely changes.
Yes, an important reason for polling is to determine state changes,
and more importantly those for which a management station needs
to take immediate action, such as obtaining more management info,
or changing a configuration.

>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
>MIBs.)
No, most (if not all) state data is ENUMs and Gauges.
Counters are statistics.

>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.)
Yes!


>7. A filter can only compare an asserted value to the single current value
>of a MIB object.  (Obvious.)
Yes, filters have no history.

>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
>do.

I hope this helped. And thanks again for your analysis.

Regards,
/david t. perkins