Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18700; 27 Sep 95 18:10 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa18696; 27 Sep 95 18:10 EDT Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa22240; 27 Sep 95 18:10 EDT Received: from localhost by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id SAA29861; Wed, 27 Sep 1995 18:04:38 -0400 X-Resent-To: ups-mib@CS.UTK.EDU ; Wed, 27 Sep 1995 18:04:36 EDT Errors-to: owner-ups-mib@CS.UTK.EDU Received: from cavebear.com by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id SAA29854; Wed, 27 Sep 1995 18:04:33 -0400 Received: by cavebear.com (4.1/SMI-4.1) id AA01946; Wed, 27 Sep 95 15:04:29 PDT Date: Wed, 27 Sep 1995 15:04:29 -0700 (PDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Michael Kirkham X-Sender: mikek@pax.cavebear.com To: UPS MIB List Subject: Configuration Group Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Greetings folks.. I'm part of a project developing a Test Suite for testing agents implementing the UPS MIB (RFC 1628) that is nearing completion. I'd like a little clarification about the Configuration Group: Do the Configuration Group objects actually change operating conditions, or are they just basically placeholders allowing a manager to request values that are [likely] to be the operating values? It seems to me that some of these objects could potentially be a danger to the UPS and equipment plugged into the UPS if they change the operating conditions. Specifically, upsConfigInputVoltage, upsConfigInputFreq, upsConfigOutputVoltage and upsConfigOutputFreq would be really *bad* things to change on a UPS that is in use, but MAX-ACCESS for these objects is read-write. You could damage the UPS by telling it to operate under 110V while it's plugged into 220V, for instance. Or you could damage equipment plugged into the UPS by changing its output voltage. So, I'm a little worried about what I should be expecting the UPS to do when a SET is done to these objects. The RFC doesn't say if the objects are not to change functional parameters when these objects are set. It doesn't say they should, either.. :) -- Michael Kirkham InterWorking Labs, Inc. 218 Carbonera Drive, Suite 102 Santa Cruz, CA 95060-1500 Tel: +1 408 459 9817 Fax: +1 408 459 9768 Email: mikek@iwl.com WWW: www.iwl.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07891; 28 Sep 95 8:18 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07886; 28 Sep 95 8:18 EDT Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa08697; 28 Sep 95 8:18 EDT Received: from localhost by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id IAA10740; Thu, 28 Sep 1995 08:15:31 -0400 Received: from sun4nl.NL.net by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id IAA10718; Thu, 28 Sep 1995 08:15:21 -0400 Received: from [193.78.6.6] by sun4nl.NL.net with SMTP id AA20183 (5.65b/CWI-3.3); Thu, 28 Sep 1995 13:15:11 +0100 Received: from vic1.victron.nl by vicnl.victron.nl id aa27793; 28 Sep 95 8:37 CET Received: from VICTRON_ONE/TEMPQ by vic1.victron.nl (Mercury 1.13); Thu, 28 Sep 95 8:37:55 CET Received: from TEMPQ by VICTRON_ONE (Mercury 1.13); Thu, 28 Sep 95 8:37:34 CET Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Jack Stiekema Organization: Victron bv, UPS and software To: ups-mib@cs.utk.edu Date: Thu, 28 Sep 1995 08:37:31 CET Subject: Re: Configuration Group Priority: normal X-Mailer: Pegasus Mail v3.22 Message-Id: <5524DF10AA@vic1.victron.nl> > Date sent: Wed, 27 Sep 1995 15:04:29 -0700 (PDT) > From: Michael Kirkham > To: UPS MIB List > Subject: Configuration Group > > Greetings folks.. Hi > Specifically, upsConfigInputVoltage, upsConfigInputFreq, > upsConfigOutputVoltage and upsConfigOutputFreq would be really *bad* > > So, I'm a little worried about what I should be expecting the UPS to do > when a SET is done to these objects. The RFC doesn't say if the objects Don't worry, most of us (UPS vendors) made it Read Only. Some have a dipswitch or jumper which allows R/W acces for localising. Kind regards, Jack Stiekema Head Software Department +------------------------+ | Phone: +31 505446284 | | GSM: +31 653145069 | | Fax: +31 505424107 | | BBS: +31 505446280 | | Email: jack@victron.nl | | WWW: www.victron.nl | | Ampr: pe0mot.ampr.org | +------------------------+ | IMV / Victron bv | | Pob 31 | | 9700 AA Groningen | | Holland | +------------------------+   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15897; 28 Sep 95 15:30 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa15893; 28 Sep 95 15:30 EDT Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa18722; 28 Sep 95 15:30 EDT Received: from localhost by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id PAA22119; Thu, 28 Sep 1995 15:25:47 -0400 Received: from relay3.UU.NET by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id PAA22098; Thu, 28 Sep 1995 15:25:43 -0400 Received: from uucp6.UU.NET by relay3.UU.NET with SMTP id QQzjej08133; Thu, 28 Sep 1995 15:25:39 -0400 Received: from stg.UUCP by uucp6.UU.NET with UUCP/RMAIL ; Thu, 28 Sep 1995 15:26:07 -0400 Received: by mcbain.stg.com (4.1/SMI-4.1) id AA22870; Thu, 28 Sep 95 14:00:14 CDT Date: Thu, 28 Sep 95 14:00:14 CDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Chris Herzog Message-Id: <9509281900.AA22870@mcbain.stg.com> To: uunet!CS.UTK.EDU!ups-mib@uunet.uu.net, uunet!cavebear.com!mikek@uunet.uu.net Subject: Re: Configuration Group > I'm part of a project developing a Test Suite for testing agents > implementing the UPS MIB (RFC 1628) that is nearing completion. I'd like > a little clarification about the Configuration Group: > > Do the Configuration Group objects actually change operating conditions, > or are they just basically placeholders allowing a manager to request > values that are [likely] to be the operating values? It seems to me that > some of these objects could potentially be a danger to the UPS and > equipment plugged into the UPS if they change the operating conditions. > > Specifically, upsConfigInputVoltage, upsConfigInputFreq, > upsConfigOutputVoltage and upsConfigOutputFreq would be really *bad* > things to change on a UPS that is in use, but MAX-ACCESS for these > objects is read-write. You could damage the UPS by telling it to operate > under 110V while it's plugged into 220V, for instance. Or you could > damage equipment plugged into the UPS by changing its output voltage. I think you're mixing what the MIB allows with the real world more than you might need to as far as a test suite goes. My feeling is that you're right in testing all the way up to the full capabilities of the MIB -- including changing these values to possibly non-sensical combos. If the MIB allows writing, test that bad boy for writing! For a test suite, you should test writability of any object that the MIB defines as writable but then need to interpret the entire set of results in the view of the various conformance levels. Different agents could conform to different levels which would affect how certain objects operate (or in fact if they are supported at all) -- the MIB states that R/W access is not _required_ but certainly is _permitted_. So long as you keep in mind the intended level of conformance when you report the results at the end of the test, things should be cool. These are just some particular objects where if you only allow read access you're OK, but if you actually do allow write access, you aren't any "more" correct than a read-only implementation IMHO. Like Jack pointed out, I think the mfgrs have taken a precaution or two to stop "bad" things from happening if in fact they allow write access to those variables so you certainly should "test" them for writability. If setting a variable causes the UPS or it's load to explode; well, let's just say it's more than an agent conformance problem :o > So, I'm a little worried about what I should be expecting the UPS to do > when a SET is done to these objects. The RFC doesn't say if the objects > are not to change functional parameters when these objects are set. It > doesn't say they should, either.. :) I think you'd be safe to assume that if you _can_ write those values, you actually changed the operational parameters. Otherwise the implementation is reporting bogus data if it's just using it as a "placeholder". Just my thoughts... zog -- Chris Herzog Software Technologies Group zog@stg.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19641; 28 Sep 95 18:17 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa19637; 28 Sep 95 18:17 EDT Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa22693; 28 Sep 95 18:17 EDT Received: from localhost by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id SAA11925; Thu, 28 Sep 1995 18:11:27 -0400 Received: from relay1.UU.NET by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id SAA11911; Thu, 28 Sep 1995 18:11:22 -0400 Received: from uucp3.UU.NET by relay1.UU.NET with SMTP id QQzjeu12536; Thu, 28 Sep 1995 18:11:09 -0400 (EDT) Received: from peernet.UUCP by uucp3.UU.NET with UUCP/RMAIL ; Thu, 28 Sep 1995 18:11:13 -0400 Received: from dorothy.peer.com by peernet.peer.com (4.1/SMI-4.1) id AA05598; Thu, 28 Sep 95 15:07:46 PDT Received: by dorothy.peer.com (4.1/SMI-4.1) id AA12793; Thu, 28 Sep 95 15:07:48 PDT Date: Thu, 28 Sep 95 15:07:48 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Randy Presuhn Message-Id: <9509282207.AA12793@dorothy.peer.com> To: ups-mib@cs.utk.edu Subject: Re: Configuration Group Hi - > Date: Thu, 28 Sep 95 14:00:14 CDT > From: zog@stg (Chris Herzog) > To: CS.UTK.EDU!ups-mib@uunet, cavebear.com!mikek@uunet > Subject: Re: Configuration Group ... > I think you'd be safe to assume that if you _can_ write those values, you > actually changed the operational parameters. Otherwise the implementation is > reporting bogus data if it's just using it as a "placeholder". ... There's some interesting work going on with EWOS (European Workshop for Open Systems) PT (Project Team) 28 on the testability of managed objects. If you ask nicely, you may get a draft from John Westgate <100014.1305@compuserve.com> when the next revision goes out for comment. This work addresses issues like the ones in this discussion. ISO/IEC JTC1/SC21/WG7 is considering using the PT 28 work and will discuss it in Kobe, Japan in November. If you have comments you'd like included, contact me for ways of getting them into X3T3. --------------------------------------------------------------- Randy Presuhn PEER Networks, Inc. Voice: +1 408 556-0720 1190 Saratoga Avenue, Suite 130 Fax: +1 408 556-0735 San Jose, California 95129-3433 Email: randy@peer.com USA ---------------------------------------------------------------