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

Re: Draft EOS minutes

> If you are anyone else would like to work on a solution, I suggest
> that you grab the NET-SNMP source code (or other SNMP agent
> source code, but open source would be better) and work out the
> impact any change would be on the agent. Yes, first the agent.
> Then the number of messages sent over the network. And finally
> the impact on the manager app.

Right - but I was first trying to probe if anyone was trying to follow this or
similar idea. For example, someone could comment that this would be probably
unfeasible in practice. Or very easy to accomplish.

> PS Marek, please do not be discouraged by my comments. There has already
>    been much work in this area. There have been several proposals that
>    are optimizing the inappropriate parts. Repeat over and over
>    again. Reduce CPU and memory utilization in the managed system,
>    followed by network traffic. If you do so, then you will have
>    a winning solution. Optimize for well designed management apps.

Anyone who joins this list has a lot of to learn. Perhaps I should keep myself
from posting before I get familair with all these ideas - after a few years of
reading various proposals ;-). The archive available on the server is not long
enough - I was trying to review it before posting, but the log is quite short.

My question about the holes was related with Wes Hardaker's new draft
draft-hardaker-eos-oops-00.txt, which seems to be quite fresh. The reasons to
fill the holes are explained in the following way:

       When requests to GET, GET-NEXT, and GET-BULK data come back in a
       SNMP RESPONSE PDU, the data can be hard to organize back into a
       logical structure again.  Holes of data (a row that contains no
       data for a particular column) within SNMP Tables make processing of
       the data collected more tedious.  Additionally, GET-BULK responses
       interleave it's data, possibly with END-OF-MIB exceptions, which
       only adds further complexity to the data processing.

The explanations focus on processing on a manager side. In fact, I do not seem
any problem here. So, could I ask about the real reasons for filling the holes?
If the reasons are well-known, I think that new documents should explain them
shortly, and nobody would ask about them anymore.