Re: snmpv2 Will it flood us or be slow

[Aleksey Y Romanov <[e-mail]>]

> 
> Many of the benefits of SNMPv2 can be gained with very little cost.
> The new descriptive error codes and exception values, not to mention
> GetBulk retrieval, are substantial improvements that require very little
> additional development effort.  In many ways, these new constructs
> have the potential to decrease processing power requirements.

No doubts about it.

> Granted,
> the new administrative framework, if fully implemented, will lead to the
                                    ^^^^^^^^^^^^^^^^^^^^
> increases you mention,

1. One more positive thing about SNMPv2 its definitions are much more 
   rigourous than that of SNMPv1. So, I do expect that they will not 
   be ignored by industry this time.

2. There is no such a thing as partial implementation of SNMPv2 adminstrative
   framework allowed. The distinction made was related to auth/priv protcols
   supported. So full implementation of adminstrative framework is not 
   optional.

> though I would argue that the increases do not
> necessarily need to be "drastic". 

3. Do you consider 50% a drastic increase ?

> Utilizing noAuth/noPriv communication
> does not greatly increase resource costs while it does provide the basis
> through which the aforementioned benefits can be gained.

Yes. But what were are talking about is implementation of partyMIB with
all its interdependencies.

> 
> John
> 

I do not have any suspects in any kind of wrong doing. The current
version of SNMPv2 is great base to start with.  I would like just to
point out issues which still has to be addressed:

1. RowStatus
2. TestAndIncrment
3. Using contexts for proxy responses routing
4. NMS collision prevention (note for Bob, I just listed it here
   not discussing it )

There are also parts which do not represent a problem, but which 
can be substantially improved:

1. Parties
2. Instance level granularity
3. The 128-oid limit 

Aleksey