Re: Draft EOS minutes
"David T. Perkins" <[email protected]>
| Newsgroups | gmane.ietf.eos |
|---|---|
| Message-ID | <[email protected]> |
hi, 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. > >Marek 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 will see. Regards, /david t. perkins