Re: Chassis Power Supply Group. (Was "" ;-) (Keith McCloghrie) Tue, 21 July 1992 06:58 UTC

Return-Path: <owner-chassismib>
Received: by CS.UTK.EDU (5.61++/2.8s-UTK) id AA26772; Tue, 21 Jul 92 02:58:02 -0400
Received: from LANSLIDE.HLS.COM by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA26768; Tue, 21 Jul 92 02:57:58 -0400
Received: from nms.netman ( by (4.1/SMI-4.0) id AA25339; Mon, 20 Jul 92 23:57:01 PDT
Received: by nms.netman (4.1/SMI-4.1) id AA02568; Mon, 20 Jul 92 23:46:29 PDT
From: (Keith McCloghrie)
Message-Id: <9207210646.AA02568@nms.netman>
Subject: Re: Chassis Power Supply Group. (Was "" ;-)
Date: Mon, 20 Jul 92 23:46:28 PDT
In-Reply-To: <>; from "" at Jul 20, 92 6:30 pm
Organization: Hughes LAN Systems
X-Mailer: ELM [version 2.2 PL0]

> Howdy,
> >2.I did not quite understand chasPowerSupplyStatus. When do you 
> >return empty(2)?  Are your slots the same as chassis slots? If yes 
> >you need not such a value, as the Chassis MIB would allow you 
> >defining Power Supply as a device (using chasEntityFunction in Keith's 
> >proposal) mapped on a slot.
> Yea, I didn't explain that one very well.  I know Donna and Keith's
> proposal put the power supplies into the chasEntityTable - treating
> power supplies like any other entity.  However, I like to idea of
> removing them from the chasEntityTable and putting power supplies
> is their own group.  It just seems to me that power supplies aren't
> like the other manageable components.  In most chassis I've seen
> the component slots and power supply slots even look completely different.
> Different sizes, grouped in different locations, etc.  Why group them
> in with things that have IP addresses, Parties, and Community Strings?
> Your chHWPSULocation fits well into the proposal where supplies are
> just another component in the entity table.  Do we want to stick
> with this proposal?

While it was Jeff Case who suggested adding 'power' as one of the values 
of chasEntityFunction, I think Dan's "would allow" phrasing is what is
intended, i.e., if the power supply is on a card in a regular slot, then 
it's important to reflect that in the chasEntityTable/chasSlotTable; 
if it's not on a card in a slot, then it need not be in the 

Since you raise the issue of Parties, IP Addresses and Community Strings, 
with the progression of SNMP Security RFCs, and the evolution of
S[N]MP, does anybody think we need to retain Community Strings and 
IP Addresses in the chasEntityTable ??