Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa27992; 1 Feb 93 19:21 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa27988; 1 Feb 93 19:21 EST Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa05269; 1 Feb 93 19:24 EST Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA15045; Mon, 1 Feb 93 19:19:34 -0500 X-Resent-To: ups-mib@CS.UTK.EDU ; Mon, 1 Feb 1993 19:19:33 EST Errors-To: owner-ups-mib@CS.UTK.EDU Received: from uu.psi.com by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA15037; Mon, 1 Feb 93 19:19:28 -0500 Received: from dolphin.exide.com by uu.psi.com (5.65b/4.1.031792-PSI/PSINet) via UUCP; id AA00234 for ; Mon, 1 Feb 93 18:10:39 -0500 Received: by dolphin.exide.com (5.59/25-eef) id AA13681; Mon, 1 Feb 93 15:33:35 EST Message-Id: <9302012033.AA13681@dolphin.exide.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tom Brennan - Exide Electronics X-Mailer: SCO System V Mail (version 3.2) To: ups-mib@cs.utk.edu Subject: Battery Group Stawman v0.1 Date: Mon, 1 Feb 93 15:33:34 EST In general, I like it. We discussed at our meetings the subject of precsion, and I remember that we were told that it would be best to use whole units; I agree with this for all but frequency readings. How well will commercial Network Managers handle 10x units here, 100x units there, and 1x units everywhere else ? Also, put me down as in favor of only one pointer to the Vendor MIB, rather than one per group.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa28865; 1 Feb 93 22:28 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa28861; 1 Feb 93 22:28 EST Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa09044; 1 Feb 93 22:30 EST Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA21171; Mon, 1 Feb 93 22:16:07 -0500 X-Resent-To: ups-mib@CS.UTK.EDU ; Mon, 1 Feb 1993 22:16:06 EST Errors-To: owner-ups-mib@CS.UTK.EDU Received: from CASE.CS.UTK.EDU by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA21149; Mon, 1 Feb 93 22:15:45 -0500 Received: from LOCALHOST.cs.utk.edu by case.cs.utk.edu with SMTP (5.61++/2.7c-UTK) id AA20275; Mon, 1 Feb 93 22:15:44 -0500 Message-Id: <9302020315.AA20275@case.cs.utk.edu> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: ups-mib-request@cs.utk.edu To: ups-mib@cs.utk.edu Cc: ups-mib-request@cs.utk.edu Subject: Roll Call/Ping. Date: Mon, 01 Feb 93 22:15:43 EST X-Orig-Sender: key@cs.utk.edu Greetings, Someone at UUNET flushed a mail-queue and I received a bunch of notices today that mail was undeliverable to APC (Pete and Doug) that date back to December. I traced their PING E-mail message in December as far as checking that messages to the UPS list were getting OUT but didn't finish the three-way handshake (refer to Comer and TCP) to make sure they were receiving. I would like each of your who receives this to send me a confirmation at ups-mib-request@cs.utk.edu. I will let the replies come in for a week and then I will try to track down those companies I don't hear from via phone and see if we can trace the problem. I am still confident that the list is sending OK. I'm just worried that some of these accounts may not be receiving OK. Sorry to bother the whole list with this, but I can think of no other way to say "Raise your hand if you can't hear me". You're cooperation is appreciated, Ken Key (ups-mib-request@cs.utk.edu) (615) 573-1434 (Eastern Time)   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa29649; 2 Feb 93 0:50 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa29645; 2 Feb 93 0:50 EST Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa11563; 2 Feb 93 0:53 EST Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA25382; Tue, 2 Feb 93 00:47:35 -0500 X-Resent-To: ups-mib@CS.UTK.EDU ; Tue, 2 Feb 1993 00:47:33 EST Errors-To: owner-ups-mib@CS.UTK.EDU Received: from nic.cerf.net by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA25374; Tue, 2 Feb 93 00:47:31 -0500 Received: by nic.cerf.net (4.1/CERFnet-1.0) id AA11609; Mon, 1 Feb 93 21:49:55 PST Date: Mon, 1 Feb 1993 21:39:25 -0800 (PST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Roger W. Draper" Subject: Re: Batt Strawman To: UPS-MIB Mailing list Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Here are my comments on the Battery Group Strawman: upsBatteryStatus: Looks fine. I believe most UPS manufacturers base the low battery indicator on an estimate of battery time remaining until the unit shuts down if the input power is not restored. This is provided as a service to the user to notify them when to start final shutdown procedures. The value is user definable to allow for different backup times. upsBatteryTimeOnBattery: I'm uncertain about the value of this variable; would someone please provide some insight? upsBatteryCapacity: upsBatteryVoltage: upsBatTimeRemaining: (upsBatteryTimeRemaining) In general I believe the resolution is too fine on these variables (of course I used to think a 40meg hard drive was big). My vote: 1% for capacity, 1V for Voltage, 1 min. for time. Roger Draper Liebert Corp.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16316; 3 Feb 93 21:33 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16312; 3 Feb 93 21:33 EST Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa02384; 3 Feb 93 21:33 EST Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA04782; Wed, 3 Feb 93 21:16:47 -0500 X-Resent-To: ups-mib@CS.UTK.EDU ; Wed, 3 Feb 1993 21:16:46 EST Errors-To: owner-ups-mib@CS.UTK.EDU Received: from nic.cerf.net by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA04774; Wed, 3 Feb 93 21:16:44 -0500 Received: by nic.cerf.net (4.1/CERFnet-1.0) id AA19371; Wed, 3 Feb 93 18:19:10 PST Date: Wed, 3 Feb 1993 18:08:17 -0800 (PST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Roger W. Draper" Subject: Battery Group changes To: UPS-MIB Mailing list Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII If no one disagrees then I suggest we: 1. Delete upsBatteryTimeOnBattery 2. Minimum resolution on Battery Capacity is 1%. 3. Minimum resolution on Battery Voltage is 1V. 4. Minimum resolution on BattTime Remaining is 1 minute. 5. Only one enterprise specific ID. Next Group... (Say, this is easy!) Roger Draper Liebert Corp.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08776; 4 Feb 93 13:56 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08772; 4 Feb 93 13:56 EST Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa16479; 4 Feb 93 13:56 EST Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA18784; Thu, 4 Feb 93 13:33:55 -0500 X-Resent-To: ups-mib@CS.UTK.EDU ; Thu, 4 Feb 1993 13:33:54 EST Errors-To: owner-ups-mib@CS.UTK.EDU Received: from CASE.CS.UTK.EDU by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA18773; Thu, 4 Feb 93 13:33:52 -0500 Received: from LOCALHOST.cs.utk.edu by case.cs.utk.edu with SMTP (5.61++/2.7c-UTK) id AA28933; Thu, 4 Feb 93 13:33:51 -0500 Message-Id: <9302041833.AA28933@case.cs.utk.edu> To: "Roger W. Draper" Cc: UPS-MIB Mailing list , key@cs.utk.edu Subject: Re: Battery Group changes In-Reply-To: Your message of "Wed, 03 Feb 93 18:08:17 PST." Date: Thu, 04 Feb 93 13:33:50 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: key@cs.utk.edu Roger Draper Says: > If no one disagrees then I suggest we: [recommendations in previous message deleted] >Next Group... > (Say, this is easy!) I'd really like to, but we'e only heard 2 responses to the strawman while I've picked up, at last count, 15 pings. I can't get a concensus from this small of a response and can't hear murmers of disapproval or approval. Right now, the Tom and Roger's replies align and make sense to me. Roger brought up the issue of: > upsBatteryTimeOnBattery: > > I'm uncertain about the value of this variable; > would someone please provide some insight? So how about it, folks? Let's hear some action! Ken Key (key@cs.utk.edu)   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06053; 5 Feb 93 11:29 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06049; 5 Feb 93 11:29 EST Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa12387; 5 Feb 93 11:29 EST Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA08627; Fri, 5 Feb 93 11:11:59 -0500 X-Resent-To: ups-mib@CS.UTK.EDU ; Fri, 5 Feb 1993 11:11:57 EST Errors-To: owner-ups-mib@CS.UTK.EDU Received: from nic.cerf.net by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA08602; Fri, 5 Feb 93 11:11:43 -0500 Received: by nic.cerf.net (4.1/CERFnet-1.0) id AA28383; Fri, 5 Feb 93 08:14:10 PST Date: Fri, 5 Feb 1993 08:12:21 -0800 (PST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Les Matheson Subject: Re: Battery Group changes To: key@cs.utk.edu Cc: "Roger W. Draper" , UPS-MIB Mailing list , key@cs.utk.edu In-Reply-To: <9302041833.AA28933@case.cs.utk.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > > upsBatteryTimeOnBattery: > > > > I'm uncertain about the value of this variable; > > would someone please provide some insight? > Sounds like "amount of time since UPS began running on battery" ; or maybe "how long you can expect to run on battery " ( taken from the brochure, I bet )   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15936; 5 Feb 93 19:46 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15932; 5 Feb 93 19:46 EST Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa28486; 5 Feb 93 19:46 EST Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA07492; Fri, 5 Feb 93 19:22:46 -0500 X-Resent-To: ups-mib@CS.UTK.EDU ; Fri, 5 Feb 1993 19:22:45 EST Errors-To: owner-ups-mib@CS.UTK.EDU Received: from nic.cerf.net by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA07484; Fri, 5 Feb 93 19:22:44 -0500 Received: by nic.cerf.net (4.1/CERFnet-1.0) id AA01330; Fri, 5 Feb 93 16:25:10 PST Date: Fri, 5 Feb 1993 16:15:32 -0800 (PST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Roger W. Draper" Subject: Re: Battery Group changes To: Les Matheson Cc: UPS-MIB Mailing list In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 5 Feb 1993, Les Matheson wrote: > > > upsBatteryTimeOnBattery: > > > > > > I'm uncertain about the value of this variable; > > > would someone please provide some insight? > > > Sounds like "amount of time since UPS began running on battery" ; or maybe > "how long you can expect to run on battery " ( taken from the brochure, I > bet ) > > Les, I assume this is the time spent on battery since the input failed. My question is of what value this serves the user since he already knows he's on battery and he also knows how much time he has left (upsBattTime Remaining). I don't think it's of any value. Any other opinions out there? Roger Draper Liebert Corp.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00677; 6 Feb 93 15:34 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id bl00451; 6 Feb 93 15:34 EST Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa10756; 6 Feb 93 13:27 EST Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA18948; Sat, 6 Feb 93 13:06:53 -0500 X-Resent-To: ups-mib@CS.UTK.EDU ; Sat, 6 Feb 1993 13:06:52 EST Errors-To: owner-ups-mib@CS.UTK.EDU Received: from UTKVX1.UTK.EDU by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA18940; Sat, 6 Feb 93 13:06:51 -0500 Received: from utkvx.utk.edu by utkvx.utk.edu (PMDF #3151 ) id <01GUEHSWAV0699DYFF@utkvx.utk.edu>; Sat, 6 Feb 1993 13:06:53 EST Date: 06 Feb 1993 13:06:53 -0500 (EST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: CASE@utkvx.utcc.utk.edu Subject: Re: Battery Group changes To: rdraper@nic.cerf.net Cc: ups-mib@cs.utk.edu Message-Id: <01GUEHSWAV0899DYFF@utkvx.utk.edu> X-Vms-To: IN%"rdraper@nic.cerf.net" X-Vms-Cc: IN%"ups-mib@cs.utk.edu",CASE Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT >I assume this is the time spent on battery since the input failed. My i'm sure we agree that this needs to be clarified if it is kept >question is of what value this serves the user since he already knows >he's on battery and he also knows how much time he has left (upsBattTime >Remaining). I don't think it's of any value. i can tell you if this is of value if you can answer the following: a) to what extent do users of this mib want/need to know what time the power failed (and thereby put us on battery)? b) to what extent is this information unavailable elsewhere? if the answer to a) is "a lot" and the answer to b) is "not at all" then the answer is this variable is useful otherwise, it may be marginal still seeking input from others regards, jdc   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00717; 6 Feb 93 15:34 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id bs00451; 6 Feb 93 15:34 EST Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa11656; 6 Feb 93 14:22 EST Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA21479; Sat, 6 Feb 93 14:06:34 -0500 X-Resent-To: ups-mib@CS.UTK.EDU ; Sat, 6 Feb 1993 14:06:32 EST Errors-To: owner-ups-mib@CS.UTK.EDU Received: from CASE.CS.UTK.EDU by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA21466; Sat, 6 Feb 93 14:06:30 -0500 Received: from LOCALHOST.cs.utk.edu by case.cs.utk.edu with SMTP (5.61++/2.7c-UTK) id AA05399; Sat, 6 Feb 93 14:06:30 -0500 Message-Id: <9302061906.AA05399@case.cs.utk.edu> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: ups-mib-request@cs.utk.edu To: ups-mib@cs.utk.edu Cc: key@cs.utk.edu Subject: Multiple messages from Jeff Date: Sat, 06 Feb 93 14:06:29 EST X-Orig-Sender: key@cs.utk.edu The multiple messages were caused by the postmaster @cs.utk.edu restarting sendmail several times in the course of some work he was doing while it happened to be processing Jeff's message. The problem has been dealt with and thank you for your patience. Ken Key (ups-mib-request@cs.utk.edu)   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13496; 8 Feb 93 12:18 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13492; 8 Feb 93 12:18 EST Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa13256; 8 Feb 93 12:18 EST Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA29672; Mon, 8 Feb 93 11:58:52 -0500 X-Resent-To: ups-mib@CS.UTK.EDU ; Mon, 8 Feb 1993 11:58:51 EST Errors-To: owner-ups-mib@CS.UTK.EDU Received: from nic.cerf.net by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA29664; Mon, 8 Feb 93 11:58:49 -0500 Received: by nic.cerf.net (4.1/CERFnet-1.0) id AA05826; Mon, 8 Feb 93 09:01:17 PST Date: Mon, 8 Feb 1993 08:59:49 -0800 (PST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Les Matheson Subject: Re: Battery Group changes To: "Roger W. Draper" Cc: UPS-MIB Mailing list In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > > > > > upsBatteryTimeOnBattery: > > > > > > > > I'm uncertain about the value of this variable; > > > > would someone please provide some insight? > > > > > Sounds like "amount of time since UPS began running on battery" ; or maybe > > "how long you can expect to run on battery " ( taken from the brochure, I > > bet ) > > > > > > Les, > > I assume this is the time spent on battery since the input failed. My > question is of what value this serves the user since he already knows > he's on battery and he also knows how much time he has left (upsBattTime > Remaining). I don't think it's of any value. > > > Any other opinions out there? > > Roger Draper > Liebert Corp. > > It may be of value to people who wish to see ( from experience ) how much time they can expect their batteries to hold up in an outage.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20351; 8 Feb 93 19:09 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20347; 8 Feb 93 19:09 EST Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa26660; 8 Feb 93 19:10 EST Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA21570; Mon, 8 Feb 93 18:48:36 -0500 X-Resent-To: ups-mib@CS.UTK.EDU ; Mon, 8 Feb 1993 18:48:35 EST Errors-To: owner-ups-mib@CS.UTK.EDU Received: from ihc.compuserve.com by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA21561; Mon, 8 Feb 93 18:48:31 -0500 Received: by ihc.compuserve.com (5.65/5.930129sam) id AA18164; Mon, 8 Feb 93 18:48:28 -0500 Date: 08 Feb 93 18:43:08 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dane Groszek <71213.2320@compuserve.com> To: "Roger W. Draper" , UPS-MIB Mailing List Subject: Battery Group Changes Message-Id: <930208234308_71213.2320_DHQ31-1@CompuServe.COM> Answer to SNMP Group Comment on UPS Battery Time, Rodger, >If no one disagrees then I suggest we: >1. Delete upsBatteryTimeOnBattery >2. Minimum resolution on Battery Capacity is 1%. >3. Minimum resolution on Battery Voltage is 1V. >4. Minimum resolution on BattTime Remaining is 1 minute. >5. Only one enterprise specific ID. 1. We do not agree with deleting Time On Battery. This value and others helps the user to predict battery cycle life which could be important in avoiding a system crash. Another variable that would help to evaluate cycle life would be the number of battery discharge cycles. For some UPS systems, this can be derived from input group variables such as the sum of UPS Input Brownouts, UPS Input Blackouts, and UPS Input Transients. Batteries are not necessarily discharged when a brown-out or transient occurs. Kevin Collins KW Control Systems Inc.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20413; 8 Feb 93 19:21 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20409; 8 Feb 93 19:21 EST Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa26949; 8 Feb 93 19:21 EST Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA22174; Mon, 8 Feb 93 19:03:27 -0500 X-Resent-To: ups-mib@CS.UTK.EDU ; Mon, 8 Feb 1993 19:03:26 EST Errors-To: owner-ups-mib@CS.UTK.EDU Received: from UTKVX3.UTK.EDU by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA22166; Mon, 8 Feb 93 19:03:26 -0500 Received: from utkvx.utk.edu by utkvx.utk.edu (PMDF #3151 ) id <01GUHMYKPP6U8WW2SH@utkvx.utk.edu>; Mon, 8 Feb 1993 19:02:51 EST Date: 08 Feb 1993 19:02:51 -0500 (EST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: CASE@utkvx.utcc.utk.edu Subject: Re: Battery Group Changes To: 71213.2320@compuserve.com Cc: ups-mib@cs.utk.edu Message-Id: <01GUHMYKPYU08WW2SH@utkvx.utk.edu> X-Vms-To: IN%"71213.2320@CompuServe.COM" X-Vms-Cc: IN%"ups-mib@cs.utk.edu",CASE Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Kevin Collins writes: >1. We do not agree with deleting Time On Battery. do you agree with the other 4 that you don't mention explicitly? regards, jdc   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04711; 9 Feb 93 12:15 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04707; 9 Feb 93 12:15 EST Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa11572; 9 Feb 93 12:16 EST Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA04578; Tue, 9 Feb 93 11:59:35 -0500 X-Resent-To: ups-mib@CS.UTK.EDU ; Tue, 9 Feb 1993 11:59:34 EST Errors-To: owner-ups-mib@CS.UTK.EDU Received: from relay1.UU.NET by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA04570; Tue, 9 Feb 93 11:59:33 -0500 Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA04641; Tue, 9 Feb 93 11:59:29 -0500 Received: from apc.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 115810.28974; Tue, 9 Feb 1993 11:58:10 EST Received: by apc (AIX 3.2/UCB 5.64/4.03) id AA19336; Tue, 9 Feb 1993 10:59:39 -0500 Date: Tue, 9 Feb 1993 10:59:39 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: apc!dougr@uunet.uu.net Message-Id: <9302091559.AA19336@apc> To: uunet!cs.utk.edu!ups-mib@uunet.uu.net Subject: APC awakens from hibernation Sorry we've been so silent. The mail problem had something to do about it. Glad to see the meeting notes published. Some of the APC stuff looks out of whack, so I'll send updated info to ups-mib-request. I suggest that everyone double-check their data. I think BatteryTimeOnBattery can be very useful. Other systems monitoring the UPS may want to trigger events based on the amount of time the UPS has been on battery. It can also be used to check whether the UPS is providing the backup time that it promised to (in product spec or in BatTimeRemaining). I also agree that the battery group values are acceptable as integers. BatteryLastReplacementDate was removed and the argument supporting its removal was that it would be ineffectual as a manual or user dependent process. Who's to say that this may not be automated in the future? It is a very valuable piece of information, and I say that it should stay in anticipation of UPS systems to come. BatteryTemperature was also left out. Batteries are severely affected by high temperatures. Will this information appear elsewhere? As an environ- ment variable? I say that it should be available. BatteryReplacement indicator is also very important. The battery in a UPS is the one thing that is guaranteed to go bad. Even if some systems can't support this, they really can support the variable. There could be some type of 'unknown' state. Lastly, if we are going to support BatteryVoltage, we need to also support BatteryFullChargeVoltage or NominalVoltage. If BatteryVoltage reads '24', how do you know if that is good or bad? If the UPS batteries are 48 volt, then it is bad. If they are 24 volt, then it is good. I don't mean to be stubborn, and I appreciate Ken's efforts to make the MIB efficient, but we UPS experts need to speak up and decide what should and shouldn't be in the MIB. Opinions?   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07045; 9 Feb 93 14:43 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07041; 9 Feb 93 14:43 EST Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa16192; 9 Feb 93 14:43 EST Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA11189; Tue, 9 Feb 93 14:08:31 -0500 X-Resent-To: ups-mib@CS.UTK.EDU ; Tue, 9 Feb 1993 14:08:28 EST Errors-To: owner-ups-mib@CS.UTK.EDU Received: from CASE.CS.UTK.EDU by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA11156; Tue, 9 Feb 93 14:08:20 -0500 Received: from LOCALHOST.cs.utk.edu by case.cs.utk.edu with SMTP (5.61++/2.7c-UTK) id AA01897; Tue, 9 Feb 93 14:08:19 -0500 Message-Id: <9302091908.AA01897@case.cs.utk.edu> To: ups-mib@cs.utk.edu Cc: key@cs.utk.edu Subject: Re: Battery Strawman. Date: Tue, 09 Feb 93 14:08:18 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: key@cs.utk.edu Greetings, I will be out of town until Friday but I want to try to fan the flames of the strawman discussion, so to speak. I've pretty much picked up a concensus to use whole numbers. Also, one pointer to ups-specific OID space. Issue for the group: should time generally be minutes or seconds? I'd like to keep the time-unit consistent. My 0.02 on upsBatteryTimeOnBattery: The way I would implement it, as currently written, is the number of minutes (or seconds) since input failed. But I wonder if this is as reliable as what folks are hoping for. Will this information be of value to you or will it actually mislead you in an intermitent power failure condition? It seems like the utility around here takes three hits before things ever stablize. Lastly, Doug has brought up some very good issues that I need to see hashed out before I can make the next strawman. Some of the things he mentioned were just outisde the borderline of my analysis of the Dallas survey for automatic inclusion. That survey is no be-all, end-all for whether a variable should be included. Personally, I was surprised that upsBatteryTemperature did not even come close. Let's hear discussion on this variables that were excluded. Please do not be shy. Thanks to Brian, Rodger, Les, Kevin, and Doug for the input so far, but we need more. Ken Key (key@cs.utk.edu)   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11589; 9 Feb 93 19:29 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11585; 9 Feb 93 19:29 EST Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa27326; 9 Feb 93 19:30 EST Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA28125; Tue, 9 Feb 93 19:13:51 -0500 X-Resent-To: ups-mib@CS.UTK.EDU ; Tue, 9 Feb 1993 19:13:49 EST Errors-To: owner-ups-mib@CS.UTK.EDU Received: from UTKVX2.UTK.EDU by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA28116; Tue, 9 Feb 93 19:13:49 -0500 Received: from utkvx.utk.edu by utkvx.utk.edu (PMDF #3151 ) id <01GUJ1DXM0268WWKAO@utkvx.utk.edu>; Tue, 9 Feb 1993 19:13:28 EST Date: 09 Feb 1993 19:13:28 -0500 (EST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: CASE@utkvx.utcc.utk.edu Subject: Re: APC awakens from hibernation To: apc!dougr@uunet.uu.net Cc: ups-mib@cs.utk.edu Message-Id: <01GUJ1DXM01S8WWKAO@utkvx.utk.edu> X-Vms-To: IN%"apc!dougr@uunet.UU.NET" X-Vms-Cc: IN%"ups-mib@cs.utk.edu",CASE Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT >I don't mean to be stubborn, and I appreciate Ken's efforts to make the MIB >efficient, but we UPS experts need to speak up and decide what should and >shouldn't be in the MIB. ken is off until friday, so i'll comment on a couple of things 1. you don't appreciate ken's efforts half as much as i do :-) 2. this kind of dialog is perceived (by me) to be mean nor stubborn ... this is how it is supposed to work 3. i am a bit surprised at the role reversal, but pleasantly 4. i hope (and believe) we can continue building the momentum we are building progressively, jdc   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11943; 9 Feb 93 20:47 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11939; 9 Feb 93 20:47 EST Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa29098; 9 Feb 93 20:48 EST Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA00497; Tue, 9 Feb 93 20:27:04 -0500 X-Resent-To: ups-mib@CS.UTK.EDU ; Tue, 9 Feb 1993 20:27:03 EST Errors-To: owner-ups-mib@CS.UTK.EDU Received: from UTKVX2.UTK.EDU by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA00485; Tue, 9 Feb 93 20:27:01 -0500 Received: from utkvx.utk.edu by utkvx.utk.edu (PMDF #3151 ) id <01GUJ3KRCTXC8WWF57@utkvx.utk.edu>; Tue, 9 Feb 1993 20:26:40 EST Date: 09 Feb 1993 20:26:40 -0500 (EST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: CASE@utkvx.utcc.utk.edu Subject: Re: APC awakens from hibernation To: key@cs.utk.edu Cc: ups-mib@cs.utk.edu Message-Id: <01GUJ3KRCTXE8WWF57@utkvx.utk.edu> X-Vms-To: IN%"key@cs.utk.edu" X-Vms-Cc: IN%"ups-mib@cs.utk.edu",CASE Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT >> 2. this kind of dialog is perceived (by me) to be mean nor stubborn ... this >> is how it is supposed to work >I think you meant "to be neither..." don't you just love it when I "help"? sigh try again 2. this kind of dialog is perceived (by me) to be NEITHER mean nor stubborn this is how it is supposed to work maybe i should just get out of the way and let the dog see the rabbit regards, jdc   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05312; 10 Feb 93 10:27 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05308; 10 Feb 93 10:27 EST Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa11076; 10 Feb 93 10:27 EST Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA05912; Wed, 10 Feb 93 10:10:17 -0500 X-Resent-To: ups-mib@CS.UTK.EDU ; Wed, 10 Feb 1993 10:10:15 EST Errors-To: owner-ups-mib@CS.UTK.EDU Received: from nic.cerf.net by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA05892; Wed, 10 Feb 93 10:10:13 -0500 Received: by nic.cerf.net (4.1/CERFnet-1.0) id AA02483; Wed, 10 Feb 93 07:12:43 PST Date: Wed, 10 Feb 1993 06:59:50 -0800 (PST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Roger W. Draper" Subject: upsBatterTimeOnBattery To: UPS-MIB Mailing list Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Thanks for all the response to my question! I'd say time on battery is a keeper. How about the resolution issues? Roger Liebert.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07882; 10 Feb 93 12:22 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07878; 10 Feb 93 12:22 EST Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa15676; 10 Feb 93 12:22 EST Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA11027; Wed, 10 Feb 93 12:04:30 -0500 X-Resent-To: ups-mib@CS.UTK.EDU ; Wed, 10 Feb 1993 12:04:29 EST Errors-To: owner-ups-mib@CS.UTK.EDU Received: from nic.cerf.net by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA11019; Wed, 10 Feb 93 12:04:27 -0500 Received: by nic.cerf.net (4.1/CERFnet-1.0) id AA07771; Wed, 10 Feb 93 09:06:58 PST Date: Wed, 10 Feb 1993 08:54:36 -0800 (PST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Les Matheson Subject: The Incredible Shrinking MIB To: upsmib Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII A little philosophical note here . . . Given the number of things that have come under fire as not being needed in the MIB, I am reminded of the days when 640K was all the memory anyone could imagine using. I suggest that the discussion really boils down to something like this: a: "Let's take X out of the MIB, it's a pain in the rear to implement and probably no one will ever use it anyway, besides which, our model XJS1000 cant support it and so we'll look bad in the marketplace" b: "Someday we're going to regret not having that MIB variable, there are things that it makes possible, and we should take the marketing hit now in the interest of having more room to grow" c: "Take it out, we'll stick it in our private MIB and sell it as a feature the competition doesn't have" I don't suggest that any of these "philosophies" is "right", but I am noticing in the ongoing conversation that these questions keep cropping up all the time. I do suggest that we may each want to ask ourselves where we stand in the matter. Am I out to make sure my products support the MIB soon so as to protect myself, or am I out to provide the best possible service and products to the customer? I think that being willing to take the marketing hit on current products is worth it if in the long run I am providing the customer with value. Obviously each MIB object still has to be assessed on it's own merits, but the question is what is the background philosophy agains which it's merits will be assessed?   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08989; 10 Feb 93 13:33 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08985; 10 Feb 93 13:33 EST Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa17590; 10 Feb 93 13:34 EST Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA14181; Wed, 10 Feb 93 13:14:51 -0500 X-Resent-To: ups-mib@CS.UTK.EDU ; Wed, 10 Feb 1993 13:14:49 EST Errors-To: owner-ups-mib@CS.UTK.EDU Received: from babyoil.ftp.com by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA14172; Wed, 10 Feb 93 13:14:46 -0500 Received: by ftp.com id AA11455; Wed, 10 Feb 93 13:14:48 -0500 Date: Wed, 10 Feb 93 13:14:48 -0500 Message-Id: <9302101814.AA11455@ftp.com> To: matheson@nic.cerf.net Subject: Re: The Incredible Shrinking MIB Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Frank Kastenholz Reply-To: kasten@ftp.com Cc: upsmib > From: Les Matheson [A discourse into the philosphy behind accepting and rejecting objects for inclusion into the MIB -- not reposted to save space] The following is a condensed version of the criteria, originally used for MIB-I, which drove these same decisions for other MIBs: (1) An object needed to be essential for either fault or configuration management. (3) Evidence of current use and utility was required. (5) To avoid redundant variables, it was required that no object be included that can be derived from others in the MIB. (6) Implementation specific objects (e.g., for BSD UNIX) were excluded. (I deleted the criteria about, e.g. , weak control objects only, since security is coming real soon now, and having only one counter per critical code path per layer since that does not seem to apply in this case). Another criteria, which actually derives from number 1 in the list, is that NM is for debugging networks, not implementations, and objects for which the prime use is debugging implementations should not be in the MIB. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10769; 10 Feb 93 14:38 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10764; 10 Feb 93 14:38 EST Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa19932; 10 Feb 93 14:39 EST Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA17191; Wed, 10 Feb 93 14:19:21 -0500 X-Resent-To: ups-mib@CS.UTK.EDU ; Wed, 10 Feb 1993 14:19:19 EST Errors-To: owner-ups-mib@CS.UTK.EDU Received: from uu.psi.com by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA17182; Wed, 10 Feb 93 14:19:09 -0500 Received: from dolphin.exide.com by uu.psi.com (5.65b/4.1.031792-PSI/PSINet) via UUCP; id AA24944 for ; Wed, 10 Feb 93 14:01:52 -0500 Received: by dolphin.exide.com (5.59/25-eef) id AA17480; Wed, 10 Feb 93 10:48:35 EST Message-Id: <9302101548.AA17480@dolphin.exide.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tom Brennan - Exide Electronics X-Mailer: SCO System V Mail (version 3.2) To: ups-mib@cs.utk.edu Subject: TimeOnBattery Date: Wed, 10 Feb 93 10:48:35 EST This isn't too important oto Exide, but could be to little UPS which only have relay contacts to indicate OnBattery, but no way to indicate BatteryTimeRemaining. Then this element tells more than is otherwise available. I offer this as explanation, not as a vote for e the feature. Jeff has before raised the point that if a UPS only has 2 relay contacts for output, how useful will it be to have it respond to MIB requests?   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07231; 12 Feb 93 13:46 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07227; 12 Feb 93 13:46 EST Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa12007; 12 Feb 93 13:46 EST Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA21707; Fri, 12 Feb 93 13:21:22 -0500 X-Resent-To: ups-mib@CS.UTK.EDU ; Fri, 12 Feb 1993 13:21:21 EST Errors-To: owner-ups-mib@CS.UTK.EDU Received: from nic.cerf.net by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA21699; Fri, 12 Feb 93 13:21:19 -0500 Received: by nic.cerf.net (4.1/CERFnet-1.0) id AA23420; Fri, 12 Feb 93 10:18:04 PST Date: Fri, 12 Feb 1993 09:49:29 -0800 (PST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Roger W. Draper" Subject: Re: APC awakens from hibernation To: apc!dougr@uunet.uu.net Cc: UPS-MIB Mailing list In-Reply-To: <9302091559.AA19336@apc> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 9 Feb 1993 apc!dougr@uunet.UU.NET wrote: > > > Sorry we've been so silent. The mail problem had something to do > about it. Good to have you back! > > BatteryLastReplacementDate was removed and the argument supporting its > removal was that it would be ineffectual as a manual or user dependent > process. Who's to say that this may not be automated in the future? It > is a very valuable piece of information, and I say that it should stay in > anticipation of UPS systems to come. > On UPS systems with large strings of batteries this would be a table with entries for each battery since battery strings are not always changed out as a single set. Do we really want to do this? This may be better served in maintenance records. > BatteryTemperature was also left out. Batteries are severely affected by > high temperatures. Will this information appear elsewhere? As an environ- > ment variable? I say that it should be available. > I agree that this very valuable variable and should be available. > BatteryReplacement indicator is also very important. The battery in a UPS > is the one thing that is guaranteed to go bad. Even if some systems can't > support this, they really can support the variable. There could be some > type of 'unknown' state. > I agree... But I would like to get feedback from others on this one. > Lastly, if we are going to support BatteryVoltage, we need to also support > BatteryFullChargeVoltage or NominalVoltage. If BatteryVoltage reads '24', > how do you know if that is good or bad? If the UPS batteries are 48 volt, > then it is bad. If they are 24 volt, then it is good. > NominalBatteryVoltage should be in the config group. > I don't mean to be stubborn, and I appreciate Ken's efforts to make the MIB > efficient, but we UPS experts need to speak up and decide what should and > shouldn't be in the MIB. > Yes, let's hear more from the UPS experts... I know your out there. Roger Liebert.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11043; 17 Feb 93 14:20 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11039; 17 Feb 93 14:20 EST Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa22595; 17 Feb 93 14:20 EST Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA16621; Wed, 17 Feb 93 14:01:35 -0500 X-Resent-To: ups-mib@CS.UTK.EDU ; Wed, 17 Feb 1993 14:01:34 EST Errors-To: owner-ups-mib@CS.UTK.EDU Received: from relay1.UU.NET by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA16611; Wed, 17 Feb 93 14:01:24 -0500 Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA07029; Wed, 17 Feb 93 14:01:20 -0500 Received: from apc.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 135934.22006; Wed, 17 Feb 1993 13:59:34 EST Received: by apc (AIX 3.2/UCB 5.64/4.03) id AA17045; Tue, 16 Feb 1993 14:46:15 -0500 Date: Tue, 16 Feb 1993 14:46:15 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: apc!yoest@uunet.uu.net Message-Id: <9302161946.AA17045@apc> To: uunet!cs.utk.edu!ups-mib@uunet.uu.net Cc: ups-mib@cs.utk.edu, key@cs.utk.edu In-Reply-To: uunet!cs.utk.edu!key's message of Tue, 09 Feb 93 14:08:18 EST <9302091908.AA01897@case.cs.utk.edu> Subject: Battery Strawman. All time should be in seconds. If we have seconds we can get minutes. If we have minutes we only have the accuracy of 60 seconds. All in favor... Pete Yoest   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22081; 17 Feb 93 18:08 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa22077; 17 Feb 93 18:08 EST Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa07767; 17 Feb 93 18:08 EST Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA26863; Wed, 17 Feb 93 17:45:01 -0500 X-Resent-To: ups-mib@CS.UTK.EDU ; Wed, 17 Feb 1993 17:45:00 EST Errors-To: owner-ups-mib@CS.UTK.EDU Received: from nic.cerf.net by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA26854; Wed, 17 Feb 93 17:44:58 -0500 Received: by nic.cerf.net (4.1/CERFnet-1.0) id AA00821; Wed, 17 Feb 93 14:47:34 PST Date: Wed, 17 Feb 1993 14:46:58 -0800 (PST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Les Matheson Subject: times in seconds To: upsmib Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I agree times should be in seconds.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22928; 17 Feb 93 20:17 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa22924; 17 Feb 93 20:17 EST Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa13842; 17 Feb 93 20:17 EST Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA02174; Wed, 17 Feb 93 20:01:06 -0500 X-Resent-To: ups-mib@CS.UTK.EDU ; Wed, 17 Feb 1993 20:01:05 EST Errors-To: owner-ups-mib@CS.UTK.EDU Received: from nic.cerf.net by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA02166; Wed, 17 Feb 93 20:01:04 -0500 Received: by nic.cerf.net (4.1/CERFnet-1.0) id AA12228; Wed, 17 Feb 93 17:03:41 PST Date: Wed, 17 Feb 1993 16:38:44 -0800 (PST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Roger W. Draper" Subject: Time in minutes To: UPS-MIB Mailing list Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I vote for time in minutes. Are there any manufactures currently reporting battery time in seconds? When loads are reduced do your seconds count backward? Is anybody aware of changes in battery technology that will make batteries any more predictable (by an order of magnitude)? Finally, 38 minutes is just more user friendly than 2280 seconds (or was that 2380? Anybody have a calculator, one with a light on it?). Roger. Liebert.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06244; 18 Feb 93 9:13 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06240; 18 Feb 93 9:13 EST Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa15150; 18 Feb 93 9:13 EST Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA05662; Thu, 18 Feb 93 08:54:18 -0500 X-Resent-To: ups-mib@CS.UTK.EDU ; Thu, 18 Feb 1993 08:54:16 EST Errors-To: owner-ups-mib@CS.UTK.EDU Received: from [128.127.2.105] by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA05653; Thu, 18 Feb 93 08:54:14 -0500 Received: by ftp.com id AA17113; Thu, 18 Feb 93 08:53:15 -0500 Date: Thu, 18 Feb 93 08:53:15 -0500 Message-Id: <9302181353.AA17113@ftp.com> To: rdraper@nic.cerf.net Subject: MIB Variable units selection Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Frank Kastenholz Reply-To: kasten@ftp.com Cc: UPS-MIB Mailing list What is "user friendly" in terms of MIB object definition is usually not a big consideration. In this case, if the object is in units of seconds, a manager station could do the math, divide by 60, and tell the user the time in minutes. What is important when picking units is: 1. Whether the granularity of the mib object properly reflects the underlying phenomenon being measured. For example, if the MIB Object's units was fortnights, then the smallest interval that can be measured, 14 days, is obviously too big for this application. 2. Whether the range of values of the MIB object adequately reflect the phenomenon being measured. For example, if this object was in units of nanoseconds then a 32 bit number would allow for a ~4 second maximum; too short. 3. Can you honestly measure things to the single unit? Could battery time really be measured to, e.g. nanoseconds, or even seconds? Alternatively, this can be viewed as determining what kind of statement of accuracy you are willing to make. One could view the units as also implying an accuracy of +/- .5 Unit; to say that the time is 68 seconds, you might be interpreted as saying that the time is 68 +/- .5 seconds. 4. The near future is also somewhat important. Is the variable's units correct to accomodate the changes that can be expected for the next 2 or 3 years in the underlying technology? If it is likely that battery technology will make it possible, in the next 2 or 3 years to honestly measure the times down to accuracies of nanoseconds, then you probably want to make the units nanoseconds. We can always change/add-to the MIB to deal with advances in the "far" (>2-3 years) future or for the "unlikely/unforseen" change that takes the world by storm and comes from someplace that no one thought of. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11805; 18 Feb 93 13:42 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11801; 18 Feb 93 13:42 EST Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa29827; 18 Feb 93 13:42 EST Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA18005; Thu, 18 Feb 93 13:20:28 -0500 X-Resent-To: ups-mib@CS.UTK.EDU ; Thu, 18 Feb 1993 13:20:27 EST Errors-To: owner-ups-mib@CS.UTK.EDU Received: from nic.cerf.net by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA17994; Thu, 18 Feb 93 13:20:25 -0500 Received: by nic.cerf.net (4.1/CERFnet-1.0) id AA14893; Thu, 18 Feb 93 10:23:02 PST Date: Thu, 18 Feb 1993 10:16:53 -0800 (PST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Les Matheson Subject: battery time in minutes vs. seconds To: upsmib Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Ok, so the seconds vs. minutes argument isn't cut and dried: 1. Probably batteries are never going to be predictable to the point that second-resolution will be calculatable. 2. The amount of time the UPS has been on batteries and the total accumulated battery discharge and the duration of any particular discharge can be measured in seconds, so it just seems like having the time remaining be in the same units is cleaner. 3. In some UPS's, time remaining could be implemented as a countdown ( i.e. what if battery voltage is not being used as a cutoff criteria, instead some fixed time limit is allowed to expire ). In such a case, knowing whether you have 1 minute and 49 seconds might make a big difference over just 1 minute -- limited by resolution. Anyway, if we have a 3 day discussion about every object, this MIB will be complete somewhere around the next century :-) ( so why am I fueling the fire?)   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11830; 18 Feb 93 13:44 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11826; 18 Feb 93 13:44 EST Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa29864; 18 Feb 93 13:44 EST Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA18125; Thu, 18 Feb 93 13:23:49 -0500 X-Resent-To: ups-mib@CS.UTK.EDU ; Thu, 18 Feb 1993 13:23:47 EST Errors-To: owner-ups-mib@CS.UTK.EDU Received: from iha.compuserve.com by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA18117; Thu, 18 Feb 93 13:23:44 -0500 Received: by iha.compuserve.com (5.65/5.930129sam) id AA03119; Thu, 18 Feb 93 13:23:40 -0500 Date: 18 Feb 93 13:09:36 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Chris Strug <71673.1050@compuserve.com> To: ups-mib@cs.utk.edu MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US Subject: UPS MIB mailing list and discussion Message-Id: <930218180936_71673.1050_DHS21-2@CompuServe.COM> Please include MERLIN GERIN on the mailing list and discussion of the UPS MIB. The contact is Mr. CHRIS STRUG.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13450; 18 Feb 93 14:33 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13445; 18 Feb 93 14:33 EST Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa02257; 18 Feb 93 14:33 EST Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA19729; Thu, 18 Feb 93 14:02:28 -0500 X-Resent-To: ups-mib@CS.UTK.EDU ; Thu, 18 Feb 1993 14:02:27 EST Errors-To: owner-ups-mib@CS.UTK.EDU Received: from relay2.UU.NET by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA19721; Thu, 18 Feb 93 14:02:26 -0500 Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA05914; Thu, 18 Feb 93 14:02:27 -0500 Received: from apc.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 140134.15903; Thu, 18 Feb 1993 14:01:34 EST Received: by apc (AIX 3.2/UCB 5.64/4.03) id AA18838; Thu, 18 Feb 1993 12:42:39 -0500 Date: Thu, 18 Feb 1993 12:42:39 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: apc!yoest@uunet.uu.net Message-Id: <9302181742.AA18838@apc> To: uunet!cs.utk.edu!ups-mib@uunet.uu.net In-Reply-To: "Roger W. Draper"'s message of Wed, 17 Feb 1993 16:38:44 -0800 (PST) Subject: Time in minutes Although currently minutes is the best most if not all of us can do I would hate to get to the point where we could do seconds and we were stuck with a battery time counter in minutes. There probably be other time variables in our MIB that require seconds. It would be nice if we could say all the UPS-MIB "time" variables are expressed in seconds so its easier to remember. Eventually I imagine there will be software that converts the time we report in seconds to any format the user choses to display times in. Leaving the variable in seconds gives us the most flexability. Pete Yoest   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10826; 19 Feb 93 12:56 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10822; 19 Feb 93 12:56 EST Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa26440; 19 Feb 93 12:56 EST Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA26140; Fri, 19 Feb 93 12:37:28 -0500 X-Resent-To: ups-mib@CS.UTK.EDU ; Fri, 19 Feb 1993 12:37:27 EST Errors-To: owner-ups-mib@CS.UTK.EDU Received: from ihb.compuserve.com by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA26124; Fri, 19 Feb 93 12:37:23 -0500 Received: by ihb.compuserve.com (5.65/5.930129sam) id AA28184; Fri, 19 Feb 93 12:37:20 -0500 Date: 19 Feb 93 12:31:27 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Phillip H. R. EPPS" <76410.327@compuserve.com> To: ups-mib@cs.utk.edu MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US Subject: Time in Seconds Message-Id: <930219173127_76410.327_CHU41-1@CompuServe.COM> The calculation of the time that the unit will operate on battery presents a significant accuracy problem. Differing battery manufacturers have differences between the time/voltage curves and at light loads the flatness of the curve makes prediction particularly tricky. A 30 minute estimate for time on battery could be +30 - 5 minutes for a unit rated to operate for 10 minutes at full power. However as the battery discharges the voltage/time gradient becomes more defined and when in the 1 - 2 minute region could have an accuracy of +/- a few seconds. To me it makes absolutely no sense to limit us to minutes as the time interval. I agree completely that 90 seconds is a whole lot more meaningfull than 1 +/_ 0.5 minutes. I doubt if there will ever be a need for sub 1 second resolution, but I cannot understand why we should bicker over the obviously correct 1 second granularity. In the same vein we are certainly measuring battery voltage to a much greater resolution than 1 volt and many manufacturers will/are also measuring battery temperature. I certainly vote for the 1/100 of one volt unit base and for the inclusion of battery temperature. The battery capacity percentage resolution is also fine at 1/10 of one percent, even if the accuracy is 10%. Frank Kastenholz should be listened too !!   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18107; 19 Feb 93 17:50 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18103; 19 Feb 93 17:50 EST Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa10911; 19 Feb 93 17:49 EST Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA12190; Fri, 19 Feb 93 17:27:26 -0500 X-Resent-To: ups-mib@CS.UTK.EDU ; Fri, 19 Feb 1993 17:27:25 EST Errors-To: owner-ups-mib@CS.UTK.EDU Received: from hp81.prod.aol.net by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA12182; Fri, 19 Feb 93 17:27:20 -0500 Received: from sco1.prod.aol.net by hp81.prod.aol.net with SMTP (16.6/16.2) id AA20599; Fri, 19 Feb 93 17:26:28 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: oneacupsif@aol.com X-Mailer: America Online Mailer To: ups-mib@cs.utk.edu Subject: Battery Strawman v0.1 Comments Date: Fri, 19 Feb 93 17:27:24 EST Message-Id: <9302191727.tn00384@aol.com> Greetings, After "watching from afar" for a while, I would like to offer my thoughts and "votes" on the UPS Battery Group Strawman v0.1. upsBatteryStatus OK as far as status reporting (unknown, Normal and Low). However, as far as "The amount of run time in reserve at the time of low battery can be configured by the upsConfigLowBatteryRunTime on some UPSs, or by a dip-switch on other UPSs." statement goes, it seems like run time configurability is a requirement. Many UPSs are not configurable in this respect. A statement something like "The amount of run time in reserve at the time of low battery is configurable in some UPSs." might be better. upsBatteryTimeOnBattery My vote - 1 second resolution. upsBatteryCapacity My vote - 1% resolution. I understand the need to not limit ourselves for the future but I can't believe anyone of us can do better than a few percent on this. Even if in the future we can, who cares if you have 30% vs 30.1% of battery capacity left? upsBatteryVoltage My vote - .1V resolution 1 volt resolution is fine for the "casual observer", but a lead acid type of battery really needs .1V resolution for meaningful data. Of course this relates to the total volts in the battery stack. .1V resolution on a 6 or 12 volt battery pack is more meaningful than on a 120 volt battery pack. Future battery technologies might require .01V resolution? I doubt it. upsBatTimeRemaining My vote - 1 second resolution I also (like some of you) like the idea of a "standard" 1 second time unit for all objects in the UPS MIB. Minutes make more sense (today at least) here, but I think seconds make sense long term. upsExtBatteryEnterpriseSpecific I think this one ought to be kept at the group level. Of course, as we progress, the idea of individual EnterpriseSpecific objects versus an overall EnterpriseSpecific object will be hashed out. Deleted variables: upsBatTemperature This one is Important. Maybe many of us are UI on this one, but I think this one ought to be brought back to life. Temperature has a big effect on battery life. The network manager with an SNMP UPS is surely going to be interested in data that says his batteries are not going to live as long as they might. upsBatLastReplacementDate Very useful data - not likely to be consistantly used by our customers! But I like it. Is this one dead? Well, now that I have tested the water - this UPS email MIB discussion stuff is fascinating. John Pierson Oneac   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25445; 22 Feb 93 20:43 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25441; 22 Feb 93 20:43 EST Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa25732; 22 Feb 93 20:43 EST Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA01020; Mon, 22 Feb 93 20:25:59 -0500 X-Resent-To: ups-mib@CS.UTK.EDU ; Mon, 22 Feb 1993 20:25:58 EST Errors-To: owner-ups-mib@CS.UTK.EDU Received: from nic.cerf.net by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA01012; Mon, 22 Feb 93 20:25:56 -0500 Received: by nic.cerf.net (4.1/CERFnet-1.0) id AA19150; Mon, 22 Feb 93 17:28:32 PST Date: Mon, 22 Feb 1993 17:23:21 -0800 (PST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Roger W. Draper" Subject: Re: Time in Seconds To: "Phillip H. R. EPPS" <76410.327@compuserve.com> Cc: ups-mib@cs.utk.edu In-Reply-To: <930219173127_76410.327_CHU41-1@CompuServe.COM> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On 19 Feb 1993, Phillip H. R. EPPS wrote: > I doubt if there will ever be a need for sub 1 second resolution, > but I cannot understand why we should bicker over the > obviously correct 1 second granularity. > After so many months of silence it's finally nice to here people bickering; Thanks for joining the discussion! Roger Liebert.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25519; 22 Feb 93 20:52 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25515; 22 Feb 93 20:52 EST Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa26038; 22 Feb 93 20:52 EST Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA01308; Mon, 22 Feb 93 20:34:32 -0500 X-Resent-To: ups-mib@CS.UTK.EDU ; Mon, 22 Feb 1993 20:34:31 EST Errors-To: owner-ups-mib@CS.UTK.EDU Received: from nic.cerf.net by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA01300; Mon, 22 Feb 93 20:34:30 -0500 Received: by nic.cerf.net (4.1/CERFnet-1.0) id AA19731; Mon, 22 Feb 93 17:37:10 PST Date: Mon, 22 Feb 1993 17:28:50 -0800 (PST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Roger W. Draper" Subject: minutes vs. seconds To: UPS-MIB Mailing list Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Thanks for all the response on this subject. Since I was the last hold out (only hold-out) and the arguments for seconds are so persuasive I vote for seconds. If there are no further inputs shall we consider this a done deal? Roger Liebert.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03382; 23 Feb 93 10:12 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03378; 23 Feb 93 10:12 EST Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa12217; 23 Feb 93 10:12 EST Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA05849; Tue, 23 Feb 93 09:55:21 -0500 X-Resent-To: ups-mib@CS.UTK.EDU ; Tue, 23 Feb 1993 09:55:20 EST Errors-To: owner-ups-mib@CS.UTK.EDU Received: from xap.xyplex.com by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA05835; Tue, 23 Feb 93 09:55:18 -0500 Received: by xap.xyplex.com id ; Tue, 23 Feb 93 12:57:09 -0500 Date: Tue, 23 Feb 93 12:57:09 -0500 Message-Id: <9302231757.AA29502@xap.xyplex.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bob Stewart To: ups-mib@cs.utk.edu In-Reply-To: "Roger W. Draper"'s message of Mon, 22 Feb 1993 17:23:21 -0800 (PST) Subject: Re: Time in Seconds Although I had to resign as co-chair, I've kept a passive interest in your progress. I'm impressed. The process is working. Good job, guys. Bob   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05675; 23 Feb 93 11:41 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05668; 23 Feb 93 11:41 EST Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa16408; 23 Feb 93 11:41 EST Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA11247; Tue, 23 Feb 93 11:25:11 -0500 X-Resent-To: ups-mib@CS.UTK.EDU ; Tue, 23 Feb 1993 11:25:09 EST Errors-To: owner-ups-mib@CS.UTK.EDU Received: from nic.cerf.net by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA11229; Tue, 23 Feb 93 11:25:07 -0500 Received: by nic.cerf.net (4.1/CERFnet-1.0) id AA16785; Tue, 23 Feb 93 08:27:47 PST Date: Tue, 23 Feb 1993 08:26:58 -0800 (PST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Les Matheson Subject: Re: minutes vs. seconds To: "Roger W. Draper" Cc: UPS-MIB Mailing list In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > > Thanks for all the response on this subject. Since I was the last hold > out (only hold-out) and the arguments for seconds are so persuasive I > vote for seconds. If there are no further inputs shall we consider this > a done deal? > > Roger > Liebert. > No, now that you mention it, maybe minutes WOULD be better. . . :-)   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06231; 23 Feb 93 12:01 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06227; 23 Feb 93 12:01 EST Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa17204; 23 Feb 93 12:01 EST Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA12143; Tue, 23 Feb 93 11:44:16 -0500 X-Resent-To: ups-mib@CS.UTK.EDU ; Tue, 23 Feb 1993 11:44:15 EST Errors-To: owner-ups-mib@CS.UTK.EDU Received: from vms.macc.wisc.edu by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA12135; Tue, 23 Feb 93 11:44:14 -0500 Received: from VMSmail by vms.macc.wisc.edu; Tue, 23 Feb 93 10:27 CST Message-Id: <23022310271405@vms.macc.wisc.edu> Date: Tue, 23 Feb 93 10:27 CST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Brian Young Subject: Seconds To: ups-mib@cs.utk.edu X-Vms-To: in%"ups-mib@cs.utk.edu",BYOUNG Greetings all! BEST also agrees to seconds. The bickering isn't bad either.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07156; 23 Feb 93 12:32 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07152; 23 Feb 93 12:32 EST Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa18491; 23 Feb 93 12:32 EST Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA13697; Tue, 23 Feb 93 12:13:06 -0500 X-Resent-To: ups-mib@CS.UTK.EDU ; Tue, 23 Feb 1993 12:13:04 EST Errors-To: owner-ups-mib@CS.UTK.EDU Received: from CASE.CS.UTK.EDU by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA13638; Tue, 23 Feb 93 12:12:52 -0500 Received: from LOCALHOST.cs.utk.edu by case.cs.utk.edu with SMTP (5.61++/2.7c-UTK) id AA02122; Tue, 23 Feb 93 12:12:50 -0500 Message-Id: <9302231712.AA02122@case.cs.utk.edu> To: ups-mib@cs.utk.edu Cc: key@cs.utk.edu Subject: UPS-MIB Seconds/battery Temp. Date: Tue, 23 Feb 93 12:12:50 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: key@cs.utk.edu Hi All, I think I detect a concensus here, seconds. Now Les and any other switch-overs to the minutes camp will need to raise a stink :-) I need to do some more analysis of the discussion, but the next battery item I'd like to see "debated" is: Battery temperature: bring it back or kill it again? I'll start by saying I've heard some good arguments for bringing it back, even if it can't be supported on all platforms today. The last few comments have been on the bring-it-back side. Any response from the keep-it-deads? Ken Key   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11484; 23 Feb 93 16:47 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11478; 23 Feb 93 16:47 EST Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa29674; 23 Feb 93 16:47 EST Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA27432; Tue, 23 Feb 93 16:30:32 -0500 X-Resent-To: ups-mib@CS.UTK.EDU ; Tue, 23 Feb 1993 16:30:31 EST Errors-To: owner-ups-mib@CS.UTK.EDU Received: from nic.cerf.net by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA27414; Tue, 23 Feb 93 16:30:29 -0500 Received: by nic.cerf.net (4.1/CERFnet-1.0) id AA07471; Tue, 23 Feb 93 13:33:09 PST Date: Tue, 23 Feb 1993 13:30:39 -0800 (PST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Roger W. Draper" Subject: Battery Temp--YES To: UPS-MIB Mailing list Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I vote to include battery temp. Roger Liebert.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13979; 23 Feb 93 18:50 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13975; 23 Feb 93 18:50 EST Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa06088; 23 Feb 93 18:50 EST Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA03883; Tue, 23 Feb 93 18:32:21 -0500 X-Resent-To: ups-mib@CS.UTK.EDU ; Tue, 23 Feb 1993 18:32:20 EST Errors-To: owner-ups-mib@CS.UTK.EDU Received: from iha.compuserve.com by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA03860; Tue, 23 Feb 93 18:32:10 -0500 Received: by iha.compuserve.com (5.65/5.930129sam) id AA14548; Tue, 23 Feb 93 18:32:07 -0500 Date: 23 Feb 93 18:23:05 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dane Groszek <71213.2320@compuserve.com> To: All Subject: Battery time Message-Id: <930223232304_71213.2320_DHQ35-1@CompuServe.COM> Subject: Battery time If the variable is intented to provide an anticipated reserve time available from a battery prior to a utility failure, then I would agree with reporting "predicted" battery time in minutes, as I agree with Roger that batteries are too unpredictable. Many factors affect the amount of energy available (and therefore the time) from a battery and the degree to which they affect batteries is not always the same. If the intention of the variable is to report the amount of time the battery has been discharged, then it should be reported in seconds. What is the intent? Kevin Collins K/W Control Systems   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08314; 24 Feb 93 12:02 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08310; 24 Feb 93 12:02 EST Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa18183; 24 Feb 93 12:02 EST Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA17193; Wed, 24 Feb 93 11:32:33 -0500 X-Resent-To: ups-mib@CS.UTK.EDU ; Wed, 24 Feb 1993 11:32:31 EST Errors-To: owner-ups-mib@CS.UTK.EDU Received: from nic.cerf.net by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA17184; Wed, 24 Feb 93 11:32:29 -0500 Received: by nic.cerf.net (4.1/CERFnet-1.0) id AA28523; Wed, 24 Feb 93 08:35:09 PST Date: Wed, 24 Feb 1993 08:33:31 -0800 (PST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Les Matheson Subject: Keep the battery temperature To: ups mib Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII This is a good thing. We want battery temperature. We like it. We must have it. It's useful.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08743; 24 Feb 93 12:18 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08739; 24 Feb 93 12:18 EST Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa18693; 24 Feb 93 12:18 EST Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA17426; Wed, 24 Feb 93 11:37:30 -0500 X-Resent-To: ups-mib@CS.UTK.EDU ; Wed, 24 Feb 1993 11:37:29 EST Errors-To: owner-ups-mib@CS.UTK.EDU Received: from nic.cerf.net by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA17414; Wed, 24 Feb 93 11:37:27 -0500 Received: by nic.cerf.net (4.1/CERFnet-1.0) id AA28793; Wed, 24 Feb 93 08:38:15 PST Date: Wed, 24 Feb 1993 08:36:43 -0800 (PST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Les Matheson Subject: Re: Battery time To: Dane Groszek <71213.2320@compuserve.com> Cc: All In-Reply-To: <930223232304_71213.2320_DHQ35-1@CompuServe.COM> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On 23 Feb 1993, Dane Groszek wrote: > > Subject: Battery time > > If the variable is intented to provide an anticipated > reserve time available from a battery prior to a utility failure, > then I would agree with reporting "predicted" battery time in > minutes, as I agree with Roger that batteries are too > unpredictable. Many factors affect the amount of energy > available (and therefore the time) from a battery and the degree > to which they affect batteries is not always the same. If the > intention of the variable is to report the amount of time the > battery has been discharged, then it should be reported in > seconds. What is the intent? > > Kevin Collins > K/W Control Systems > > Just in case anyone misunderstood, I was *kidding* when I changed my mind from seconds to minutes. You're on your own arguing this point, Kevin. . . :-) Les Matheson Liebert   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13799; 24 Feb 93 17:03 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13795; 24 Feb 93 17:03 EST Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa27956; 24 Feb 93 17:03 EST Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA11456; Wed, 24 Feb 93 16:38:05 -0500 X-Resent-To: ups-mib@CS.UTK.EDU ; Wed, 24 Feb 1993 16:38:04 EST Errors-To: owner-ups-mib@CS.UTK.EDU Received: from HUACHUCA-EMH1.ARMY.MIL by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA11448; Wed, 24 Feb 93 16:38:01 -0500 Message-Id: <9302242138.AA11448@CS.UTK.EDU> Date: Wed, 24 Feb 93 14:35:40 MST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Mark F. Rhyner" To: ups-mib@cs.utk.edu Cc: mrhyner@huachuca-emh1.army.mil Subject: Status of MIB? Can someone tell me the status of the UPS-MIB? Is it going into an RFC and if not how can it be specified? Thanks, Mark ############################################################################## # Mark Rhyner # # # USAISEC # # # ASQB-OSE-PA # SPACE FOR RENT # # DSN: 879-3197 COMM: (602) 538-3197 # # # EMAIL: mrhyner@huachuca-emh1.army.mil # # # or mrhyner%sed@huachuca-emh8.army.mil # # # or CIS: 71441,1316 GENIE: M.RHYNER1 # # ##############################################################################   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05609; 25 Feb 93 9:28 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05605; 25 Feb 93 9:28 EST Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa08563; 25 Feb 93 9:28 EST Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA22889; Thu, 25 Feb 93 09:12:48 -0500 X-Resent-To: ups-mib@CS.UTK.EDU ; Thu, 25 Feb 1993 09:12:47 EST Errors-To: owner-ups-mib@CS.UTK.EDU Received: from ihb.compuserve.com by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA22881; Thu, 25 Feb 93 09:12:44 -0500 Received: by ihb.compuserve.com (5.65/5.930129sam) id AA04602; Thu, 25 Feb 93 09:12:43 -0500 Date: 25 Feb 93 09:08:55 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dane Groszek <71213.2320@compuserve.com> To: All Subject: BatTemp Message-Id: <930225140854_71213.2320_DHQ51-1@CompuServe.COM> Subject: Battery Temperature I would agree with keeping battery temperature. Kevin Collins K/W Control Systems