RE: [RMONMIB] comments on draft-ietf-rmonmib-dsmon-mib-02.txt

[Larry Stabile <lstabile@concord.com>]

Les Bell:

> Hi Andy,
> 
> I agree with Ofer Goren that it is not a simple compile switch to support
> SNMPv2C/v3 for the majority of implementations.
> 
> But I would go a bit further and suggest that you should continue to support the
> overflow counters in new MIBs.  If you don't, then I believe they will be
> defined in proprietary MIBs by the majority of vendors that cannot easily
> support SNMPv2C/v3.  This will make it more difficult for the NMS people
> everywhere.
> 
> It is true that there are a few SNMPv2C/v3 implementations out there that could
> be used as a replacement for the many SNMPv1 implementations that are out there.
> However I would find it difficult to justify the cost of purchasing a third
> party SNMPv2C/v3 implementation and porting it into an existing product.  Even
> taking a 'free' implementation requires significant development effort to port,
> adapting it to interface to an existing product, or adapting the rest of the
> software to the new SNMP interface.  Why should I have to divert resources to
> this work when I could implement new features instead, where the end-user will
> see as a more direct benefit.
> 
> If you have an agent and NMS that both support SNMPv2C/v3, then you always have
> the option of not implementing the overflow counters in your agent.  The MIB
> compliance statements can make it clear that it is required to implement either
> the 64-bit counters or the 32-bit overflow counters, but it is not required to
> implement both.
> 
> We have an existing solution to the 64-bit counters that works well with
> existing equipment.  Let's not break it.

This is essentially saying that no one ever has to move up to 64
bits. If agent vendors and WGs continue to supply overflow counters,
there is no incentive to upgrade. The RFCs are clear that 64 bits is
the proper form for high-capacity measurements. If everyone wants
dual-32 instead, why not just amend SNMPv1 and other standards to add
overflow counter conventions, and deprecate 64 bits?

By continuing to add overflow counters, we are just increasing the
hodgepodge, and are not improving mibs toward standards. I agree with
Andy that we should drop them. I think dsmon is as good a place to
start as any.

 - Larry

--------------

Larry Stabile
Concord Communications, Inc.
600 Nickerson Road
Marlborough, MA 01752
lstabile@concord.com
508-303-4246