Re: Power Supply MIB - Early Warning

Bob Stewart <rlstewart@eng.xyplex.com> Thu, 27 August 1992 16:00 UTC

Return-Path: <owner-chassismib>
Received: by CS.UTK.EDU (5.61++/2.8s-UTK) id AA14934; Thu, 27 Aug 92 12:00:54 -0400
Received: from xap.xyplex.com by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA14909; Thu, 27 Aug 92 12:00:42 -0400
Received: by xap.xyplex.com id <AA02058@xap.xyplex.com>; Thu, 27 Aug 92 12:00:01 -0500
Date: Thu, 27 Aug 1992 12:00:01 -0500
Message-Id: <9208271700.AA02058@xap.xyplex.com>
From: Bob Stewart <rlstewart@eng.xyplex.com>
To: chassismib@cs.utk.edu
In-Reply-To: gallagher@quiver.enet.dec.com's message of Wed, 26 Aug 92 17:14:38 EDT <9208262113.AA18653@us1rmc.bb.dec.com>
Subject: Re: Power Supply MIB - Early Warning


> Can I try to sell you on chasPowerSupplyHealthText one more time?  

Convincing me to include health text is pretty easy.  Although its value for
automated management is marginal, its value is high to humans from systems
that have lots of information and will provide it.  It slightly offends my
sense of easy cop out, since such techniques can be grossly overused, but not
enough to argue much about it.  In fact, information supplied in that form and
proving to be useful becomes a fine candidate for explicit MIB objects.

>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?)

I really did mean the voltage actually available from the output, but I
understand that wattage is also useful, and perhaps moreso.  My judgement in
this area is not sufficiently educated.  I have little idea of exactly what is
useful or reasonable to expect, so you experts out there will have to help.

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

Most of the fancy stuff I've invented didn't get much past first draft.  I
much prefer the simplicity of enumerated integers, if we can convince
ourselves that we're sufficiently comprehensive.

>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.

Just because we started out with two MIBs doesn't mean we shouldn't have one
or three.  We could consider moving all or part of this into the Chassis MIB,
or perhaps splitting it further.  Other than the problem of zillions of MIB
documents, a split of Chassis, Power Supply, and Environment may be correct.
Actually, the environment stuff may properly be an optional group for the
MIB-II System MIB, except that probably doesn't quite follow the established
hierarchy.  

>Looks like a good synthesis.

Thanks for the quick comments.  C'mon the rest of you guys.  Remember, Jeff
told us this list is NOT read only.  I'm not smart enough to do this by
myself, even with Shawn's help.

	Bob