[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Draft EOS minutes
on the following....
At 04:59 PM 8/16/2002 +0200, Marek Malowidzki wrote:
>Thanks DaveS for these clarifications on the "holes issue". I think that newer RFCs or drafts should contain a few more lines of explanations.
>> So there's no requirement to check the index values - they're all
>> guaranteed to refer to the same row. And this varbind list can be
>> used immediately to retrieve the next row, without worrying about
>> getting things back into line again.
>However, I would not agree that there is no requirement to check the index
>values - in my opinion, a SNMP library that checks agent's responses should be paranoic here - and gurantee that the response is really the one that a manager expects and that it is completely correct. This approach allowed us to quickly detect bugs in our agent implementation.
Unless there is a "higher level library function" that is being used,
the "lower level functions" have no clue that a manager is retrieving
all rows of selected columns. (A "row" means the index values match.)
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.
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.)
2) the cost of adding such an operation is a BIG win for both
agent and management apps. When it is implemented, people
/david t. perkins