re: Power Supply MIB - Early Warning

[[e-mail]]

>A table of power supplies, indexed by power supply index, a small integer
>which may correspond to a physical location in a chassis, either a regular
>slot or a power supply slot.  Each entry contains:
>
>	description - a textual description including vendor's name and
>	version.
>
>	status - unknown, empty, bad, warning, standby, engaged, redundant.
>	Standby means believed usable but not supplying power.  Engaged means
>	supplying power.  Redundant means supplying power but believed
>	unnecessary (that n+1 business...).  Status is bad or warning if
>	one or more outputs or environmental sensors indicates bad or
>	warning, although the low level could be bad but overall status
>	just a warning.
>
>	events - number of times status has gone to warning or bad.
>

Can I try to sell you on chasPowerSupplyHealthText one more time?  
(It's similar the the HealthText found in the repeater MIB).  It might be 
defined as:

	chasPowerSupplyHealthText OBJECT-TYPE
	    SYNTAX    DisplayString
	    ACCESS    read-only
	    STATUS    mandatory
	    DESCRIPTION
	        "The health text object is a text string which provides
	         information relevant to the operational state of the
	         power supply.  Agents may use this string to provide
	         detailed information on current failures.  The contents
	         are agent specific."
	    ::= {  chasPowerSupplyEntry xx }

>A table of outputs, indexed by power supply index and an additional small
>integer.  I'd rather use voltage as the second index, but it can be negative
>and I don't believe that's allowed.  An implementation can omit entries of
>status "unknown", and could thus always have an empty table.  Each entry
>contains:
>
>	voltage - in hundredths of volts, nominal (expected) output, such as
>	-5, +5, +12, -15, etc.
>
>	status - unknown, bad, warning, good.  If unknown, supplied voltage
>	is meaningless.
>
>	supplied voltage - in hundredths of volts, power currently provided by
>	this output.  Status of good and value of 0 together indicate supplied
>	voltage is not available.
>
>	warnings - number of times status has gone to warning.
>
>	failures - number of times status has gone to bad.
>

Can I assume that "supplied voltage" is a tpyo and that you really meant
to specify the power, in hundredths of a watt for the corresponding voltage?
(And that you meant to call it OfferedPower instead of SuppiedVoltage?)

>Now we get really fancy.  A table of environmental statuses, indexed by power
>supply index and (shudder) an OID.  Standard OIDs provided for humidity,
>temperature, and fan.  An implementation may omit entries with status
>"unknown" and thus could have an empty table.  Each entry contains:
>
>	status - unknown, bad, warning, good.
>
>	warnings - number of times status has gone to warning.
>
>	failures - number of times status has gone to bad.

Fancy, but a very good idea.  (Maybe we can buck the trend and go with an
enumerated integer rather than the OID.)

Does this environmental information have to relate to a power supply?
It would be handy to have a group of environmental objects (like temperature
and fan status) which could be applied to the whole chassis - not just the
power supplies.

Looks like a good synthesis.
						-Shawn