Re: RFC1155 Timeticks hitting maximum value

But is was in the context specifically of hrSystemUptime - at least that is how I read it.  I was suggesting a surgical fix to a specific problem related to uptime.  That could be fixed with a single object and leave the others that use time ticks intact.

That said, I do agree with you that a good NMS should be able to deal with this and other oddities in this and many other objects.  

/jon
On Jun 23, 2010, at 7:30 PM, Randy Presuhn wrote:

> 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
> 
> _______________________________________________
> OPS-AREA mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ops-area
>