RE: FW: 64 bit counters in MPLS MIBs

["C. M. Heard" <heard@pobox.com>]

On Mon, 6 Jan 2003, Wijnen, Bert (Bert) wrote:
> So I saw in their MIB modules:
> - HC (counter64) counters with LC counters (counter32) for 
>   SNMPv1 access or devices that do not have native 64bit
>   arithmenthic.

I think providing LC counters _for this reason_ is a bad idea,
if the HC bit counters are needed in the first place.  It's
just giving license to implement something inadequate.  Note
that the "solution" cannot achieve its intended purpose
unless the LC counters figure as an _alternative_ to the HC
counters, not as an optional-to-implement supplement to them.

> - regular LC counters for things that do not roll over within
>   an hour.

That, of course, is OK.

> Now... for the first set, I have been giving advice lately that
> with me it is OK if the WG decides that they just do HC counters
> and do not provide LC counters. If they want to provide them,
> then fine... but it just adds objects and complexity in 
> compliance statements and for management apps. And worse,
> you can never get rid of them...

I'd say it's not OK (given the stated reason).  Providing
alternative means to do the same thing is BAD for
interoperability.  Providing alternatives that don't work
properly is even worse.

> (I like DBH suggestion to add them but make then deprecated
> right away... that way old systems can still do it if they
> want, but it is not needed.)

For SNMPv1 compatibility, maybe.  But in this case you
don't make the 32-bit counters an _alternative_ to the
64-bit counters, you make them an optional-to-implement
_supplement_.  (And if you want the alternative to work
correctly, for each a 32-bit "event" counter you would
have a corresponding 32-bit "rollover" counter.)

> I know that such is a bit harsh on SNMPv1 management apps,
> but then, I believe that specifically on the NMS side
> it is time by now to move over to SNMPv3.

Yep.  Presumably that's why SNMPv3 is Standard and SNMPv1
is Historic.

//cmh