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

["David T. Perkins" <dperkins@dsperkins.com>]

HI,

I do not know what is meant by "64-bit implementations".

My belief is that a backwards compatable approach TO THE SNMPv1
PROTOCOL has to be adopted that allows new data types (such as
the 64-bit counter, 64-bit signed and unsigned integers) to be
added. And there is already a solution. This solution has been
in use for several years in the UC-DAVIS SNMP agent.

The solution is to add the new data types to the SMI, and define
the "transport mapping" so that "old" SMI data types
have values
encoded as "straight" BER, and new (to SNMPv1) data type
have
values encoded first into BER and that is used as the value for
an encoding of OPAQUE data type. This is all explained on the
UC-DAVIS site.

The result is that agents can continue to be written in SNMPv1
(no major upgrade). Only a very small and localized updated is
needed.
(I believe in the UC-DAVIS code, it was less than 20 lines of C
code).

Only the purests get upset with this proposal. It really works!

Regards,
/david t. perkins

At 10:26 AM 10/03/2000 -0400, Carter Bullard wrote: 

> Gentle People, 
> There will be an eventual need for overflow counters
> with 64 bit implementations.  Its just a matter of time, 
> as it was with 32 bit implementations. 
>
> Is the consensus that there will not be overflow counter 
> support in 64 bit implementations? 
>
> Carter 
>
> Carter Bullard 
> QoSient, LLC 
> 300 E. 56th Street, Suite 17A 
> New York, New York  10022 
>
> carter@qosient.com 
> Phone +1 212 813-9426 
> Fax   +1 212 813-9426 
>
> -----Original Message----- 
> From: rmonmib-admin@ietf.org [mailto:rmonmib-admin@ietf.org]On Behalf Of 
> Larry Stabile 
> Sent: Tuesday, October 03, 2000 9:30 AM 
> To: rmonmib@ietf.org; mibs@ops.ietf.org 
> Subject: RE: [RMONMIB] comments on draft-ietf-rmonmib-dsmon-mib-02.txt 
>
>
> 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 
>
> _______________________________________________ 
> RMONMIB mailing list 
> RMONMIB@ietf.org 
> http://www.ietf.org/mailman/listinfo/rmonmib