Re: snmpv2 Will it flood us or be slow

[[e-mail]]

 >> What we are looking at with v2 is somthing that - while
 >> it addresses shortcomings in v1 - requires drastic increases in
 >> storage, processing power and developer time.
 >
 >   Many of the benefits of SNMPv2 can be gained with very little cost.

Extremely true.  However...

 >   Utilizing noAuth/noPriv communication
 >   does not greatly increase resource costs while it does provide the basis

If an agent were to solely utilize noauth/nopriv then it would not
have any means to authenticate set requests.  And such authentication
was perhaps the #1 reason why we went to V2 in the first place.

In other words, to get the single most valuable part of V2, the
ability to do "safe sets", you must increment the size of the agent by
a significant factor and enter the brave new world of the party mib,
clock synchronization, and such.

Much of the way that SNMPv2 is written is such that it is rather
difficult to unbind the various parts and select the good from the
heavy.  However, the following come to mind as easily severable from
the party mib and the administrative framework:

	- The improved formalisms of mib and agent definitions
	- The basic mechanisms of the manager to manager mib (albeit the
	  routing mechanism for traps would have to be reworked if separated)
	- GetBulk
	- Informationrequest
	- Improved PDU structure so that errors don't necessarily cause total
	  query failure.
	- 64 bit numbers
	- Row creation
	- testandincr
	(and the list surely goes on) 

And even without any of the V2 security mechanisms, one can always
define a MIB variable so that its visible value is encrypted, thus
ensuring privacy of queries, and by adopting the V2 XOR idea, you can
even update it with privacy.

The question in my mind is whether V2 ought to be reworked to remove
the burden of the administrative framework.

Yes, the framework does contain many good ideas.  And the party mib
data structures are extremely clever.  And it is nice that we have
space for infinite expansion to the degree that everyone on earth can
have his/her own authentication protocol.  But there is a limit on how
much stuff one should pile into the protocol and its infrastructure.
It is this same "feature-itis" that burdened CMIP.

I submit that like most healthy plants in the garden, a heafty pruning
will do SNMPv2 a great deal of good.

			--karl--