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

Re: Draft EOS minutes

On Fri, 16 Aug 2002 10:53:12 -0700, "David T. Perkins"
<dperkins@dsperkins.com> said:
> [...] As Wes pointed out in previous email, writing a library to fix
> the result of a GETNEXT or even a GETBULK is not terribly difficult.
> But doing it in a way that is not wasteful does require some
> thought. But more importantly, coming up with a new operation that
> "fills holes" is a HUGE win for both the manager and agent.

Having written manager software that tries to make efficient use of
get-bulk, I strongly agree.  Not only is the code hairy, you are also
running into the question of selecting good max-repetitions (to reduce
the number of round trips to the agent, while at the same time
avoiding the waste of resources from "overshoot").  And I also
encountered bugs with SNMP agents in widely implemented router
software that simply generate incorrect responses to get-bulk (missing
some rows - this seems to have been fixed in recent releases of that
particular vendor).

> The biggest hurdles so far is convincing this WG that:
> 1) retrieving all rows but with selected columns of tables
>    is a common operation that is done by well designed
>    management apps. (Some people want to retrieve all columns
>    of a table instead of just selected columns. Retrieving
>    all is GROSSLY wasteful.)

Yes.  Also you often want to look at columns under different table
OIDs that share an index, such as, say, ifDescr (from ifTable) and
ifAlias (ifXTable).

Personally I would also care about the case when the application
doesn't want all rows, but only rows in a specific index range
(emphasizing Dave's point above, when I talk about "rows" I always
imply that the application MUST be able to specify which columns it is
interested in, and it MUST be possible for the columns to belong to
separate table OIDs as long as they are indexed identically).

To efficiently support such row subsets, one could either devise a
DISMAN-like filter mechanism (maybe there already is), or integrate
index range specifications into the new protocol operations.  At least
for the common case where the "interesting" indexes are all indexes
between a lower and an upper bound, the latter should be quite simple.

> 2) the cost of adding such an operation is a BIG win for both
>    agent and management apps. When it is implemented, people
>    will see.