I'll respond as well.
My response is based more on gut feel than on a close technical analysis. I spent years working on the SNMP engine portion of a major management application, and there were certain things I found that were less than optimal.
My experience is with a tool that has an SNMP engine and multiple user applications that make requests of the engine. The interface to the engine is a protocol-independent request processor. So in my eyes, any proposal that requires the user to understand the intricacies of SNMP just won't cut it. The proposals of interest to me are those that can be largely hidden from the user within the SNMP engine.
I'm not convinced a mib to report snmp extended capabilities is important. Whether an operation is supported is only important if I want to use it. I can send the extended message to an agent once, and if it fails with an appropriate error code, I can note that it doesn't support that operation and not try again. This has state issues similar to SNMPv1's TOO-BIG error; if we find that it is a problem later, we can always do a mib later. First we should define some extended operations. I'd say we don't need to focus on this now.
Using mibs to collect data periodically looks as though it would be useful for applications that poll regularly. But I'm not convinced this is a high priority. I'd say we don't need to focus on this now.
I am interested in the OID compression/suppression proposals. They seem fairly easy to accomplish and yield an immediate benefit. SNMP is constantly being criticised by the flavor of the month competitive protocol for being too inefficient carrying all those long OIDs. We probably spend more time listening to the complaints than it would take to add OID suppression and compression to the message format. Let's correct the problem and improve the efficiency.
I agree with Andy; no opaques or otherwise complex-to-unpack data fields.
Wes Hardaker's proposal is the first proposal in a while that has caught my interest. I think it deserves more study by this WG.
I concur with Andy that the processing of existing operations should continue to work the way they do. New features should be available only to new operations. PDU suppression/compression should be able to be used by any message, but the "unpacking" of the PDU conceptually would occur by the message processing model before the snmp-application gets it, so the processing of the PDU remains unchanged.
Because networks now generally have high reliability, and because the emphasis on security has greatly increased and security protocols often deal with establishing secure sessions, I believe the single most important task of this WG should be to define how TCP can be used effectively as a supplementary transport to the basic UDP transport. Enabling sessions would permit the development of new authentication models for SNMPv3, to support centralized session-based authentication via RADIUS, Diameter, Kerberos, etc. The ability to "cache" session information could permit more efficient security processing and access control, especially for repetitive polling. Allowing the development of mibs that can contain large data fields, and messages than can contain lots of varbinds, will increase the usefulness of SNMP. I think the TCP transport is by far the most important evolutionary advancement for SNMP.
> -----Original Message-----
> From: Andy Bierman [mailto:firstname.lastname@example.org]
> Sent: Friday, August 16, 2002 3:55 PM
> To: email@example.com
> Subject: support for new work
> This email is intended to state my opinion on the new work proposals
> made to the EOS WG, because the WG Chair is trying to gauge consensus,
> and silence means no opinion.
> MIB proposals: I do not think any of the various MIB proposals
> should be pursued by this WG.
> OID optimizations: I favor protocol mechanisms for OID compression
> and suppression, because this would be a generalized solution.
> I do not support any solution which relies on opaque, packed
> OCTET STRINGs to achieve these goals, because an engine would
> not be able to generically unpack the data. There are also
> issues with holes in rows and MIB versioning that make this approach
> Protocol Operations: I support Wes Hardaker's proposal,
> Object Oriented PDUs for SNMP. There are a lot of details
> to work out, but it looks promising for supporting SMIv3
> hierarchical data structures, as well as addressing some
> current inefficiencies in the protocol.
> Backward and Forward Compatibility: I think new features should only
> be supported in new protocol operations because this allows
> the most flexibility to do proper design. Retrofitting existing
> protocol operations with new features will result in hacks,
> and create more implementation complexity than it solves.
> Old protocol operations should continue to be supported,
> exactly as currently defined.
> Transport: This new protocol version (with object oriented
> protocol operations) should be run over UDP or TCP. No
> complex hacks should be added to support large PDU fragmentation
> if UDP is used. Large PDUs should only be supported over TCP.
> Session based features (e.g., security, compression) should
> be considered for the TCP version.