Re: snmpv2 Will it flood us or be slow

[Frank Kastenholz <[e-mail]>]

 > My view of V2 is that it is more like the Social Security
 > Administration -- an administrative nightmare that has far more
 > administrative framework that is reasonable to do a simple job.

Karl,

While I have not done any SNMPv2 implementations, I've done SNMPv1
implementations, including an implementation of the old SNMPv1
plus Security (for newcomers -- it never went anywhere).
Administratively, SNMPv1+Security is very close to what SNMPv2 is.
It requires (or can use) the same basic "stuff". And yes, if you
want to fully use all the features of SNMPv1+Security it was horrible
to administer (much less implement). It seems to me that IF you want
all the things in V2 THEN you must "pay the price" however, if you do
not want some stuff then you do not need to configure that stuff.
Furthermore, if your agent-system does not need something then do not
implement it and constrain the configuration interfaces (MIBs, consoles,
etc) accordingly -- if you feel that you do not need privacy in your
agent then A) do not implement DES and B) don't allow someone to
set the partyPrivProtocol to anything other than noPriv".


 > My concern is that the management of SNMPv2 itself will turn out to be
 > painfully large; that a significant part of the work of managing a
 > network will be used to manage the management system.

If and Only If you want to use all the goop.

 > Indeed, I have substantial concerns that SNMPv2 party mib
 > misconfigurations and mis-implementations will result in a overall
 > *decrease* in network stability.

Yup -- and filling out your tax forms incorrectly will result in an
overall decrease in your financial stability :-) The point is that
we have a need for powerful capabilities -- privacy, authentication,
views, access policies, and so on. Now, ASSUMING that this need is
genuine then we need the facilities and capabilities in SNMPv2
configuration. 

 > I have already seen network gear fail because of SNMPv1 implementation
 > bugs.  So I am not optimimistic.

Implementation is different than operation/configuration. 

--
Frank Kastenholz
FTP Software
2 High Street
North Andover, Mass. USA 01845
[phone]