Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09606; 3 Jan 94 13:15 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09602; 3 Jan 94 13:15 EST Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa19185; 3 Jan 94 13:15 EST Received: from localhost by CS.UTK.EDU with SMTP (8.6.4/2.8s-UTK) id NAA04272; Mon, 3 Jan 1994 13:01:38 -0500 X-Resent-To: ups-mib@CS.UTK.EDU ; Mon, 3 Jan 1994 13:01:36 EST Errors-to: owner-ups-mib@CS.UTK.EDU Received: from dub-img-2.compuserve.com by CS.UTK.EDU with ESMTP (8.6.4/2.8s-UTK) id NAA04247; Mon, 3 Jan 1994 13:01:33 -0500 Received: from localhost by dub-img-2.compuserve.com (8.6.4/5.930129sam) id NAA07748; Mon, 3 Jan 1994 13:01:03 -0500 Date: 03 Jan 94 12:55:19 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Ron Pitt (NSSI)" <71303.577@compuserve.com> To: UPSMIB Subject: Re: The latest draft. Message-ID: <940103175518_71303.577_DHQ89-1@CompuServe.COM> I was under the impression that this review was to be for editorial mistakes only. In that spirit, NSSI likes this draft and has no problem with it going to the "Proposed Standard" phase. I would be VERY MUCH AGAINST major changes at this point in the process. This would include removal of a conformance group. Ron Pitt NSSI   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa28298; 4 Jan 94 0:37 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa28294; 4 Jan 94 0:37 EST Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa12187; 4 Jan 94 0:37 EST Received: from localhost by CS.UTK.EDU with SMTP (8.6.4/2.8s-UTK) id AAA19782; Tue, 4 Jan 1994 00:26:03 -0500 X-Resent-To: ups-mib@CS.UTK.EDU ; Tue, 4 Jan 1994 00:26:01 EST Errors-to: owner-ups-mib@CS.UTK.EDU Received: from arl-img-1.compuserve.com by CS.UTK.EDU with ESMTP (8.6.4/2.8s-UTK) id AAA19773; Tue, 4 Jan 1994 00:26:00 -0500 Received: from localhost by arl-img-1.compuserve.com (8.6.4/5.930129sam) id AAA01968; Tue, 4 Jan 1994 00:25:30 -0500 Date: 04 Jan 94 00:22:50 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Terry L. Zumwalt" <71151.2550@compuserve.com> To: UPS SNMP MIB Committe Subject: IPM's Input Message-ID: <940104052249_71151.2550_CHE68-1@CompuServe.COM> IPM is also opposed to any 11th hour changes. We agree completely with NSSI on changes to the proposed draft. We also have intentions of using the Basic compliance group it should stay as agreed upon in Houston. Changes at this time should be minor. Regards Terry L. Zumwalt International Power Machines Corp.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09242; 6 Jan 94 13:10 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09235; 6 Jan 94 13:10 EST Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa14136; 6 Jan 94 13:10 EST Received: from localhost by CS.UTK.EDU with SMTP (8.6.4/2.8s-UTK) id MAA14482; Thu, 6 Jan 1994 12:54:56 -0500 X-Resent-To: ups-mib@CS.UTK.EDU ; Thu, 6 Jan 1994 12:54:55 EST Errors-to: owner-ups-mib@CS.UTK.EDU Received: from nic.cerf.net by CS.UTK.EDU with ESMTP (8.6.4/2.8s-UTK) id MAA14471; Thu, 6 Jan 1994 12:54:53 -0500 Received: from localhost (rdraper@localhost) by nic.cerf.net (8.6.4/8.6.4) id JAA20160; Thu, 6 Jan 1994 09:55:42 -0800 Date: Thu, 6 Jan 1994 09:55:15 -0800 (PST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Roger W. Draper" X-Orig-Sender: "Roger W. Draper" Reply-To: "Roger W. Draper" Subject: No New Changes To: UPS-MIB Mailing list Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Liebert Corporation is also opposed to any last minute changes to the proposed standard, only editorial mistakes should be corrected at this time. Roger Draper Liebert Corp.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11700; 6 Jan 94 14:23 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11696; 6 Jan 94 14:23 EST Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa16589; 6 Jan 94 14:23 EST Received: from localhost by CS.UTK.EDU with SMTP (8.6.4/2.8s-UTK) id OAA20705; Thu, 6 Jan 1994 14:13:40 -0500 X-Resent-To: ups-mib@CS.UTK.EDU ; Thu, 6 Jan 1994 14:13:39 EST Errors-to: owner-ups-mib@CS.UTK.EDU Received: from relay2.UU.NET by CS.UTK.EDU with SMTP (8.6.4/2.8s-UTK) id OAA20697; Thu, 6 Jan 1994 14:13:37 -0500 Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA11212; Thu, 6 Jan 94 14:13:29 -0500 Received: from apc.UUCP by uucp5.uu.net with UUCP/RMAIL (queueing-rmail) id 065832.13247; Thu, 6 Jan 1994 06:58:32 EST Received: by apc (AIX 3.2/UCB 5.64/4.03) id AA19338; Wed, 5 Jan 1994 18:59:56 -0500 Date: Wed, 5 Jan 1994 18:59:56 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Doug Rademacher Message-Id: <9401052359.AA19338@apc> To: uunet!cs.utk.edu!ups-mib@uunet.uu.net Subject: 11th hour changes My most recent messages were written in reference to Jeff's list of issues still outstanding. I am only trying to address those issues. My messages were also completed before Jeff's deadline of 12/29. If we had wanted to stop any more discussion, then there shouldn't have been a call for more input. I was under the impression that we should make any changes now, because they would be very difficult to change later. When, actually, is the 11th hour? Is it now? Is it 6 months from now? If the points I made were valid, then let's address them before it really is too late. So far this forum has only heard from five participants. Is every- one still on vacation? _____________________________________________________________________ _ ___ ___ / \ _)/ / _\|| \___ --------------------------------------------------------------------- Douglas J. Rademacher | American Power Conversion Corp. Director of Software Development | 132 Fairgrounds Road | West Kingston, RI 02818 apc!dougr@uunet.uu.net | (401) 789-5735 x2073 ---------------------------------------------------------------------   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14437; 9 Jan 94 12:30 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14433; 9 Jan 94 12:30 EST Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa25271; 9 Jan 94 12:30 EST Received: from localhost by CS.UTK.EDU with SMTP (8.6.4/2.8s-UTK) id MAA21401; Sun, 9 Jan 1994 12:14:55 -0500 X-Resent-To: ups-mib@CS.UTK.EDU ; Sun, 9 Jan 1994 12:14:54 EST Errors-to: owner-ups-mib@CS.UTK.EDU Received: from vms.macc.wisc.edu by CS.UTK.EDU with SMTP (8.6.4/2.8s-UTK) id MAA21394; Sun, 9 Jan 1994 12:14:52 -0500 Received: from VMSmail by vms.macc.wisc.edu; Sun, 09 Jan 94 11:12 CDT Message-Id: <24010911120350@vms.macc.wisc.edu> Date: Sun, 09 Jan 94 11:12 CDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Brian Young Subject: My review To: ups-mib@cs.utk.edu X-VMS-To: in%"ups-mib@cs.utk.edu",BYOUNG Hi guys, Sorry for the long delay in getting my comments in. Just completed reviewing all mail since the last release of the MIB. A few comments... BEST would like to see the basic group remain. Our Fortress has many of the features required for full-featured compliance, but not all, so it marries better with the basic group. I think that many of us have units that fit this category, but don't want to admit it for some reason. :) BEST also hmmms on the killing of the config group variables: input voltage, input frequency, output voltage, output frequency, output VA and output power from the subset group! We also feel that changes should be kept to a minimum at this point. Things look pretty good right now, so let's keep it that way. I've got enough gray hairs from this project already. :) Regards, Brian Young Best Power Technology   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04655; 10 Jan 94 12:26 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04651; 10 Jan 94 12:26 EST Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa17446; 10 Jan 94 12:26 EST Received: from localhost by CS.UTK.EDU with SMTP (8.6.4/2.8s-UTK) id MAA02250; Mon, 10 Jan 1994 12:15:41 -0500 X-Resent-To: ups-mib@CS.UTK.EDU ; Mon, 10 Jan 1994 12:15:39 EST Errors-to: owner-ups-mib@CS.UTK.EDU Received: from dante.exide.com by CS.UTK.EDU with SMTP (8.6.4/2.8s-UTK) id MAA02237; Mon, 10 Jan 1994 12:15:38 -0500 Received: by dante.exide.com (5.0/1.34) id AA02185; Mon, 10 Jan 94 12:18:35 EST Date: Mon, 10 Jan 94 12:18:35 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tom Brennan Message-Id: <9401101718.AA02185@dante.exide.com> To: ups-mib@cs.utk.edu Subject: When can we expect the Final draft of MIB? Content-Length: 165 The deadline for comments is passed, and even the late comments have slowed down to a trickle. For our planning purposes, when can we expect to see the final draft?   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04594; 19 Jan 94 11:28 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04590; 19 Jan 94 11:28 EST Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa08922; 19 Jan 94 11:28 EST Received: from localhost by CS.UTK.EDU with SMTP (8.6.4/2.8s-UTK) id JAA02612; Wed, 19 Jan 1994 09:45:52 -0500 X-Resent-To: ups-mib@CS.UTK.EDU ; Wed, 19 Jan 1994 09:45:50 EST Errors-to: owner-ups-mib@CS.UTK.EDU Received: from sun4nl.NL.net by CS.UTK.EDU with SMTP (8.6.4/2.8s-UTK) id JAA02579; Wed, 19 Jan 1994 09:45:36 -0500 Received: from vicnl by sun4nl.NL.net via EUnet id AA29996 (5.65b/CWI-3.3); Wed, 19 Jan 1994 15:45:34 +0100 Received: from vic1 by vicnl.victron.nl id aa08498; 19 Jan 94 14:53 CET Received: from VICTRON_ONE/TEMPQ by vic1.victron.nl (Mercury 1.11); Wed, 19 Jan 94 14:58:56 CET Received: from TEMPQ by VICTRON_ONE (Mercury 1.11); Wed, 19 Jan 94 14:58:40 CET Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Jack Stiekema, PE0MOT" Organization: Victron bv To: ups-mib@cs.utk.edu Date: Wed, 19 Jan 1994 14:58:33 GMT+0200 Subject: Re: When can we expect the Final draft of MIB? Reply-To: jack@victron.nl Priority: normal X-Mailer: PMail v3.0 (R1a) Message-Id: <15429465D90@vic1.victron.nl> it's quit, what is the next date? Kind regards, Jack +----------------------------------------------------+ | Victron bv POB 31 9700 AA Groningen Holland | | phone: +31 50 446222 fax: +31 50 424107 | +----------------------------------------------------+   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14993; 19 Jan 94 19:02 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14989; 19 Jan 94 19:02 EST Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa20042; 19 Jan 94 19:02 EST Received: from localhost by CS.UTK.EDU with SMTP (8.6.4/2.8s-UTK) id SAA12555; Wed, 19 Jan 1994 18:44:16 -0500 X-Resent-To: ups-mib@CS.UTK.EDU ; Wed, 19 Jan 1994 18:44:15 EST Errors-to: owner-ups-mib@CS.UTK.EDU Received: from relay1.UU.NET by CS.UTK.EDU with SMTP (8.6.4/2.8s-UTK) id SAA12546; Wed, 19 Jan 1994 18:44:10 -0500 Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAvzow28356; Wed, 19 Jan 94 18:44:07 -0500 Received: from apc.UUCP by uucp5.uu.net with UUCP/RMAIL (queueing-rmail) id 154016.7038; Wed, 19 Jan 1994 15:40:16 EST Received: by apc (AIX 3.2/UCB 5.64/4.03) id AA17652; Wed, 19 Jan 1994 11:14:17 -0500 Date: Wed, 19 Jan 1994 11:14:17 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Doug Rademacher Message-Id: <9401191614.AA17652@apc> To: uunet!cs.utk.edu!ups-mib@uunet.uu.net Subject: ping ping _____________________________________________________________________ _ ___ ___ / \ _)/ / _\|| \___ --------------------------------------------------------------------- Douglas J. Rademacher | American Power Conversion Corp. Director of Software Development | 132 Fairgrounds Road | West Kingston, RI 02818 apc!dougr@uunet.uu.net | (401) 789-5735 x2073 ---------------------------------------------------------------------   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00705; 20 Jan 94 2:56 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00701; 20 Jan 94 2:56 EST Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa01499; 20 Jan 94 2:56 EST Received: from localhost by CS.UTK.EDU with SMTP (8.6.4/2.8s-UTK) id CAA10827; Thu, 20 Jan 1994 02:45:26 -0500 X-Resent-To: ups-mib@CS.UTK.EDU ; Thu, 20 Jan 1994 02:45:25 EST Errors-to: owner-ups-mib@CS.UTK.EDU Received: from sun4nl.NL.net by CS.UTK.EDU with SMTP (8.6.4/2.8s-UTK) id CAA10811; Thu, 20 Jan 1994 02:45:22 -0500 Received: from vicnl by sun4nl.NL.net via EUnet id AA14006 (5.65b/CWI-3.3); Thu, 20 Jan 1994 08:45:23 +0100 Received: from vic1 by vicnl.victron.nl id aa09612; 20 Jan 94 8:13 CET Received: from VICTRON_ONE/TEMPQ by vic1.victron.nl (Mercury 1.11); Thu, 20 Jan 94 8:19:11 CET Received: from TEMPQ by VICTRON_ONE (Mercury 1.11); Thu, 20 Jan 94 8:18:57 CET Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Jack Stiekema, PE0MOT" Organization: Victron bv To: ups-mib@cs.utk.edu Date: Thu, 20 Jan 1994 08:18:49 GMT+0200 Subject: Re: When can we expect the Final draft of MIB? Reply-To: jack@victron.nl Priority: normal X-Mailer: PMail v3.0 (R1a) Message-Id: <16580563E0A@vic1.victron.nl> ->it's quit, -> ->what is the next date? Adam Stolinsky and i are afraid we in Europ missed the boat (or did it sink?). Ping looks ok Doug (or is it a submarine sonar). Kind regards, Jack +----------------------------------------------------+ | Victron bv POB 31 9700 AA Groningen Holland | | phone: +31 50 446222 fax: +31 50 424107 | +----------------------------------------------------+   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20774; 23 Jan 94 20:02 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20770; 23 Jan 94 20:02 EST Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa01265; 23 Jan 94 20:02 EST Received: from localhost by CS.UTK.EDU with SMTP (8.6.4/2.8s-UTK) id TAA08214; Sun, 23 Jan 1994 19:52:43 -0500 X-Resent-To: ups-mib@CS.UTK.EDU ; Sun, 23 Jan 1994 19:52:41 EST Errors-to: owner-ups-mib@CS.UTK.EDU Received: from relay1.UU.NET by CS.UTK.EDU with SMTP (8.6.4/2.8s-UTK) id TAA08182; Sun, 23 Jan 1994 19:52:36 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: yamai@soliton.co.jp MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwadv05014; Sun, 23 Jan 94 19:52:38 -0500 Received: from iij.UUCP by uucp6.uu.net with UUCP/RMAIL (queueing-rmail) id 195142.13026; Sun, 23 Jan 1994 19:51:42 EST Received: from localhost by uucp0.iij.ad.jp (8.6.5+2.3W/2.7W) id JAA05910; Mon, 24 Jan 1994 09:42:29 +0900 Received: by brahma.soliton.co.jp (4.1/IIJ-U1.1) id AA11271; Mon, 24 Jan 94 09:40:19 JST Date: Mon, 24 Jan 94 09:40:19 JST Message-Id: <9401240040.AA11271@brahma.soliton.co.jp> To: ups-mib@cs.utk.edu Subject: Please send me the UPS MIB or document. Hello. This is M.Yamai. I am Engnir. of Soliton Systems K.K. Japan. I plan to develop first UPS agent in Japan. But I have no information about UPS MIB or UPS agent. Please send me the USP MIB or UPS agents information. Regard. /yamai@soliton.co.jp   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25325; 23 Jan 94 23:06 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25321; 23 Jan 94 23:06 EST Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa03757; 23 Jan 94 23:06 EST Received: from localhost by CS.UTK.EDU with SMTP (8.6.4/2.8s-UTK) id WAA19695; Sun, 23 Jan 1994 22:56:57 -0500 X-Resent-To: ups-mib@CS.UTK.EDU ; Sun, 23 Jan 1994 22:56:55 EST Errors-to: owner-ups-mib@CS.UTK.EDU Received: from UTKVX3.UTK.EDU by CS.UTK.EDU with ESMTP (8.6.4/2.8s-UTK) id WAA19678; Sun, 23 Jan 1994 22:56:54 -0500 Received: from utkvx.utk.edu by utkvx.utk.edu (PMDF V4.2-13 #4157) id <01H81EU6NVXS8Y53EH@utkvx.utk.edu>; Sun, 23 Jan 1994 22:56:46 EST Date: Sun, 23 Jan 1994 22:56:46 -0500 (EST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: CASE@utkvx.utcc.utk.edu Subject: status To: ups-mib@cs.utk.edu Message-id: <01H81EU6QAQQ8Y53EH@utkvx.utk.edu> X-VMS-To: IN%"ups-mib@cs.utk.edu" X-VMS-Cc: CASE MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT the reviews conducted by the snmp directorate are now completed and i am incorporating their comments and input from the list into the document at this time regards, jdc   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa29958; 24 Jan 94 3:16 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa29954; 24 Jan 94 3:16 EST Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa07401; 24 Jan 94 3:16 EST Received: from localhost by CS.UTK.EDU with SMTP (8.6.4/2.8s-UTK) id DAA04443; Mon, 24 Jan 1994 03:06:36 -0500 X-Resent-To: ups-mib@CS.UTK.EDU ; Mon, 24 Jan 1994 03:06:35 EST Errors-to: owner-ups-mib@CS.UTK.EDU Received: from sun4nl.NL.net by CS.UTK.EDU with SMTP (8.6.4/2.8s-UTK) id DAA04436; Mon, 24 Jan 1994 03:06:29 -0500 Received: from vicnl by sun4nl.NL.net via EUnet id AA26777 (5.65b/CWI-3.3); Mon, 24 Jan 1994 09:06:31 +0100 Received: from vic1 by vicnl.victron.nl id aa15967; 24 Jan 94 8:45 CET Received: from VICTRON_ONE/TEMPQ by vic1.victron.nl (Mercury 1.11); Mon, 24 Jan 94 8:49:41 CET Received: from TEMPQ by VICTRON_ONE (Mercury 1.11); Mon, 24 Jan 94 8:49:30 CET Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Jack Stiekema, PE0MOT" Organization: Victron bv To: ups-mib@cs.utk.edu Date: Mon, 24 Jan 1994 08:49:22 GMT+0200 Subject: IETF meeting ?? Reply-To: jack@victron.nl Priority: normal X-Mailer: PMail v3.0 (R1a) Message-Id: <44079E4E54@vic1.victron.nl> Do we attend the IETF meeting end March in Seatle? Please a concensus a.s.a.p. because of my overfilled agenda. Kind regards, Jack +----------------------------------------------------+ | Victron bv POB 31 9700 AA Groningen Holland | | phone: +31 50 446222 fax: +31 50 424107 | +----------------------------------------------------+   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07942; 24 Jan 94 11:26 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07938; 24 Jan 94 11:26 EST Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa16843; 24 Jan 94 11:26 EST Received: from localhost by CS.UTK.EDU with SMTP (8.6.4/2.8s-UTK) id LAA11300; Mon, 24 Jan 1994 11:13:59 -0500 X-Resent-To: ups-mib@CS.UTK.EDU ; Mon, 24 Jan 1994 11:13:57 EST Errors-to: owner-ups-mib@CS.UTK.EDU Received: from metronet.com by CS.UTK.EDU with SMTP (8.6.4/2.8s-UTK) id LAA11293; Mon, 24 Jan 1994 11:13:55 -0500 Received: by metronet.com id AA09317 (5.67a/IDA1.5hp for UPS-MIB@CS.UTK.EDU); Mon, 24 Jan 1994 10:14:04 -0600 Date: Mon, 24 Jan 1994 10:13:05 -0500 (CDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Greg Hanka X-Orig-Sender: Greg Hanka Reply-To: Greg Hanka Subject: Ground fault/no ground alarms To: UPS-MIB@cs.utk.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Cris Buck, UPS Prod. Mgr. at EFI Electronics, asked me why the very important "ground fault/no ground" conditions are not enumerated specifically as an alarm or alarms. It is his belief that these are very important items and I presume many would concur. It is my recollection that these were discussed along with other input items and the consensus was that they all fell into the category of the alarm UPSALARMINPUTBAD. Can someone please enlighten me on the issue and discussion of ground fault handling? Better Regards, Go Cowboys/Chiefs Gordon Monk via Greg Hanka, ghanka@metronet.com +--------------------------------------------------------------------------+ Gregory M. Hanka P.O. Box 940148 Director of Software Development Plano, TX 75094-0148 Net X, Inc., Dallas, TX. Internet: ghanka@metronet.com / Public key \ Compu$erve: 72223,172 (72223.172@compuserve.com) \ via finger / +--------------------------------------------------------------------------+   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01085; 25 Jan 94 6:54 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id ai01032; 25 Jan 94 6:54 EST Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa01408; 25 Jan 94 5:30 EST Received: from localhost by CS.UTK.EDU with SMTP (8.6.4/2.8s-UTK) id CAA15410; Tue, 25 Jan 1994 02:15:22 -0500 X-Resent-To: ups-mib@CS.UTK.EDU ; Tue, 25 Jan 1994 02:15:21 EST Errors-to: owner-ups-mib@CS.UTK.EDU Received: from sun4nl.NL.net by CS.UTK.EDU with SMTP (8.6.4/2.8s-UTK) id CAA15401; Tue, 25 Jan 1994 02:15:19 -0500 Received: from vicnl by sun4nl.NL.net via EUnet id AA12221 (5.65b/CWI-3.3); Tue, 25 Jan 1994 08:15:20 +0100 Received: from vic1 by vicnl.victron.nl id aa17797; 25 Jan 94 8:08 CET Received: from VICTRON_ONE/TEMPQ by vic1.victron.nl (Mercury 1.11); Tue, 25 Jan 94 8:13:23 CET Received: from TEMPQ by VICTRON_ONE (Mercury 1.11); Tue, 25 Jan 94 8:13:12 CET Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Jack Stiekema, PE0MOT" Organization: Victron bv To: ups-mib@cs.utk.edu, ghanka@metronet.com Date: Tue, 25 Jan 1994 08:13:09 GMT+0200 Subject: Re: Ground fault/no ground alarms Reply-To: jack@victron.nl Priority: normal X-Mailer: PMail v3.0 (R1a) Message-Id: <5B6D652D65@vic1.victron.nl> ->Date sent: Mon, 24 Jan 1994 10:13:05 -0500 (CDT) ->From: Greg Hanka ->Subject: Ground fault/no ground alarms ->Cris Buck, UPS Prod. Mgr. at EFI Electronics, asked me why the very ->important "ground fault/no ground" conditions are not enumerated ->specifically as an alarm or alarms. It is his belief that these are ->Gordon Monk Hi Gordon, I did a ctrlqfind on all email but there is no "ground" mentioned last 10 months except for Doug's address, so sri. Maybe we mentioned it in Dallas? Kind regards, Jack +----------------------------------------------------+ | Victron bv POB 31 9700 AA Groningen Holland | | phone: +31 50 446222 fax: +31 50 424107 | +----------------------------------------------------+   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03292; 25 Jan 94 10:46 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03288; 25 Jan 94 10:46 EST Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa01167; 25 Jan 94 8:45 EST Received: from localhost by CS.UTK.EDU with SMTP (8.6.4/2.8s-UTK) id IAA15272; Tue, 25 Jan 1994 08:24:14 -0500 X-Resent-To: ups-mib@CS.UTK.EDU ; Tue, 25 Jan 1994 08:24:14 EST Errors-to: owner-ups-mib@CS.UTK.EDU Received: from dante.exide.com by CS.UTK.EDU with SMTP (8.6.4/2.8s-UTK) id IAA15265; Tue, 25 Jan 1994 08:24:12 -0500 Received: by dante.exide.com (5.0/1.34) id AA16243; Tue, 25 Jan 94 08:27:29 EST Date: Tue, 25 Jan 94 08:27:29 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tom Brennan Message-Id: <9401251327.AA16243@dante.exide.com> To: ups-mib@cs.utk.edu Subject: re: Ground fault My memory is not to be fully trusted, but this is what I recall: on the assumption that most such wiring problems are installation rather than on going problems (eg, phase rotation), and from the point of view of the network manager (well, what more can he do but have somebody sent out to check the "Bad Input Line"), we refrained from adding more specific alarms for bad input. Too infrequent, not manageable (remember snM!p). Tom Brennan, Exide   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05676; 25 Jan 94 12:34 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05630; 25 Jan 94 12:34 EST Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa06991; 25 Jan 94 12:34 EST Received: from localhost by CS.UTK.EDU with SMTP (8.6.4/2.8s-UTK) id MAA02793; Tue, 25 Jan 1994 12:02:10 -0500 X-Resent-To: ups-mib@CS.UTK.EDU ; Tue, 25 Jan 1994 12:02:06 EST Errors-to: owner-ups-mib@CS.UTK.EDU Received: from LOCALHOST by CS.UTK.EDU with SMTP (8.6.4/2.8s-UTK) id MAA02737; Tue, 25 Jan 1994 12:01:49 -0500 Message-Id: <199401251701.MAA02737@CS.UTK.EDU> To: yamai@soliton.co.jp cc: ups-mib@cs.utk.edu Subject: Re: Please send me the UPS MIB or document. Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ken Key In-reply-to: Your message of Mon, 24 Jan 1994 09:40:19 +0200. <9401240040.AA11271@brahma.soliton.co.jp> Date: Tue, 25 Jan 1994 12:01:43 -0500 X-Orig-Sender: key@cs.utk.edu Greetings, Here is a copy of the latest draft of the IETF UPS MIB Working Group Internet Draft. There will be a new draft in the next few weeks, but the changes should be mostly editorial. You can subscribe to the UPS MIB Working Group e-mailing list by sending a request to: ups-mib-request@cs.utk.edu The UPS MIB is 56 pages long. -- Ken Key (ups-mib-request@cs.utk.edu) Univ. of Tennessee, Knoxville ============================================================================= draft UPS MIB December 1993 UPS Management Information Base December 1993 Jeffrey D. Case, Ph.D. (Editor) SNMP Research, Incorporated case@snmp.com Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet Drafts as reference material or to cite them other than as a "work in progress". Expires June 1994 [Page 1] draft UPS MIB December 1993 1. Introduction This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing uninterruptible power supply (UPS) systems. Expires June 1994 [Page 2] draft UPS MIB December 1993 2. The SNMPv2 Network Management Framework The SNMPv2 Network Management Framework consists of four major components. They are: o RFC 1442 which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. o RFC 1213 defines MIB-II, the core set of managed objects for the Internet suite of protocols. o RFC 1445 which defines the administrative and other architectural aspects of the framework. o RFC 1448 which defines the protocol used for network access to managed objects. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. 2.1. Object Definitions Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the subset of Abstract Syntax Notation One (ASN.1) defined in the SMI. In particular, each object type is named by an OBJECT IDENTIFIER, an administratively assigned name. The object type together with an object instance serves to uniquely identify a specific instantiation of the object. For human convenience, we often use a textual string, termed the descriptor, to refer to the object type. Expires June 1994 [Page 3] draft UPS MIB December 1993 3. Overview This document defines the managed objects for Uninterruptible Power Supplies which are to be manageable via the Simple Network Management Protocol (SNMP). 4. Status YET TO BE DONE: 1. Proofread carefully by multiple readers 2. Shorten some overly long lines Expires June 1994 [Page 4] draft UPS MIB December 1993 5. Definitions UPS-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, OBJECT-IDENTITY, experimental, Counter32, Gauge32, Integer32 | FROM SNMPv2-SMI DisplayString, TimeStamp, TestAndIncr | FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; upsMIB MODULE-IDENTITY LAST-UPDATED "9312210000Z" | ORGANIZATION "IETF UPS MIB Working Group" CONTACT-INFO " Jeffrey D. Case (Editor) SNMP Research, Incorporated 3001 Kimberlin Heights Road, Knoxville, TN, 37920 615-573-1434 case@snmp.com" DESCRIPTION "The MIB module to describe Uninterruptible Power Supplies." ::= { experimental 39 12 6 } | PositiveInteger ::= TEXTUAL-CONVENTION DISPLAY-HINT "1d" STATUS current DESCRIPTION "This data type is a non-zero and non-negative value." SYNTAX INTEGER (1..2147483648) NonNegativeInteger ::= TEXTUAL-CONVENTION DISPLAY-HINT "1d" STATUS current DESCRIPTION "This data type is a non-negative value." SYNTAX INTEGER (0..2147483648) Expires June 1994 [Page 5] draft UPS MIB December 1993 univPowerSupply OBJECT IDENTIFIER ::= { experimental 39 } -- Note: this should be unintPowerSupply upsMibDraft2 OBJECT IDENTIFIER ::= { univPowerSupply 12 } -- Note: univPowerSupply 1-12 were used in earlier drafts. -- From now on, drafts will use version and subversion numbers -- under the experimental tree to prevent OID name-space collision -- when implementing different versions of experimental MIBS. upsMibE26 OBJECT IDENTIFIER ::= { upsMibDraft2 6 } | -- Experimental Version 2 minor version 6 (Exp v2.6) of UPS MIB. | upsObjects OBJECT IDENTIFIER ::= { upsMibE26 1 } | -- -- The Device Identification group. -- All objects in this group except for upsIdentName and -- upsIdentAttachedDevices are set at device initialization -- and remain static. -- upsIdent OBJECT IDENTIFIER ::= { upsObjects 1 } upsIdentManufacturer OBJECT-TYPE SYNTAX DisplayString (SIZE (0..31)) MAX-ACCESS read-only STATUS current DESCRIPTION "The name of the UPS manufacturer." ::= { upsIdent 1 } upsIdentModel OBJECT-TYPE SYNTAX DisplayString (SIZE (0..63)) MAX-ACCESS read-only STATUS current DESCRIPTION "The UPS Model designation." ::= { upsIdent 2 } upsIdentUPSSoftwareVersion OBJECT-TYPE SYNTAX DisplayString (SIZE (0..63)) MAX-ACCESS read-only STATUS current DESCRIPTION Expires June 1994 [Page 6] draft UPS MIB December 1993 "The UPS firmware/software version(s). This variable may or may not have the same value as upsIdentAgentSoftwareVersion in some implementations." ::= { upsIdent 3 } upsIdentAgentSoftwareVersion OBJECT-TYPE SYNTAX DisplayString (SIZE (0..63)) MAX-ACCESS read-only STATUS current DESCRIPTION "The UPS agent software version. This variable may or may not have the same value as upsIdentUPSSoftwareVersion in some implementations." ::= { upsIdent 4 } upsIdentName OBJECT-TYPE SYNTAX DisplayString (SIZE(0..63)) MAX-ACCESS read-write STATUS current DESCRIPTION "A string identifying the UPS. This object should be set by the administrator." ::= { upsIdent 5 } upsIdentAttachedDevices OBJECT-TYPE SYNTAX DisplayString (SIZE(0..63)) MAX-ACCESS read-write STATUS current DESCRIPTION "A string identifying the devices attached to the output(s) of the UPS. This object should be set by the administrator." ::= { upsIdent 6 } Expires June 1994 [Page 7] draft UPS MIB December 1993 -- -- Battery Group -- upsBattery OBJECT IDENTIFIER ::= { upsObjects 2 } upsBatteryStatus OBJECT-TYPE SYNTAX INTEGER { unknown(1), batteryNormal(2), batteryLow(3), batteryDepleted(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The indication of the capacity remaining in the UPS system's batteries. A value of batteryNormal indicates that the remaining run-time is greater than | upsConfigLowBattTime. | A value of batteryLow indicates that the remaining battery run-time is less than or equal to | upsConfigLowBattTime. A value of batteryDepleted | indicates that the UPS will be unable to sustain the present load when and if the utility power is lost (including the possibility that the utility power is currently absent and the UPS is unable to sustain the output)." ::= { upsBattery 1 } upsSecondsOnBattery OBJECT-TYPE SYNTAX NonNegativeInteger UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "If the unit is on battery power, the elapsed time since the UPS last switched to battery power, or the time since the network management subsystem was last restarted, whichever is less. Zero shall be returned if the unit is not on battery power." ::= { upsBattery 2 } upsEstimatedMinutesRemaining OBJECT-TYPE SYNTAX PositiveInteger Expires June 1994 [Page 8] draft UPS MIB December 1993 UNITS "minutes" MAX-ACCESS read-only STATUS current DESCRIPTION "An estimate of the time to battery charge depletion under the present load conditions if the utility power were to be lost and remain off." ::= { upsBattery 3 } upsEstimatedChargeRemaining OBJECT-TYPE SYNTAX INTEGER (0..100) MAX-ACCESS read-only STATUS current DESCRIPTION "An estimate of the battery charge remaining expressed as a percent of full charge." ::= { upsBattery 4 } upsBatteryVoltage OBJECT-TYPE SYNTAX NonNegativeInteger UNITS "0.1 Volt DC" MAX-ACCESS read-only STATUS current DESCRIPTION "The magnitude of the present battery voltage." ::= { upsBattery 5 } upsBatteryCurrent OBJECT-TYPE SYNTAX Integer32 | UNITS "0.1 Amp DC" MAX-ACCESS read-only STATUS current DESCRIPTION "The present battery current." ::= { upsBattery 6 } upsBatteryTemperature OBJECT-TYPE SYNTAX Integer32 | UNITS "degrees Centigrade" MAX-ACCESS read-only STATUS current DESCRIPTION "The ambient temperature at or near the UPS Battery casing." ::= { upsBattery 7 } Expires June 1994 [Page 9] draft UPS MIB December 1993 -- -- Input Group -- upsInput OBJECT IDENTIFIER ::= { upsObjects 3 } upsInputFrequency OBJECT-TYPE SYNTAX NonNegativeInteger UNITS "0.1 Hertz" MAX-ACCESS read-only STATUS current DESCRIPTION "The present input frequency." ::= { upsInput 1 } upsInputLineBads OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of times the input entered an out-of-tolerance condition as defined by the manufacturer." ::= { upsInput 2 } upsInputNumLines OBJECT-TYPE SYNTAX NonNegativeInteger MAX-ACCESS read-only STATUS current DESCRIPTION "The number of input lines utilized in this device. This variable indicates the number of rows in the input table." ::= { upsInput 3 } upsInputTable OBJECT-TYPE SYNTAX SEQUENCE OF UpsInputEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of input table entries. The number of entries is given by the value of upsInputNumLines." ::= { upsInput 4 } Expires June 1994 [Page 10] draft UPS MIB December 1993 upsInputEntry OBJECT-TYPE SYNTAX UpsInputEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry containing information applicable to a particular input line." INDEX { upsInputLineIndex } ::= { upsInputTable 1 } UpsInputEntry ::= SEQUENCE { upsInputLineIndex PositiveInteger, upsInputVoltage NonNegativeInteger, upsInputCurrent NonNegativeInteger, upsInputTruePower NonNegativeInteger | } upsInputLineIndex OBJECT-TYPE SYNTAX PositiveInteger MAX-ACCESS not-accessible STATUS current DESCRIPTION "The input line identifier." ::= { upsInputEntry 1 } upsInputVoltage OBJECT-TYPE SYNTAX NonNegativeInteger UNITS "RMS Volts" MAX-ACCESS read-only STATUS current DESCRIPTION "The magnitude of the present input voltage." ::= { upsInputEntry 2 } upsInputCurrent OBJECT-TYPE SYNTAX NonNegativeInteger UNITS "0.1 RMS Amp" MAX-ACCESS read-only STATUS current DESCRIPTION "The magnitude of the present input current." ::= { upsInputEntry 3 } upsInputTruePower OBJECT-TYPE | SYNTAX NonNegativeInteger Expires June 1994 [Page 11] draft UPS MIB December 1993 UNITS "Watts" MAX-ACCESS read-only STATUS current DESCRIPTION "The magnitude of the present input true power." ::= { upsInputEntry 4 } Expires June 1994 [Page 12] draft UPS MIB December 1993 -- -- The Output group. -- upsOutput OBJECT IDENTIFIER ::= { upsObjects 4 } upsOutputSource OBJECT-TYPE SYNTAX INTEGER { other(1), none(2), | normal(3), | bypass(4), | battery(5), | booster(6), | reducer(7) | } MAX-ACCESS read-only STATUS current DESCRIPTION "The present source of output power. The enumeration | none(2) indicates that there is no source of output | power (and therefore no output power), for example, | the system has opened the output breaker." | ::= { upsOutput 1 } upsOutputFrequency OBJECT-TYPE SYNTAX NonNegativeInteger UNITS "0.1 Hertz" MAX-ACCESS read-only STATUS current DESCRIPTION "The present output frequency." ::= { upsOutput 2 } upsOutputNumLines OBJECT-TYPE SYNTAX NonNegativeInteger MAX-ACCESS read-only STATUS current DESCRIPTION "The number of output lines utilized in this device. This variable indicates the number of rows in the output table." ::= { upsOutput 3 } upsOutputTable OBJECT-TYPE Expires June 1994 [Page 13] draft UPS MIB December 1993 SYNTAX SEQUENCE OF UpsOutputEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of output table entries. The number of entries is given by the value of upsOutputNumLines." ::= { upsOutput 4 } upsOutputEntry OBJECT-TYPE SYNTAX UpsOutputEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry containing information applicable to a particular output line." INDEX { upsOutputLineIndex } ::= { upsOutputTable 1 } UpsOutputEntry ::= SEQUENCE { upsOutputLineIndex PositiveInteger, upsOutputVoltage NonNegativeInteger, upsOutputCurrent NonNegativeInteger, upsOutputPower NonNegativeInteger, upsOutputPercentLoad NonNegativeInteger } upsOutputLineIndex OBJECT-TYPE SYNTAX PositiveInteger MAX-ACCESS not-accessible STATUS current DESCRIPTION "The output line identifier." ::= { upsOutputEntry 1 } upsOutputVoltage OBJECT-TYPE SYNTAX NonNegativeInteger UNITS "RMS Volts" MAX-ACCESS read-only STATUS current DESCRIPTION "The present output voltage." ::= { upsOutputEntry 2 } upsOutputCurrent OBJECT-TYPE SYNTAX NonNegativeInteger Expires June 1994 [Page 14] draft UPS MIB December 1993 UNITS "0.1 RMS Amp" MAX-ACCESS read-only STATUS current DESCRIPTION "The present output current." ::= { upsOutputEntry 3 } upsOutputPower OBJECT-TYPE SYNTAX NonNegativeInteger UNITS "Watts" MAX-ACCESS read-only STATUS current DESCRIPTION "The present output true power." ::= { upsOutputEntry 4 } upsOutputPercentLoad OBJECT-TYPE SYNTAX NonNegativeInteger UNITS "percent" MAX-ACCESS read-only STATUS current DESCRIPTION "The percentage of the UPS power capacity presently being used, i.e., the greater of the percent load of true power capacity and the percent load of VA." ::= { upsOutputEntry 5 } Expires June 1994 [Page 15] draft UPS MIB December 1993 -- -- The Bypass group. -- upsBypass OBJECT IDENTIFIER ::= { upsObjects 5 } upsBypassFrequency OBJECT-TYPE SYNTAX NonNegativeInteger UNITS "0.1 Hertz" MAX-ACCESS read-only STATUS current DESCRIPTION "The present bypass frequency." ::= { upsBypass 1 } upsBypassNumLines OBJECT-TYPE SYNTAX NonNegativeInteger MAX-ACCESS read-only STATUS current DESCRIPTION "The number of bypass lines utilized in this device. This entry indicates the number of rows in the bypass table." ::= { upsBypass 2 } upsBypassTable OBJECT-TYPE SYNTAX SEQUENCE OF UpsBypassEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of bypass table entries. The number of entries is given by the value of upsBypassNumLines." ::= { upsBypass 3 } upsBypassEntry OBJECT-TYPE SYNTAX UpsBypassEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry containing information applicable to a particular bypass input." INDEX { upsBypassLineIndex } ::= { upsBypassTable 1 } UpsBypassEntry ::= SEQUENCE { Expires June 1994 [Page 16] draft UPS MIB December 1993 upsBypassLineIndex PositiveInteger, upsBypassVoltage NonNegativeInteger, upsBypassCurrent NonNegativeInteger, upsBypassPower NonNegativeInteger } upsBypassLineIndex OBJECT-TYPE SYNTAX PositiveInteger MAX-ACCESS not-accessible STATUS current DESCRIPTION "The bypass line identifier." ::= { upsBypassEntry 1 } upsBypassVoltage OBJECT-TYPE SYNTAX NonNegativeInteger UNITS "RMS Volts" MAX-ACCESS read-only STATUS current DESCRIPTION "The present bypass voltage." ::= { upsBypassEntry 2 } upsBypassCurrent OBJECT-TYPE SYNTAX NonNegativeInteger UNITS "0.1 RMS Amp" MAX-ACCESS read-only STATUS current DESCRIPTION "The present bypass current." ::= { upsBypassEntry 3 } upsBypassPower OBJECT-TYPE SYNTAX NonNegativeInteger UNITS "Watts" MAX-ACCESS read-only STATUS current DESCRIPTION "The present true power conveyed by the bypass." ::= { upsBypassEntry 4 } Expires June 1994 [Page 17] draft UPS MIB December 1993 -- -- The Alarm group. -- upsAlarm OBJECT IDENTIFIER ::= { upsObjects 6 } upsAlarmsPresent OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The present number of active alarm conditions." ::= { upsAlarm 1 } upsAlarmTable OBJECT-TYPE SYNTAX SEQUENCE OF UpsAlarmEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of alarm table entries. The table contains zero, one, or many rows at any moment, depending upon the number of alarm conditions in effect. The table is initially empty at agent startup. The agent creates a row in the table each time a condition is detected and deletes that row when that condition no longer pertains. The agent creates the first row with upsAlarmId equal to 1, and increments the value of upsAlarmId each time a new row is created, wrapping to the first free value greater than or equal to 1 when the maximum value of upsAlarmId would otherwise be exceeded. Consequently, after multiple operations, the table may become sparse, e.g., containing entries for rows 95, 100, 101, and 203 and the entries are in chronological order until upsAlarmId wraps. Alarms are named by an OBJECT IDENTIFIER, upsAlarmDescr, to allow a single table to reflect well known alarms plus alarms defined by a particular implementation, i.e., as documented in the private enterprise MIB definition for the device. No two rows will have the same value of upsAlarmDescr, since alarms define conditions. In order to meet this requirement, care should be taken in the definition of alarm conditions to insure that a system cannot enter the same condition multiple times simultaneously. Expires June 1994 [Page 18] draft UPS MIB December 1993 The number of active rows in the table at any given time is reflected by the value of upsAlarmsPresent." ::= { upsAlarm 2 } upsAlarmEntry OBJECT-TYPE SYNTAX UpsAlarmEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry containing information applicable to a particular alarm." INDEX { upsAlarmId } ::= { upsAlarmTable 1 } UpsAlarmEntry ::= SEQUENCE { upsAlarmId PositiveInteger, upsAlarmDescr OBJECT IDENTIFIER, upsAlarmTime TimeStamp } upsAlarmId OBJECT-TYPE SYNTAX PositiveInteger MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique identifier for an alarm condition. This value must remain constant." ::= { upsAlarmEntry 1 } upsAlarmDescr OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "A reference to an alarm description object. The object referenced should not be accessible, but rather be used to provide a unique description of the alarm condition." ::= { upsAlarmEntry 2 } upsAlarmTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION Expires June 1994 [Page 19] draft UPS MIB December 1993 "The value of sysUpTime when the alarm condition was detected. If the alarm condition was detected at the time of agent startup and presumably existed before agent startup, the value of upsAlarmTime shall equal 0." ::= { upsAlarmEntry 3 } -- -- Well known alarm conditions. -- upsWellKnownAlarms OBJECT IDENTIFIER ::= { upsAlarm 3 } upsAlarmBatteryBad OBJECT-IDENTITY STATUS current DESCRIPTION "One or more batteries have been determined to require replacement." ::= { upsWellKnownAlarms 1 } upsAlarmOnBattery OBJECT-IDENTITY STATUS current DESCRIPTION "The UPS is drawing power from the batteries." ::= { upsWellKnownAlarms 2 } upsAlarmLowBattery OBJECT-IDENTITY STATUS current DESCRIPTION "The remaining battery run-time is less than or equal to upsConfigLowBattTime." | ::= { upsWellKnownAlarms 3 } upsAlarmDepletedBattery OBJECT-IDENTITY STATUS current DESCRIPTION "The UPS will be unable to sustain the present load when and if the utility power is lost." ::= { upsWellKnownAlarms 4 } upsAlarmTempBad OBJECT-IDENTITY STATUS current Expires June 1994 [Page 20] draft UPS MIB December 1993 DESCRIPTION "A temperature is out of tolerance." ::= { upsWellKnownAlarms 5 } upsAlarmInputBad OBJECT-IDENTITY STATUS current DESCRIPTION "An input condition is out of tolerance." ::= { upsWellKnownAlarms 6 } upsAlarmOutputBad OBJECT-IDENTITY STATUS current DESCRIPTION "An output condition (other than OutputOverload) is out of tolerance." ::= { upsWellKnownAlarms 7 } upsAlarmOutputOverload OBJECT-IDENTITY STATUS current DESCRIPTION "The output load exceeds the UPS output capacity." ::= { upsWellKnownAlarms 8 } upsAlarmOnBypass OBJECT-IDENTITY STATUS current DESCRIPTION "The Bypass is presently engaged on the UPS." ::= { upsWellKnownAlarms 9 } upsAlarmBypassBad OBJECT-IDENTITY STATUS current DESCRIPTION "The Bypass is out of tolerance." ::= { upsWellKnownAlarms 10 } upsAlarmOutputOffAsRequested OBJECT-IDENTITY STATUS current DESCRIPTION "The UPS has shutdown as requested, i.e., the output is off." ::= { upsWellKnownAlarms 11 } upsAlarmUpsOffAsRequested OBJECT-IDENTITY STATUS current DESCRIPTION Expires June 1994 [Page 21] draft UPS MIB December 1993 "The entire UPS has shutdown as commanded." ::= { upsWellKnownAlarms 12 } upsAlarmChargerFailed OBJECT-IDENTITY STATUS current DESCRIPTION "An uncorrected problem has been detected within the UPS charger subsystem." ::= { upsWellKnownAlarms 13 } upsAlarmUpsOutputOff OBJECT-IDENTITY STATUS current DESCRIPTION "The output of the UPS is in the off state." ::= { upsWellKnownAlarms 14 } upsAlarmUpsSystemOff OBJECT-IDENTITY STATUS current DESCRIPTION "The UPS system is in the off state." ::= { upsWellKnownAlarms 15 } upsAlarmFanFailure OBJECT-IDENTITY STATUS current DESCRIPTION "The failure of one or more fans in the UPS has been detected." ::= { upsWellKnownAlarms 16 } upsAlarmFuseFailure OBJECT-IDENTITY STATUS current DESCRIPTION "The failure of one or more fuses has been detected." ::= { upsWellKnownAlarms 17 } upsAlarmGeneralFault OBJECT-IDENTITY STATUS current DESCRIPTION "A general fault in the UPS has been detected." ::= { upsWellKnownAlarms 18 } upsAlarmDiagnosticTestFailed OBJECT-IDENTITY STATUS current DESCRIPTION "The result of the last diagnostic test indicates a Expires June 1994 [Page 22] draft UPS MIB December 1993 failure." ::= { upsWellKnownAlarms 19 } upsAlarmCommunicationsLost OBJECT-IDENTITY STATUS current DESCRIPTION "A problem has been encountered in the communications between the agent and the UPS." ::= { upsWellKnownAlarms 20 } upsAlarmAwaitingPower OBJECT-IDENTITY STATUS current DESCRIPTION "The UPS output is off and the UPS is awaiting the return of input power." ::= { upsWellKnownAlarms 21 } upsAlarmShutdownPending OBJECT-IDENTITY STATUS current DESCRIPTION "A upsShutdownAfterDelay countdown is underway." ::= { upsWellKnownAlarms 22 } upsAlarmShutdownImminent OBJECT-IDENTITY STATUS current DESCRIPTION "The UPS will turn off power to the load in less than 5 seconds; this may be either a timed shutdown or a low battery shutdown." ::= { upsWellKnownAlarms 23 } upsAlarmTestInProgress OBJECT-IDENTITY STATUS current DESCRIPTION "A test is in progress, as initiated and indicated by the Test Group. Tests initiated via other implementation-specific mechanisms can indicate the presence of the testing in the alarm table, if desired, via a OBJECT-IDENTITY macro in the MIB document specific to that implementation and are outside the scope of this OBJECT-IDENTITY." ::= { upsWellKnownAlarms 24 } Expires June 1994 [Page 23] draft UPS MIB December 1993 -- -- The Test Group -- upsTest OBJECT IDENTIFIER ::= { upsObjects 7 } upsTestId OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-write STATUS current DESCRIPTION "The test is named by an OBJECT IDENTIFIER which allows a standard mechanism for the initiation of tests, including the well known tests identified in this document as well as those introduced by a particular implementation, i.e., as documented in the private enterprise MIB definition for the device. Setting this variable initiates the named test. Sets to this variable require the presence of upsTestSpinLock in the same SNMP message. The set request will be rejected with an appropriate error message if the requested test cannot be performed, including attempts to start a test when another test is already in progress. Tests in progress may be aborted by setting this variable to upsTestAbortTestInProgress. Read operations return the value of the name of the test in progress if a test is in progress or the name of the last test performed if no test is in progress, unless no test has been run, in which case the well known value upsTestNoTestsInitiated is returned." ::= { upsTest 1 } -- see [10] for more information on the semantics of objects with -- syntax of TestAndIncr | upsTestSpinLock OBJECT-TYPE SYNTAX TestAndIncr | MAX-ACCESS read-write STATUS current DESCRIPTION "A spin lock on the test subsystem. The spinlock is Expires June 1994 [Page 24] draft UPS MIB December 1993 used as follows. Before starting a test, a manager-station should make sure that a test is not in progress as follows: try_again: get (upsTestSpinLock) | while (upsTestResultsSummary == inProgress) { | /* loop while a test is running for another manager */ short delay get (upsTestSpinLock) } lock_value = upsTestSpinLock /* no test in progress, start the test */ set (upsTestSpinLock = lock_value, upsTestId = requested_test) if (error_index == 1) { /* (upsTestSpinLock failed) */ /* if problem is not access control, then some other manager slipped in ahead of us */ goto try_again } if (error_index == 2) { /* (upsTestId) */ /* cannot perform the test */ give up } /* test started ok */ /* wait for test completion by polling upsTestResultsSummary */ get (upsTestSpinLock, upsTestResultsSummary, upsTestResultsDetail) while (upsTestResultsSummary == inProgress) { short delay get (upsTestSpinLock, upsTestResultsSummary, upsTestResultsDetail) } /* when test completes, retrieve any additional test results */ /* if upsTestSpinLock == lock_value + 1, then these are our test */ /* results (as opposed to another manager's */ The initial value of upsTestSpinLock at agent Expires June 1994 [Page 25] draft UPS MIB December 1993 initialization shall be 1." ::= { upsTest 2 } upsTestResultsSummary OBJECT-TYPE SYNTAX INTEGER { donePass(1), doneWarning(2), doneError(3), aborted(4), inProgress(5), noTestsInitiated(6) } MAX-ACCESS read-only STATUS current DESCRIPTION "The results of the current or last UPS diagnostics test performed. The values for donePass(1), doneWarning(2), and doneError(3) are self-documenting. The value aborted(4) is returned for tests which are aborted by setting the value of upsTestId to upsTestAbortTestInProgress. Tests which have not yet concluded are indicated by inProgress(5). The value noTestsInitiated(6) indicates that no previous test results are available, such as is the case when no tests have been run since the last reinitialization of the network management subsystem and the system has no provision for non-volatile storage of test results." ::= { upsTest 3 } upsTestResultsDetail OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "Additional information about upsTestResultsSummary. If no additional information available, a zero length string is returned." ::= { upsTest 4 } upsTestStartTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION Expires June 1994 [Page 26] draft UPS MIB December 1993 "The value of sysUpTime at the time the test in progress was initiated, or, if no test is in progress, the time the previous test was initiated. If the value of upsTestResultsSummary is noTestsInitiated(6), upsTestStartTime has the value 0." ::= { upsTest 5 } upsTestElapsedTime OBJECT-TYPE SYNTAX TimeInterval MAX-ACCESS read-only STATUS current DESCRIPTION "The amount of time, in TimeTicks, since the test in progress was initiated, or, if no test is in progress, the previous test took to complete. If the value of upsTestResultsSummary is noTestsInitiated(6), upsTestElapsedTime has the value 0." ::= { upsTest 6 } -- -- Well known tests. -- upsWellKnownTests OBJECT IDENTIFIER ::= { upsTest 7 } upsTestNoTestsInitiated OBJECT-IDENTITY STATUS current DESCRIPTION "No tests have been initiated and no test is in progress." ::= { upsWellKnownTests 1 } upsTestAbortTestInProgress OBJECT-IDENTITY STATUS current DESCRIPTION "The test in progress is to be aborted / the test in progress was aborted." ::= { upsWellKnownTests 2 } upsTestGeneralSystemsTest OBJECT-IDENTITY STATUS current DESCRIPTION "The manufacturer's standard test of UPS device systems." Expires June 1994 [Page 27] draft UPS MIB December 1993 ::= { upsWellKnownTests 3 } upsTestQuickBatteryTest OBJECT-IDENTITY STATUS current DESCRIPTION "A test that is sufficient to determine if the battery needs replacement." ::= { upsWellKnownTests 4 } upsTestDeepBatteryCalibration OBJECT-IDENTITY STATUS current DESCRIPTION "The system is placed on battery to a discharge level, set by the manufacturer, sufficient to determine battery replacement and battery run-time with a high degree of confidence. WARNING: this test will leave the battery in a low charge state and will require time for recharging to a level sufficient to provide normal battery duration for the protected load." ::= { upsWellKnownTests 5 } Expires June 1994 [Page 28] draft UPS MIB December 1993 -- -- The Control group. -- upsControl OBJECT IDENTIFIER ::= { upsObjects 8 } upsShutdownType OBJECT-TYPE SYNTAX INTEGER { output(1), system(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object determines the action taken by the upsShutdownAfterDelay and upsRebootWithDuration objects. Setting this object to output(1) indicates that shutdown requests should cause only the output of the UPS to turn off. Setting this object to system(2) indicates that shutdown requests will cause the entire UPS system to turn off." ::= { upsControl 1 } upsShutdownAfterDelay OBJECT-TYPE SYNTAX INTEGER (-1..2147483648) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "Setting this object will shutdown (i.e., turn off) either the UPS output or the UPS system (as determined by the value of upsShutdownType at the time of shutdown) after the indicated number of seconds, or less if the UPS batteries become depleted. Setting this object to 0 will cause the shutdown to occur immediately. Setting this object to -1 will abort the countdown. If the system is already in the desired state at the time the countdown reaches 0, then nothing will happen. That is, there is no additional action at that time if upsShutdownType = system and the system is already off. Similarly, there is no additional action at that time if upsShutdownType = output and the output is already off. When read, upsShutdownAfterDelay will return the number of seconds remaining until shutdown, or -1 if no shutdown Expires June 1994 [Page 29] draft UPS MIB December 1993 countdown is in effect. On some systems, if the agent is restarted while a shutdown countdown is in effect, the countdown may be aborted. Sets to this object override any upsShutdownAfterDelay already in effect." ::= { upsControl 2 } upsStartupAfterDelay OBJECT-TYPE SYNTAX INTEGER (-1..2147483648) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "Setting this object will start the output after the indicated number of seconds, including starting the UPS, if necessary. Setting this object to 0 will cause the startup to occur immediately. Setting this object to -1 will abort the countdown. If the output is already on at the time the countdown reaches 0, then nothing will happen. Sets to this object override the effect of any upsStartupAfterDelay countdown or upsRebootWithDuration countdown in progress. When read, upsStartupAfterDelay will return the number of seconds until startup, or -1 if no startup countdown is in effect. If the countdown expires during a utility failure, the startup shall depend upon the value of upsAutoRestart at that time. On some systems, if the agent is restarted while a startup countdown is in effect, the countdown is aborted." ::= { upsControl 3 } | upsRebootWithDuration OBJECT-TYPE SYNTAX INTEGER (-1..300) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "Setting this object will immediately shutdown (i.e., turn off) either the UPS output or the UPS system (as determined by the value of upsShutdownType at the time of shutdown) for a period equal to the indicated number of seconds, after which time the output will be started, including starting the UPS, if necessary. If the number of seconds required to perform the request is greater than the requested duration, then the Expires June 1994 [Page 30] draft UPS MIB December 1993 requested shutdown and startup cycle shall be performed in the minimum time possible, but in no case shall this require more than the requested duration plus 60 seconds. When read, upsRebootWithDuration shall return the number of seconds remaining in the countdown, or -1 if no countdown is in progress. If the startup should occur during a utility failure, the startup shall depend upon the value of upsAutoRestart at that time." ::= { upsControl 4 } | upsAutoRestart OBJECT-TYPE SYNTAX INTEGER { on(1), off(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Setting this object to 'on' will cause the UPS system to restart after a shutdown if/when utility power is | present. Setting this object to 'off' will prevent | the UPS system from restarting after a shutdown until | an operator manually or remotely explicitly restarts | it." | ::= { upsControl 5 } | Expires June 1994 [Page 31] draft UPS MIB December 1993 -- -- The Configuration group. -- upsConfig OBJECT IDENTIFIER ::= { upsObjects 9 } upsConfigInputVoltage OBJECT-TYPE SYNTAX NonNegativeInteger UNITS "RMS Volts" MAX-ACCESS read-write STATUS current DESCRIPTION "The magnitude of the nominal input voltage. On those systems which support read-write access to this object, if there is an attempt to set this variable to a value that is not supported, the request must be rejected and the agent shall respond with an appropriate error message, i.e., badValue for SNMPv1, or inconsistentValue for SNMPv2." ::= { upsConfig 1 } upsConfigInputFreq OBJECT-TYPE SYNTAX NonNegativeInteger UNITS "0.1 Hertz" MAX-ACCESS read-write STATUS current DESCRIPTION "The nominal input frequency. On those systems which support read-write access to this object, if there is an attempt to set this variable to a value that is not supported, the request must be rejected and the agent shall respond with an appropriate error message, i.e., badValue for SNMPv1, or inconsistentValue for SNMPv2." ::= { upsConfig 2 } upsConfigOutputVoltage OBJECT-TYPE SYNTAX NonNegativeInteger UNITS "RMS Volts" MAX-ACCESS read-write STATUS current DESCRIPTION "The magnitude of the nominal output voltage. On those systems which support read-write access to this object, if there is an attempt to set this variable to a value that is not supported, the request must be Expires June 1994 [Page 32] draft UPS MIB December 1993 rejected and the agent shall respond with an appropriate error message, i.e., badValue for SNMPv1, or inconsistentValue for SNMPv2." ::= { upsConfig 3 } upsConfigOutputFreq OBJECT-TYPE SYNTAX NonNegativeInteger UNITS "0.1 Hertz" MAX-ACCESS read-write STATUS current DESCRIPTION "The nominal output frequency. On those systems which support read-write access to this object, if there is an attempt to set this variable to a value that is not supported, the request must be rejected and the agent shall respond with an appropriate error message, i.e., badValue for SNMPv1, or inconsistentValue for SNMPv2." ::= { upsConfig 4 } upsConfigOutputVA OBJECT-TYPE SYNTAX NonNegativeInteger UNITS "Volt-Amps" MAX-ACCESS read-only STATUS current DESCRIPTION "The magnitude of the nominal Volt-Amp rating." ::= { upsConfig 5 } upsConfigOutputPower OBJECT-TYPE SYNTAX NonNegativeInteger UNITS "Watts" MAX-ACCESS read-only STATUS current DESCRIPTION "The magnitude of the nominal true power rating." ::= { upsConfig 6 } upsConfigLowBattTime OBJECT-TYPE | SYNTAX NonNegativeInteger UNITS "minutes" MAX-ACCESS read-write STATUS current DESCRIPTION "The value of upsEstimatedMinutesRemaining at which a lowBattery condition is declared. For agents which Expires June 1994 [Page 33] draft UPS MIB December 1993 support only discrete (discontinuous) values, then the agent shall round up to the next supported value. If the requested value is larger than the largest supported value, then the largest supported value shall be selected." ::= { upsConfig 7 } upsConfigAudibleStatus OBJECT-TYPE SYNTAX INTEGER { disabled(1), enabled(2), muted(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "The requested state of the audible alarm. When in the disabled state, the audible alarm should never sound. The enabled state is self-describing. Setting this object to muted(3) when the audible alarm is sounding shall temporarily silence the alarm. It will remain muted until it would normally stop sounding and the value returned for read operations during this period shall equal muted(3). At the end of this period, the value shall revert to enabled(2). Writes of the value muted(3) when the audible alarm is not sounding shall be accepted but shall have no effect." ::= { upsConfig 8 } upsConfigLowVoltageTransferPoint OBJECT-TYPE SYNTAX NonNegativeInteger UNITS "RMS Volts" MAX-ACCESS read-write STATUS current DESCRIPTION "The minimum input line voltage allowed before the UPS system transfers to battery backup." ::= { upsConfig 9 } upsConfigHighVoltageTransferPoint OBJECT-TYPE SYNTAX NonNegativeInteger UNITS "RMS Volts" MAX-ACCESS read-write STATUS current DESCRIPTION Expires June 1994 [Page 34] draft UPS MIB December 1993 "The maximum line voltage allowed before the UPS system transfers to battery backup." ::= { upsConfig 10 } Expires June 1994 [Page 35] draft UPS MIB December 1993 -- -- notifications, i.e., traps -- upsTraps OBJECT IDENTIFIER ::= { upsMibE26 2 } | -- This section defines the well-known notifications sent by | -- UPS agents. | -- Care must be taken to insure that no particular notification -- is sent to a single receiving entity more often than once -- every five seconds. upsTrapOnBattery NOTIFICATION-TYPE OBJECTS { upsEstimatedMinutesRemaining, upsSecondsOnBattery, upsConfigLowBattTime } | STATUS current DESCRIPTION "The UPS is operating on battery power. This trap is persistent and is resent at one minute intervals until the UPS either turns off or is no longer running on battery." ::= { upsTraps 1 } upsTrapTestCompleted NOTIFICATION-TYPE OBJECTS { upsTestId, upsTestSpinLock, upsTestResultsSummary, upsTestResultsDetail, upsTestStartTime, upsTestElapsedTime } STATUS current DESCRIPTION "This trap is sent upon completion of a UPS diagnostic test." ::= { upsTraps 2 } upsTrapAlarmEntryAdded NOTIFICATION-TYPE OBJECTS { upsAlarmId, upsAlarmDescr } STATUS current DESCRIPTION "This trap is sent each time an alarm is inserted into to the alarm table. It is sent on the insertion all alarms except for upsAlarmOnBattery and upsAlarmTestInProgress." ::= { upsTraps 3 } upsTrapAlarmEntryRemoved NOTIFICATION-TYPE OBJECTS { upsAlarmId, upsAlarmDescr } STATUS current Expires June 1994 [Page 36] draft UPS MIB December 1993 DESCRIPTION "This trap is sent each time an alarm is removed from the alarm table. It is sent on the removal of all | alarms except for upsAlarmTestInProgress." | ::= { upsTraps 4 } Expires June 1994 [Page 37] draft UPS MIB December 1993 -- -- conformance information -- upsConformance OBJECT IDENTIFIER ::= { upsMibE26 3 } | upsCompliances OBJECT IDENTIFIER ::= { upsConformance 1 } -- -- compliance statements -- upsSubsetCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for UPSs that only support the basic two-contact communication protocol." MODULE -- this module MANDATORY-GROUPS { upsSubsetIdentGroup, upsSubsetBatteryGroup, upsSubsetInputGroup, upsSubsetOutputGroup, upsSubsetAlarmGroup, upsSubsetControlGroup, upsSubsetConfigGroup } OBJECT upsBatteryStatus SYNTAX INTEGER { batteryNormal(2), batteryLow(3) } DESCRIPTION "Support of the values unknown(1) and batteryDepleted(4) is not required." OBJECT upsAlarmDescr DESCRIPTION "Support of all `well known' alarm types is not required. The well known alarm types which must be supported are: - upsAlarmOnBattery, upsAlarmLowBattery, - upsAlarmInputBad, - upsAlarmUpsOutputOff, upsAlarmUpsSystemOff, - and upsAlarmTestInProgress." OBJECT upsOutputSource SYNTAX INTEGER { Expires June 1994 [Page 38] draft UPS MIB December 1993 normal(2), battery(4) } DESCRIPTION "Support of the values other(1), none(2), bypass(4), | booster(6) and reducer(7) | is not required." OBJECT upsShutdownType MIN-ACCESS read-only DESCRIPTION "Read-write access is not required, i.e., compliant systems need not support more than one shutdown type." OBJECT upsAutoRestart + MIN-ACCESS read-only + DESCRIPTION + "Read-write access is not required, i.e., compliant + systems need not support more than one restart type." + OBJECT upsConfigInputVoltage MIN-ACCESS read-only DESCRIPTION "Read-write access is not required." OBJECT upsConfigInputFreq MIN-ACCESS read-only DESCRIPTION "Read-write access is not required." OBJECT upsConfigOutputVoltage MIN-ACCESS read-only DESCRIPTION "Read-write access is not required." OBJECT upsConfigOutputFreq MIN-ACCESS read-only DESCRIPTION "Read-write access is not required." ::= { upsCompliances 1 } upsBasicCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION Expires June 1994 [Page 39] draft UPS MIB December 1993 "The compliance statement for UPSs that support full-featured functions, such as control." MODULE -- this module MANDATORY-GROUPS { upsBasicIdentGroup, upsBasicBatteryGroup, upsBasicInputGroup, upsBasicOutputGroup, upsBasicAlarmGroup, upsBasicTestGroup, upsBasicControlGroup, upsBasicConfigGroup } OBJECT upsAlarmDescr DESCRIPTION "Support of all `well known' alarm types is not required. The well known alarm types which must be supported are: upsAlarmOnBattery, upsAlarmLowBattery, + upsAlarmDepletedBattery, upsAlarmTempBad, + upsAlarmInputBad, upsAlarmOutputOverload, + upsAlarmOnBypass, upsAlarmBypassBad, + upsAlarmOutputOffAsRequested, + upsAlarmUpsOffAsRequested, + upsAlarmUpsOutputOff, upsAlarmUpsSystemOff, + upsAlarmGeneralFault, upsAlarmDiagnosticTestFailed, + upsAlarmCommunicationsLost, upsAlarmShutdownPending, + and upsAlarmTestInProgress." OBJECT upsTestId DESCRIPTION "Support of all `well known' test types is not required. If no tests are supported, then the testing The well known test types which must be supported are: | upsTestNoTestsInitiated." | OBJECT upsOutputSource SYNTAX INTEGER { normal(2), battery(4) } DESCRIPTION "Support of the values other(1), none(2), bypass(4), | booster(6) and reducer(7) | is not required." GROUP upsBasicBypassGroup DESCRIPTION "The upsBasicBypassGroup is only required for UPSs that have a Bypass present." Expires June 1994 [Page 40] draft UPS MIB December 1993 OBJECT upsShutdownType MIN-ACCESS read-only DESCRIPTION "Read-write access is not required, i.e., compliant systems need not support more than one shutdown type." OBJECT upsAutoRestart + MIN-ACCESS read-only + DESCRIPTION + "Read-write access is not required, i.e., compliant + systems need not support more than one restart type." + OBJECT upsConfigInputVoltage MIN-ACCESS read-only DESCRIPTION "Read-write access is not required." OBJECT upsConfigInputFreq MIN-ACCESS read-only DESCRIPTION "Read-write access is not required." OBJECT upsConfigOutputVoltage MIN-ACCESS read-only DESCRIPTION "Read-write access is not required." OBJECT upsConfigOutputFreq MIN-ACCESS read-only DESCRIPTION "Read-write access is not required." OBJECT upsConfigLowBattTime | DESCRIPTION "Implementation of all possible values may be onerous for some systems. Consequently, not all possible values must be supported. However, at least two different manufactuerer-selected values must be supported." ::= { upsCompliances 2 } upsFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION Expires June 1994 [Page 41] draft UPS MIB December 1993 "The compliance statement for UPSs that support advanced full-featured functions." MODULE -- this module MANDATORY-GROUPS { upsFullIdentGroup, upsFullBatteryGroup, upsFullInputGroup, upsFullOutputGroup, upsFullAlarmGroup, upsFullTestGroup, upsFullControlGroup, upsFullConfigGroup } OBJECT upsAlarmDescr DESCRIPTION "Support of all `well known' alarm types is not required. The well known alarm types which must be supported are: upsAlarmBatteryBad, upsAlarmOnBattery, upsAlarmLowBattery, upsAlarmDepletedBattery, upsAlarmTempBad, upsAlarmInputBad, upsAlarmOnBypass, upsAlarmBypassBad, upsAlarmOutputOffAsRequested, upsAlarmUpsOffAsRequested, upsAlarmUpsOutputOff, upsAlarmUpsSystemOff, upsAlarmGeneralFault, upsAlarmDiagnosticTestFailed, upsAlarmCommunicationsLost, - upsAlarmShutdownPending, and upsAlarmTestInProgress." OBJECT upsTestId DESCRIPTION "Support of all `well known' test types is not required. The well known test types which must be supported are: upsTestNoTestsInitiated, upsTestGeneralSystemsTest, - and upsTestQuickBatteryTest." | OBJECT upsOutputSource SYNTAX INTEGER { normal(2), battery(4) } DESCRIPTION "Support of the values other(1), none(2), bypass(4), | booster(6) and reducer(7) | is not required." GROUP upsFullBypassGroup DESCRIPTION "The upsFullBypassGroup is only required for UPSs that have a Bypass present." Expires June 1994 [Page 42] draft UPS MIB December 1993 OBJECT upsShutdownType MIN-ACCESS read-only DESCRIPTION "Read-write access is not required, i.e., compliant systems need not support more than one shutdown type." OBJECT upsAutoRestart + MIN-ACCESS read-only + DESCRIPTION + "Read-write access is not required, i.e., compliant + systems need not support more than one restart type." + OBJECT upsConfigInputVoltage MIN-ACCESS read-only DESCRIPTION "Read-write access is not required." OBJECT upsConfigInputFreq MIN-ACCESS read-only DESCRIPTION "Read-write access is not required." OBJECT upsConfigOutputVoltage MIN-ACCESS read-only DESCRIPTION "Read-write access is not required." OBJECT upsConfigOutputFreq MIN-ACCESS read-only DESCRIPTION "Read-write access is not required." OBJECT upsConfigLowBattTime | DESCRIPTION "Implementation of all possible values may be onerous for some systems. Consequently, not all possible values must be supported. However, at least two different manufactuerer-selected values must be supported." ::= { upsCompliances 3 } Expires June 1994 [Page 43] draft UPS MIB December 1993 -- -- units of conformance -- -- summary at a glance: -- subset basic adv --upsIdentManufacturer x x x --upsIdentModel x x x --upsIdentUPSSoftwareVersion x x | --upsIdentAgentSoftwareVersion x x x --upsIdentName x x x --upsIdentAttachedDevices x x -- --upsBatteryStatus x x x notes --upsSecondsOnBattery x x x --upsEstimatedMinutesRemaining x | --upsEstimatedChargeRemaining x | --upsBatteryVoltage --upsBatteryCurrent --upsBatteryTemperature -- --upsInputFrequency x x --upsInputLineBads x x x --upsInputNumLines x x --upsInputVoltage x x --upsInputCurrent --upsInputTruePower | -- --upsOutputSource x x x notes --upsOutputFrequency x x --upsOutputNumLines x x --upsOutputVoltage x x --upsOutputCurrent x --upsOutputPower x --upsOutputPercentLoad x -- -- --upsBypassFrequency x x iff note --upsBypassNumLines x x --upsBypassVoltage x x --upsBypassCurrent --upsBypassPower -- -- Expires June 1994 [Page 44] draft UPS MIB December 1993 --upsAlarmsPresent x x x --upsAlarmDescr x x x notes --upsAlarmTime x x x -- --upsTestId x x notes --upsTestSpinLock x x --upsTestResultsSummary x x --upsTestResultsDetail x x --upsTestStartTime x x --upsTestElapsedTime x x -- --upsShutdownType x x x notes --upsShutdownAfterDelay x x x --upsStartupAfterDelay x x --upsRebootWithDuration x x --upsAutoRestart x x x notes| -- --upsConfigInputVoltage x x x notes --upsConfigInputFreq x x x notes --upsConfigOutputVoltage x x x notes --upsConfigOutputFreq x x x notes --upsConfigOutputVA x x x --upsConfigOutputPower x x x --upsConfigLowBattTime x x at least 2| --upsConfigAudibleStatus x x --upsConfigLowVoltageTransferPoint --upsConfigHighVoltageTransferPoint Expires June 1994 [Page 45] draft UPS MIB December 1993 -- units of conformance upsGroups OBJECT IDENTIFIER ::= { upsConformance 2 } upsSubsetGroups OBJECT IDENTIFIER ::= { upsGroups 1 } upsSubsetIdentGroup OBJECT-GROUP OBJECTS { upsIdentManufacturer, upsIdentModel, upsIdentAgentSoftwareVersion, upsIdentName, - upsIdentAttachedDevices } STATUS current DESCRIPTION "The upsSubsetIdentGroup defines objects which are common across all UPSs which meet subset compliance." ::= { upsSubsetGroups 1 } upsSubsetBatteryGroup OBJECT-GROUP OBJECTS { upsBatteryStatus, upsSecondsOnBattery } STATUS current DESCRIPTION "The upsSubsetBatteryGroup defines the objects that are common to battery groups of two-contact UPSs." ::= { upsSubsetGroups 2 } upsSubsetInputGroup OBJECT-GROUP OBJECTS { upsInputLineBads } STATUS current DESCRIPTION "The upsSubsetInputGroup defines the objects that are common to the Input groups of two-contact UPSs." ::= { upsSubsetGroups 3 } upsSubsetOutputGroup OBJECT-GROUP OBJECTS { upsOutputSource } STATUS current DESCRIPTION "The upsSubsetOutputGroup defines the objects that are common to the Output groups of two-contact UPSs." ::= { upsSubsetGroups 4 } -- { upsSubsetGroups 5 } is reserved for future use (upsSubsetBypassGroup) upsSubsetAlarmGroup OBJECT-GROUP OBJECTS { upsAlarmsPresent, upsAlarmDescr, upsAlarmTime } STATUS current DESCRIPTION Expires June 1994 [Page 46] draft UPS MIB December 1993 "The upsSubsetAlarmGroup defines the objects that are common to the Alarm groups of basic two-contact UPSs." ::= { upsSubsetGroups 6 } -- { upsSubsetGroups 7 } is reserved for future use (upsSubsetTestGroup) upsSubsetControlGroup OBJECT-GROUP OBJECTS { upsShutdownType, upsShutdownAfterDelay, upsAutoRestart } STATUS current DESCRIPTION "The upsSubsetControlGroup defines the objects that are common to the Control groups of basic two-contact UPSs." ::= { upsSubsetGroups 8 } upsSubsetConfigGroup OBJECT-GROUP OBJECTS { upsConfigInputVoltage, upsConfigInputFreq, upsConfigOutputVoltage, upsConfigOutputFreq, upsConfigOutputVA, upsConfigOutputPower } STATUS current DESCRIPTION "The upsSubsetConfigGroup defines the objects that are common to the Config groups of basic two-contact UPSs." ::= { upsSubsetGroups 9 } upsBasicGroups OBJECT IDENTIFIER ::= { upsGroups 2 } upsBasicIdentGroup OBJECT-GROUP OBJECTS { upsIdentManufacturer, upsIdentModel, upsIdentUPSSoftwareVersion, upsIdentAgentSoftwareVersion, upsIdentName } STATUS current DESCRIPTION "The upsBasicIdentGroup defines objects which are common to the Ident group of compliant UPSs which support basic functions." ::= { upsBasicGroups 1 } upsBasicBatteryGroup OBJECT-GROUP OBJECTS { upsBatteryStatus, upsSecondsOnBattery } | STATUS current DESCRIPTION "The upsBasicBatteryGroup defines the objects that are Expires June 1994 [Page 47] draft UPS MIB December 1993 common to the battery groups of compliant UPSs which support basic functions." ::= { upsBasicGroups 2 } upsBasicInputGroup OBJECT-GROUP OBJECTS { upsInputFrequency, upsInputLineBads, upsInputNumLines, upsInputVoltage } | STATUS current DESCRIPTION "The upsBasicInputGroup defines the objects that are common to the Input groups of compliant UPSs which support basic functions." ::= { upsBasicGroups 3 } upsBasicOutputGroup OBJECT-GROUP OBJECTS { upsOutputSource, upsOutputFrequency, upsOutputNumLines, upsOutputVoltage } STATUS current DESCRIPTION "The upsBasicOutputGroup defines the objects that are common to the Output groups of compliant UPSs which support basic functions." ::= { upsBasicGroups 4 } upsBasicBypassGroup OBJECT-GROUP OBJECTS { upsBypassFrequency, upsBypassNumLines, upsBypassVoltage } STATUS current DESCRIPTION "The upsBasicBypassGroup defines the objects that are common to the Bypass groups of compliant UPSs which support basic functions." ::= { upsBasicGroups 5 } upsBasicAlarmGroup OBJECT-GROUP OBJECTS { upsAlarmsPresent, upsAlarmDescr, upsAlarmTime } STATUS current DESCRIPTION "The upsBasicAlarmGroup defines the objects that are common to the Alarm groups of compliant UPSs which support basic functions." ::= { upsBasicGroups 6 } upsBasicTestGroup OBJECT-GROUP Expires June 1994 [Page 48] draft UPS MIB December 1993 OBJECTS { upsTestId, upsTestSpinLock, upsTestResultsSummary, upsTestResultsDetail, upsTestStartTime, upsTestElapsedTime } STATUS current DESCRIPTION "The upsBasicTestGroup defines the objects that are common to the Test groups of compliant UPSs which support basic functions." ::= { upsBasicGroups 7 } upsBasicControlGroup OBJECT-GROUP OBJECTS { upsShutdownType, upsShutdownAfterDelay, upsStartupAfterDelay, upsRebootWithDuration, upsAutoRestart } STATUS current DESCRIPTION "The upsBasicControlGroup defines the objects that are common to the Control groups of compliant UPSs which support basic functions." ::= { upsBasicGroups 8 } upsBasicConfigGroup OBJECT-GROUP OBJECTS { upsConfigInputVoltage, upsConfigInputFreq, upsConfigOutputVoltage, upsConfigOutputFreq, upsConfigOutputVA, upsConfigOutputPower, upsConfigLowBattTime, upsConfigAudibleStatus } | STATUS current DESCRIPTION "The upsBasicConfigGroup defines the objects that are common to the Config groups of UPSs which support basic functions." ::= { upsBasicGroups 9 } upsFullGroups OBJECT IDENTIFIER ::= { upsGroups 3 } upsFullIdentGroup OBJECT-GROUP OBJECTS { upsIdentManufacturer, upsIdentModel, upsIdentUPSSoftwareVersion, upsIdentAgentSoftwareVersion, upsIdentName, upsIdentAttachedDevices } STATUS current DESCRIPTION "The upsFullIdentGroup defines objects which are common to the Ident group of fully compliant UPSs." ::= { upsFullGroups 1 } Expires June 1994 [Page 49] draft UPS MIB December 1993 upsFullBatteryGroup OBJECT-GROUP OBJECTS { upsBatteryStatus, upsSecondsOnBattery, upsEstimatedMinutesRemaining, upsEstimatedChargeRemaining } STATUS current DESCRIPTION "The upsFullBatteryGroup defines the objects that are common to the battery groups of fully compliant UPSs." ::= { upsFullGroups 2 } upsFullInputGroup OBJECT-GROUP OBJECTS { upsInputFrequency, upsInputLineBads, upsInputNumLines, upsInputVoltage } | STATUS current DESCRIPTION "The upsFullInputGroup defines the objects that are common to the Input groups of fully compliant UPSs." ::= { upsFullGroups 3 } upsFullOutputGroup OBJECT-GROUP OBJECTS { upsOutputSource, upsOutputFrequency, upsOutputNumLines, upsOutputVoltage, | upsOutputCurrent, upsOutputPower, upsOutputPercentLoad } STATUS current DESCRIPTION "The upsFullOutputGroup defines the objects that are common to the Output groups of fully compliant UPSs." ::= { upsFullGroups 4 } upsFullBypassGroup OBJECT-GROUP OBJECTS { upsBypassFrequency, upsBypassNumLines, upsBypassVoltage } STATUS current DESCRIPTION "The upsFullBypassGroup defines the objects that are common to the Bypass groups of fully compliant UPSs." ::= { upsFullGroups 5 } upsFullAlarmGroup OBJECT-GROUP OBJECTS { upsAlarmsPresent, upsAlarmDescr, upsAlarmTime } STATUS current DESCRIPTION "The upsFullAlarmGroup defines the objects that are common to the Alarm groups of fully compliant UPSs." Expires June 1994 [Page 50] draft UPS MIB December 1993 ::= { upsFullGroups 6 } upsFullTestGroup OBJECT-GROUP OBJECTS { upsTestId, upsTestSpinLock, upsTestResultsSummary, upsTestResultsDetail, upsTestStartTime, upsTestElapsedTime } STATUS current DESCRIPTION "The upsFullTestGroup defines the objects that are common to the Test groups of fully compliant UPSs." ::= { upsFullGroups 7 } upsFullControlGroup OBJECT-GROUP OBJECTS { upsShutdownType, upsShutdownAfterDelay, upsStartupAfterDelay, upsRebootWithDuration, upsAutoRestart } STATUS current DESCRIPTION "The upsFullControlGroup defines the objects that are common to the Control groups of fully compliant UPSs." ::= { upsFullGroups 8 } upsFullConfigGroup OBJECT-GROUP OBJECTS { upsConfigInputVoltage, upsConfigInputFreq, upsConfigOutputVoltage, upsConfigOutputFreq, upsConfigOutputVA, upsConfigOutputPower, upsConfigLowBattTime, upsConfigAudibleStatus } | STATUS current DESCRIPTION "The upsFullConfigGroup defines the objects that are common to the Config groups of UPSs." ::= { upsFullGroups 9 } END Expires June 1994 [Page 51] draft UPS MIB December 1993 6. Acknowledgements The UPS MIB represents the combined work of the IETF UPS MIB Working Group, with particular, substantial authorship contributions from: Mike Davison Fibercom, Inc. Ray Wasson Consultant Roger Draper Liebert Corporation Ken Key SNMP Research, Incorporated Pete Yoest American Power Conversion Doug Rademacher American Power Conversion Ron Pitt Network Security Systems, Inc Terry Zumwalt International Power Machines Lawren Markle Tripp Lite Bill Elliot ONEAC Tom Brennan Exide Electronics Brian Young Best Power Technology Expires June 1994 [Page 52] draft UPS MIB December 1993 7. References [1] M.T. Rose and K. McCloghrie, Structure and Identification of Management Information for TCP/IP-based internets, Internet Working Group Request for Comments 1155. Network Information Center, SRI International, Menlo Park, California, (May, 1990). [2] K. McCloghrie and M.T. Rose, Management Information Base for Network Management of TCP/IP-based internets, Internet Working Group Request for Comments 1156. Network Information Center, SRI International, Menlo Park, California, (May, 1990). [3] J.D. Case, M.S. Fedor, M.L. Schoffstall, and J.R. Davin, Simple Network Management Protocol, Internet Working Group Request for Comments 1157. Network Information Center, SRI International, Menlo Park, California, (May, 1990). [4] K. McCloghrie and M.T. Rose (editors), Management Information Base for Network Management of TCP/IP-based internets: MIB- II, Internet Working Group Request for Comments 1213. Network Information Center, SRI International, Menlo Park, California, (March, 1991). [5] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8824, (December, 1987). [6] Information processing systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Notation One (ASN.1), International Organization for Standardization. International Standard 8825, (December, 1987). [7] M.T. Rose, K. McCloghrie (editors), Concise MIB Definitions, Internet Working Group Request for Comments 1212. Network Information Center, SRI International, Menlo Park, California, (March, 1991). [8] M.T. Rose (editor), A Convention for Defining Traps for use with the SNMP, Internet Working Group Request for Comments 1215. Network Information Center, SRI International, Menlo Park, California, (March, 1991). Expires June 1994 [Page 53] draft UPS MIB December 1993 [9] J.D. Case, K. McCloghrie, M.T. Rose, and S. Waldbusser, Conformance Statements for version 2 of the Simple Network Management Protocol (SNMPv2), Request for Comments 1444, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, (April 1993). [10] J.D. Case, K. McCloghrie, M.T. Rose, and S. Waldbusser, Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2), Request for Comments 1443, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, (April 1993). Expires June 1994 [Page 54] draft UPS MIB December 1993 8. Security Considerations Security issues are not discussed in this memo. 9. Author's Address Jeffrey D. Case, Ph.D. The University of Tennessee Department of Computer Science 107 Ayres Hall Knoxville, Tennessee 37996 Phone: (615) 573-1434 Email: case@CS.UTK.EDU Expires June 1994 [Page 55] draft UPS MIB December 1993 Table of Contents 1 Introduction .............................................. 2 2 The SNMPv2 Network Management Framework ................... 3 2.1 Object Definitions ...................................... 3 3 Overview .................................................. 4 4 Status .................................................... 4 5 Definitions ............................................... 5 5.1 The Device Identification Group. ....................... 6 5.2 The Battery Group ....................................... 8 5.3 The Input Group ......................................... 10 5.4 The Output Group ........................................ 13 5.5 The Bypass Group ........................................ 16 5.6 The Alarm Group ......................................... 18 5.7 The Test Group .......................................... 24 5.8 The Control Group ....................................... 29 5.9 The Configuration Group ................................. 32 6 Acknowledgements .......................................... 52 7 References ................................................ 53 8 Security Considerations ................................... 55 9 Author's Address .......................................... 55 Expires June 1994 [Page 56] ============================================================================ > Hello. > This is M.Yamai. > > I am Engnir. of Soliton Systems K.K. Japan. > I plan to develop first UPS agent in Japan. > But I have no information about UPS MIB or UPS agent. > Please send me the USP MIB or UPS agents information. > > Regard. > > /yamai@soliton.co.jp   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14579; 25 Jan 94 20:53 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14575; 25 Jan 94 20:53 EST Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa19486; 25 Jan 94 20:53 EST Received: from localhost by CS.UTK.EDU with SMTP (8.6.4/2.8s-UTK) id UAA12430; Tue, 25 Jan 1994 20:42:49 -0500 X-Resent-To: ups-mib@CS.UTK.EDU ; Tue, 25 Jan 1994 20:42:46 EST Errors-to: owner-ups-mib@CS.UTK.EDU Received: from relay2.UU.NET by CS.UTK.EDU with SMTP (8.6.4/2.8s-UTK) id UAA12421; Tue, 25 Jan 1994 20:42:45 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: yamai@soliton.co.jp MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwali00641; Tue, 25 Jan 94 20:41:28 -0500 Received: from iij.UUCP by uucp2.uu.net with UUCP/RMAIL (queueing-rmail) id 203721.23967; Tue, 25 Jan 1994 20:37:21 EST Received: from localhost by uucp0.iij.ad.jp (8.6.5+2.3W/2.7W) id JAA13591; Wed, 26 Jan 1994 09:47:04 +0900 Received: by brahma.soliton.co.jp (4.1/IIJ-U1.1) id AA21589; Wed, 26 Jan 94 09:32:04 JST Date: Wed, 26 Jan 94 09:32:04 JST Message-Id: <9401260032.AA21589@brahma.soliton.co.jp> To: ups-mib@cs.utk.edu Subject: subscribe