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, 04 Jan 1993 09:14:00 -0800
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 Priority: 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. >> >>Thoughts? >> -Shawn >> >Shawn, > >This sounds like a good idea to me, unless I hear complaints I will add this. >It is really no more difficult in the basic case and adds functionality for >those that need it. Dave, 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 locationType.location.index 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. Pete
- FW: Adding a 'chasEnvironSlotIndex' to t {3COM/PDD/PeteW}