Re: Chassis MIB comments

kzm@hls.com (Keith McCloghrie) Sun, 23 August 1992 19:28 UTC

Return-Path: <owner-chassismib>
Received: by CS.UTK.EDU (5.61++/2.8s-UTK) id AA07540; Sun, 23 Aug 92 15:28:00 -0400
Received: from LANSLIDE.HLS.COM by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA07536; Sun, 23 Aug 92 15:27:56 -0400
Received: from nms.netman (nms.hls.com) by lanslide.hls.com (4.1/SMI-4.0) id AA23742; Sun, 23 Aug 92 12:28:12 PDT
Received: by nms.netman (4.1/SMI-4.1) id AA21980; Sun, 23 Aug 92 12:27:52 PDT
From: kzm@hls.com (Keith McCloghrie)
Message-Id: <9208231927.AA21980@nms.netman>
Subject: Re: Chassis MIB comments
To: arneson@yeti.ctron.com (David L. Arneson)
Date: Sun, 23 Aug 92 12:27:51 PDT
Cc: kzm@hls.com, chassismib@cs.utk.edu
In-Reply-To: <9208211722.AA13842@yeti.ctron>; from "David L. Arneson" at Aug 21, 92 1:22 pm
Organization: Hughes LAN Systems
X-Mailer: ELM [version 2.2 PL0]


> In reading the The above statement.  Perhaps it would be benificial to
> redefine chasEntityTimeStamp from a time stamp as presently defined to
> chasEntityTime "sysUpTime for this entity".
  
There seems to be two choices here: 

1) define it as a timestamp (a fixed value between restarts), and base it
on the sysUpTime of the agent implementing the Chassis MIB, or

2) define it as a ticking clock (an incrementing value between restarts), 
and base it on the sysUpTime of the particular (underlying) entity.

My preference is for option 1, since it's a little more general.

Keith.