Re: snmpv2 Will it flood us or be slow

[[e-mail]]

Hi -- Despite some of my statements, I really am a fan of V2.  I sort
of look at V2 as the artist did the block of marble -- somewhere
inside that large block of stone is a beautiful statue waiting to be
exposed.  We just need to chip off the excess...

 >    > 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.
 >
 >   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.

If you draw a graph of agent complexity versus agent capabilitie, you
won't see a nice straight line.  Rather you will see a major step
function.  If you want authenticated transactions (the lack of which
is the purported reason why few SET requests have ever been issued in
real-life) then there is an extremely large increment in the
complexity which must be active in an agent.

After all the years of people saying that the reason they don't do SET
requests is because of lack of authentication, is it realistic to
believe that agents are going to now avoid bearing the cost of
authentication?  Of course not, any device which accepts Set requests
is going to authenticate them.  And we all admit that it will be a
significant incremental cost to use this one, all important feature.

 >   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".

The privacy protocol is actually the easier part of things.  It's the
authentication, the views, the access lists that is the real pain.
All those internal mib-cross references that must be maintained.

All those MIB data structures will exist, need to be initialized, need
to be maintained, need to be handled in case they become inconsistent.

(BTW -- the fact that the choice of protocol, i.e. noPriv,
paryPrivProtocl, etc., is expressed as a variable-lengh, multiple byte
OID rather than a simple enumerated byte is an example of the silly
extent the protocol has gone to accomodate any and all unforeseeable
changes.)

 >    > 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.

I want to use only a tiny dab of the goop, authentication, and the
cost of that little piece is very large.  And much of reason why that
cost is so large is that the basic function of authentication --
proving that the sender of a packet is truely who he purports to be --
is has been bound up with access lists, views and the like.

Yes, I can define parties with views and access lists that are pretty
short and all inclusive.  But that means that the agent must have the
mechanisms to deal with those.  And it means that those administrative
MIB elements must be managed and maintaned.

 >    > 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 really disagree here.  I find that SNMPv2, just like CMIP, is a
basket into which everybody threw their favorite hobbyhorse.  CMIP has
scoping and filters.  V2 has access lists and views.  CMIP has linked
replies.  SNMPv2 has proxy mibs.  SNMPV2 has row creation.  CMIP has
create/delete primitives.  CMIP has GDMO.  SNMPv2 has "textual
conventions".  And the list goes on.

Neither protocol was engineered against a well articulated statement
of requirements, as a consequence, both protocols are obese.  There
was no statement of goals to say whether the benefit of say, for
example, instance level granularity, was worth the cost to the
community or was simply useful to a small community.

As Simon Hacket put it: All we wanted out of V2 was a way to safely do
Sets.  Instead of the racehorse we wanted, we got a camel -- a
horse designed by a committee -- which is big, slow, smells bad, and
spits, although it will do well on extremely sandy racetracks.

In V2 we have a system which invites misuse and mis-configuration.
Tax forms at least have internal cross checks and are easily audited
for simple computing errors.  The V2 administrative framework is
highly subject to pollution from a single implementation or
operational error.

 >    > I have already seen network gear fail because of SNMPv1 implementation
 >    > bugs.  So I am not optimimistic.
 >
 >   Implementation is different than operation/configuration. 

That's not a very useful distinction.

When I am out in the field trying to get something to work, I don't
care whether it is the implementation or the specification.  If the
box doesn't work, it doesn't work.

			--karl--