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

RE: proposed row ops requirements



hi

Juergen> If people do not want changes, then lets stay away from touching
Juergen> the protocol operations at all and lets just do things like OID
Juergen> compression that are purely an issue between the SNMP engines 
Juergen> involved and completely transparent to management applications
Juergen> and agent implementations.

We can't really do everything we want to do if we don't touch the protocol.

I haven't seen the concerns being voiced on the mailing list as resistance
to change, but rather an attempt to make sure that the costs of EOS changes
are proportional to the benefits we will get from them.

Juergen>Once again, I like to see this stated clearly in the requirements:
Juergen>
Juergen>(a) Make SNMP efficient so that retrieving a table with a few
hundred
Juergen>    entries is at least as fast as retrieving the same information
via
Juergen>    other channels (e.g. FTP or CLI).
Juergen>
Juergen>(b) Make the costs for implementing writable objects at least as
cheap
Juergen>    as implementing a CLI command or a Web interface.
Juergen>
Juergen>Actually, I would like to see that every proposed new feature has to
Juergen>prove how it helps to reach (a) or (b).

My problem with the way to (a) is written, is that I don't usually want the
entire table - I only want some of the columns.  If we focus on efficiency 
for getting the entire table, then we may not actually gain anything.  
If I get something 4 times more efficient, but I have to retrieve 4 times 
the information to use the feature, then I'm exactly where I started.

Sharon