Re: RFC1155 Timeticks hitting maximum value

Hi -

> From: "Jon Saperia" <[email protected]>
> To: "Randy Presuhn" <[email protected]>
> Cc: <[email protected]>
> Sent: Wednesday, June 23, 2010 3:54 PM
> Subject: Re: [OPS-AREA] RFC1155 Timeticks hitting maximum value
>
> Why would a whole new set of objects be required to either fix,
> hrSystemUptime, or create a new higher capacity object?

The question wasn't just about hrSystemUptime, but the fundamental
deficiency of time ticks.

Coming up with a new time ticks syntax would effectively mean
every existing time ticks object would at least need to be
considered for obsolescence, and new objects would need
to be created in appropriate cases.  Counters currently referencing those
time ticks objects as discontinuity indicators would then have to be
considered for update as well, unless we were going to say that
implementations MUST support both representations.  (This quickly
becomes a replay of the 32-bit counter / 64-bit counter / paired-counter
discussion from SMIv2.)

But that really wouldn't address the problem - an existing NMS
application that behaves badly when hrSystemUptime wraps.

Randy