Re: [RMONMIB] Overflow Counters (was comments ondraft-ietf-rmonmib-dsmon-mib-02.txt)

[Andy Bierman <abierman@cisco.com>]

"C. M. Heard" wrote:
> 
> On Mon, 2 Oct 2000, Andy Bierman wrote:
> 
> > I would like to propose that it is time to stop duplicating Counter64
> > objects in MIBs with a "Counter32/Overflow32 pair". It is time to
> > require SNMPv2C support in applications to access 64-bit counters.
>   ^^^^^^^^^^^^^^^^^^^^^^^
> 
> Should that not say "require SNMPv3 support"?  The last time I
> looked SNMPv2C was an experimental protocol, not a standard.  A
> conformant SNMP implementation will support at least one of SNMPv1
> or SNMPv3, but there is no requirement that it support SNMPv2C.
> 

This is a problem, isn't it?
I don't believe an SNMPv1 to SNMPv3 upgrade is even close to simple,
especially compared to the implementation cost of overflow counters.
I don't think the "experimental" label means much though.  We have
many more users of V2C than we ever did of the Party-based V2.
Wearing my WG Chair hat, I don't want to lift a finger to help
anyone "fix SNMPv1". They can move on to SNMPv3 to pick up new features.
Wearing my SW Engineer hat, it's hard to justify an upgrade to SNMPv3
simply to utilize the Counter64 data type. 

I have a problem with an IETF policy intended to help vendors avoid using 
the current management protocol. There are some vendors that perhaps will 
never upgrade from SNMPv1 to SNMPv3. How many more years should IETF WGs 
design MIBs for SNMPv1?  I think it's time to serve notice that the
bar is being raised again, and it won't be the last time either. (SMIv3! ;-)

> //cmh
> 

Andy