home *** CD-ROM | disk | FTP | other *** search
-
- CURRENT_MEETING_REPORT_
-
-
- Reported by Bob Stewart/Xyplex
-
- Minutes of the Uninterruptible Power Supply Working Group (UPSMIB)
-
- The UPSMIB Working Group held a meeting at the IETF meeting in Columbus,
- Ohio, on Thursday, 1 April 1993. Jeff Case and Ken Key presided and
- shanghaied Bob Stewart to record.
-
- General Discussion
-
- There was a review of the IETF process based on RFC1310, mentioning the
- terms Internet-Draft, Proposed/Draft Internet Standard. Final review
- and approval is by the IESG.
-
- The history of the document is: two company submissions at the BOF in
- Cambridge, synthesis, discussion, strawman proposals, surveys and
- analysis. The draft is not final yet and still requires consensus on
- what to include.
-
- Cycle time for this group is slower due to less direct Internet
- involvement.
-
- UPSMIB is the first IETF MIB that is not a direct component of
- communication; a ``toaster'' MIB. UPSs have been remotely managed for a
- long time, providing an important experience base. A Group member
- suggested that the Group should get on with the real work.
-
- Brief introductions around the room revealed about fifteen vendors, two
- users, and a scattering of telecommunications, NMS, and agent people.
-
- The Group needs to decide about its next meeting based on progress in
- the near future. About 8-10 of the present attendees could come to
- Amsterdam. It's a long trip for a single meeting, and most have no
- other IETF interests.
-
- Review of Strawman
-
- The Strawman had been sent out via email a week prior to the IETF
- meeting. Several questions were raised.
-
-
- o Should enterprise-specific OID be one per MIB or per Group?
-
- o Should input frequence resolution be 0.1 hz?
-
- o What is the definition of blackout versus brownout? Should MIB
- include brownout? The ensuing discussion of the blackout counter
- took most of the meeting, recorded here is sequential statements.
-
- 1
-
- Just make it line failures. Count times gone to battery. Blackout is
- too specific. This should be a badness indicator. Is count for
- lifetime or uptime? A motor/generator is outside the charter; the
- concern is batter UPSs. Move counter to batter Group and count times on
- battery. Email result has been fewer counters for line problems. If
- not characterized accurately, the counter is not useful. Any count can
- stimulate investigation. Other counters were discussed and removed at
- Dallas meeting; a standard definition was promised but not delivered;
- Roger Draper will provide the definition.
-
- Count times line was bad enough to need battery, distinct from other
- reasons. All input values should be by line. Count times line failure
- would have gone to batter without other line.
-
- Define real limits. Report value and let NMS check limits. Must not
- poll too often. Let NMS set threshold at UPS.
-
- Possible choices are:
-
-
- a. Each vendor decides criteria and agent checks.
- b. Group decides criteria or uses other standard, agent checks.
- c. Supply tunable criteria for agent to check.
- d. Agent supplies conditions for NMS to check.
-
-
- The strong consensus was this list is complete.
-
- What is the tool for an administrator? It should warn administrator of
- an impending problem.
-
- (c) can have defaults and implies MIB variables and storage. (d) was
- not well liked but some of it is useful and good. (c) requires many
- read-write variables with storage, plus customer education, but is most
- flexible, although a human will misconfigure it. (a) can't distinguish
- sensitive criteria from insensitive, which are based on vendor goals;
- administrator can't form judgements; it's the easiest to agree on. The
- Group should be able to do (b). (b) can't be done. Consensus for (b)
- is not possible. IEEE defines blackout. Avoid dependency on other
- organizations by including their specification in this document. The
- list of definitions is very large.
-
- Consensus is that (b) is desirable but not achievable for input group.
- (c) is too complex, must do (a). Like (c) but how many variables?
- Prefer (c) with vendor defaults. Cost of (c) is high and allows manager
- to do the wrong thing. Prefer (a) because administrator doesn't want to
- know and (c) is a support problem.
-
- MIB will have alarms, so (a) is redundant. A trap may get lost and the
- NMS may go away. Conditions indicate values, alarms indicate
-
- 2
-
-
-
-
-
- comparisons, notifications imply telling someone; first two can be
- polled, last can be lost. Words must be used carefully.
-
- Details are redundant between input and batter groups. That is not true
- if bad line is different from on battery. Criteria may be tight for
- poor power, less so for insufficient power. (c) requires agreeing on
- list, (a) is only possibility. (c) could be vendor specific. UPS must
- report failures that are covered by redundancy.
-
- One of the users likes (a) and (d) to cross check vendor settings. (d)
- could be vendor specific. (c) could be optional but a standard group to
- encourage NMSs to do standard screens; require group if capability
- present. How does an NMS determine what's there. There are standard
- ways, which can be agreed.
-
- There was no strong consensus for (a) and optional (b). Check for
- strong disagreement. The MIB should be as much ***d and required as
- possible; agreement is best. An optional standard is weaker than a
- required one, but better than enterprise MIBs.
-
- There was very weak consensus on an optional threshold group. Users
- don't know what to do with (c), do (a) only. An expert will need
- multiple groups rather than one group.
-
- Vendors can leave things out, not be compliant and let the market
- decide. Some groups do not work without some objects, such as indexes.
- (c) is not achievable, even as optional. Group could define parameters
- and do general thresholds. It may not be possible to model parameter;
- do (a). Leave it to (a) and let vendors publish their criteria. It is
- necessary to try defining (c) to see if it's possible. Could everyone
- agree on a value for harmonic distortion?
-
- An attempted list of parameters was suggested: input voltage out of
- range, input frequency out of range, phase error from input wiring,
- phase angle out of tolerance, other screw-ups. These are not clear
- values.
-
- Suddenly there was a strong Group consensus that (c) is not possible and
- (a) is the only way. Blackout counter becomes ``line was bad'' as
- defined by vendor and is per line. Frequency is by line and is zero if
- not measurable.
-
- Can line index be a/b/c rather than a number? No.
-
- Doe MIB need a line-to-line table and a separate line to neutral table?
- Decide when columns are determined. The line table has an index,
- voltage, frequency, and bad line counter. Lines could all be good, but
- an input bad. Strawman will model one table, with user-friendly label,
- line to line, and line to neutral.
-
- . There will be one MIB document with multiple compliance statements.
- This may eliminate debate or may add some. It uses the SNMPv2 tools for
- documentation.
-
-
- 3
-
-
-
-
-
- Presentation of a Contact Closure MIB - by Ray Wasson
-
- Ray's presentation included the following points:
-
-
- o UPSs need a simple MIB group for contact closure devices. A
- handout four objects: upsControlOutputOffDelay,
- upsControlAudioOutput, upsTestBattery, and upsTestBatteryStatus.
- This is a minimum, and less than the previously-proposed basic MIB.
-
- o It could use some additions from the original basic proposal. Some
- basic objects, such as location, are in MIB-II.
-
- o This is preferable as a simple, separate document, forwarded
- separately. It is best if basic info is common across all levels
- of MIB. A small MIB is not a direct subset, but picks from groups
- and loses context.
-
- o Jeff will discuss separate documents with SNMP Directorate.
- Compliance groups will cover this without separate documents.
- There is concern that waiting for the whole thing takes too long.
-
- o There was no consensus on the proposal. The group was not willing
- to decide without understanding new compliance specifications. The
- group needs to resolve conflicts and move forward.
-
- o For email: Is the contact closure proposal or the original basic
- MIB a possible separate document. Complaince should require naming
- compliance groups implemented. The consensus was for Jeff to see
- if that is allowable. He expects the SNMP Directorate to allow 2
- but not more. Jeff will email SNMPv2 compliance document.
-
-
- MIB Group Spokesmen
-
- Volunteers were found to act as spokesmen to push progress on each MIB
- group:
-
-
- Configuration Tom Brennan
- Control Adam Stolinski
- Alarm Terry Zumwalt
- Bypass Roger Draper
- Output Roger Draper
- Battery Phillip Epps
- Identity Steve Held
-
- 4
-
-
-
-
-
- Input Roger Draper
- Test Doug Rademacher
- Traps Jeff Case
-
-
-
- 5
-