RE: support for new work

Hi,

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.

my $.02
dbh

> -----Original Message-----
> From: Andy Bierman [mailto:[email protected]]
> Sent: Friday, August 16, 2002 3:55 PM
> To: [email protected]
> Subject: support for new work
> 
> 
> Hi,
> 
> 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
> undesirable.
> 
> 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.
> 
> Andy
> 
>