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