FW: Adding a 'chasEnvironSlotIndex' to t

{3COM/PDD/PeteW}@pdd.3mail.3com.com Mon, 04 January 1993 09:39 UTC

Return-Path: <owner-chassismib@CS.UTK.EDU>
Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA25388; Mon, 4 Jan 93 04:39:47 -0500
X-Resent-To: chassismib@CS.UTK.EDU ; Mon, 04 Jan 1993 09:39:46 GMT
Errors-To: owner-chassismib@CS.UTK.EDU
Received: from gatekeeper.3Com.COM by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA25380; Mon, 4 Jan 93 04:39:43 -0500
Received: from gw.3Com.COM by gatekeeper.3Com.COM with SMTP id AA12996 (5.65c/IDA-1.4.4-910725 for <chassismib@cs.utk.edu>); Mon, 4 Jan 1993 01:39:41 -0800
Received: by gw.3Com.COM id AA14865 (5.65c/IDA-1.4.4 for chassismib@cs.utk.edu); Mon, 4 Jan 1993 01:39:40 -0800
Date: Mon, 4 Jan 93 09:14 PST
From: {3COM/PDD/PeteW}@pdd.3mail.3com.com
Subject: FW: Adding a 'chasEnvironSlotIndex' to t
To: chassismib@cs.utk.edu
Message-Id: <930104.013541@3Mail.3Com.COM>
Msg-Date: 1993-01-04
Msg-Time: 09:08

Microsoft Mail v3.0 IPM.Microsoft Mail.Note
From: Wilson, Peter
To:  Moran, Paul
     Woodruff, Paul
     IETF-Chassis MIB
Subject:  FW: Adding a 'chasEnvironSlotIndex' to t
Date: 1993-01-04 09:01
Message ID: F255ED3F
Parent message ID: 934873E0
Conversation ID: 934873E0


From: Wilson, Peter
To: {arneson
Subject: Re: Adding a 'chasEnvironSlotIndex' to t
Date: Monday, January 04, 1993 9:00AM

>>These objects are fine for 'chassis wide' sensors, like a sensor which
>>represents the temperature of the chassis.  But what of cases where there
>>are sensors within each module occupying a slot?  For example, what if
>>there were a temperature sensor on each module?  What each module had
>>built-in fans which were monitored using a 'sensorFans'?
>>A new object could be added to this table to solve this problem.
>>'chasEnvironSlotIndex' could be added to represent the slot in which the
>>sensor resides.  The ChasEnvironTable would then be indexed using both
>>chasEnvironIndex and chasEnvironSlotIndex.  chasEnvironSlotIndex could be
>>zero for 'chassis wide' sensors.
>>						-Shawn
>This sounds like a good idea to me, unless I hear complaints I will add 
>It is really no more difficult in the basic case and adds functionality for
>those that need it.

how are you getting on adding the location type and index to the tables. 
Have you managed to work in any of my ideas? Assuming for a moment you have 
then it is reasonable that different types of component in the chassis could 
have environment sensors. In the example Bob Stewart put forward of a 
chassis with 'front' and 'rear' cards both types can have sensors. The index 
on this table would then be both the location type (eg rear, front, chassis, 
PSU, FAN etc and the instance number. The index to this table would then be


Two points to consider:
1) Does the location of the sensor have to be part of the index. Could just 
be an information column.
2) If it does then 'share' the object in the physical config table, don't 
add extra objects to the table.