home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / upsmib / upsmib-minutes-93mar.txt < prev    next >
Text File  |  1993-05-14  |  9KB  |  234 lines
  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4.  
  5. Reported by Bob Stewart/Xyplex
  6.  
  7. Minutes of the Uninterruptible Power Supply Working Group (UPSMIB)
  8.  
  9. The UPSMIB Working Group held a meeting at the IETF meeting in Columbus,
  10. Ohio, on Thursday, 1 April 1993.  Jeff Case and Ken Key presided and
  11. shanghaied Bob Stewart to record.
  12.  
  13. General Discussion
  14.  
  15. There was a review of the IETF process based on RFC1310, mentioning the
  16. terms Internet-Draft, Proposed/Draft Internet Standard.  Final review
  17. and approval is by the IESG.
  18.  
  19. The history of the document is:  two company submissions at the BOF in
  20. Cambridge, synthesis, discussion, strawman proposals, surveys and
  21. analysis.  The draft is not final yet and still requires consensus on
  22. what to include.
  23.  
  24. Cycle time for this group is slower due to less direct Internet
  25. involvement.
  26.  
  27. UPSMIB is the first IETF MIB that is not a direct component of
  28. communication; a ``toaster'' MIB. UPSs have been remotely managed for a
  29. long time, providing an important experience base.  A Group member
  30. suggested that the Group should get on with the real work.
  31.  
  32. Brief introductions around the room revealed about fifteen vendors, two
  33. users, and a scattering of telecommunications, NMS, and agent people.
  34.  
  35. The Group needs to decide about its next meeting based on progress in
  36. the near future.  About 8-10 of the present attendees could come to
  37. Amsterdam.  It's a long trip for a single meeting, and most have no
  38. other IETF interests.
  39.  
  40. Review of Strawman
  41.  
  42. The Strawman had been sent out via email a week prior to the IETF
  43. meeting.  Several questions were raised.
  44.  
  45.  
  46.    o Should enterprise-specific OID be one per MIB or per Group?
  47.  
  48.    o Should input frequence resolution be 0.1 hz?
  49.  
  50.    o What is the definition of blackout versus brownout?  Should MIB
  51.      include brownout?  The ensuing discussion of the blackout counter
  52.      took most of the meeting, recorded here is sequential statements.
  53.  
  54.                                    1
  55.  
  56. Just make it line failures.  Count times gone to battery.  Blackout is
  57. too specific.  This should be a badness indicator.  Is count for
  58. lifetime or uptime?  A motor/generator is outside the charter; the
  59. concern is batter UPSs.  Move counter to batter Group and count times on
  60. battery.  Email result has been fewer counters for line problems.  If
  61. not characterized accurately, the counter is not useful.  Any count can
  62. stimulate investigation.  Other counters were discussed and removed at
  63. Dallas meeting; a standard definition was promised but not delivered;
  64. Roger Draper will provide the definition.
  65.  
  66. Count times line was bad enough to need battery, distinct from other
  67. reasons.  All input values should be by line.  Count times line failure
  68. would have gone to batter without other line.
  69.  
  70. Define real limits.  Report value and let NMS check limits.  Must not
  71. poll too often.  Let NMS set threshold at UPS.
  72.  
  73. Possible choices are:
  74.  
  75.  
  76.   a. Each vendor decides criteria and agent checks.
  77.   b. Group decides criteria or uses other standard, agent checks.
  78.   c. Supply tunable criteria for agent to check.
  79.   d. Agent supplies conditions for NMS to check.
  80.  
  81.  
  82. The strong consensus was this list is complete.
  83.  
  84. What is the tool for an administrator?  It should warn administrator of
  85. an impending problem.
  86.  
  87. (c) can have defaults and implies MIB variables and storage.  (d) was
  88. not well liked but some of it is useful and good.  (c) requires many
  89. read-write variables with storage, plus customer education, but is most
  90. flexible, although a human will misconfigure it.  (a) can't distinguish
  91. sensitive criteria from insensitive, which are based on vendor goals;
  92. administrator can't form judgements; it's the easiest to agree on.  The
  93. Group should be able to do (b).  (b) can't be done.  Consensus for (b)
  94. is not possible.  IEEE defines blackout.  Avoid dependency on other
  95. organizations by including their specification in this document.  The
  96. list of definitions is very large.
  97.  
  98. Consensus is that (b) is desirable but not achievable for input group.
  99. (c) is too complex, must do (a).  Like (c) but how many variables?
  100. Prefer (c) with vendor defaults.  Cost of (c) is high and allows manager
  101. to do the wrong thing.  Prefer (a) because administrator doesn't want to
  102. know and (c) is a support problem.
  103.  
  104. MIB will have alarms, so (a) is redundant.  A trap may get lost and the
  105. NMS may go away.  Conditions indicate values, alarms indicate
  106.  
  107.                                    2
  108.  
  109.  
  110.  
  111.  
  112.  
  113. comparisons, notifications imply telling someone; first two can be
  114. polled, last can be lost.  Words must be used carefully.
  115.  
  116. Details are redundant between input and batter groups.  That is not true
  117. if bad line is different from on battery.  Criteria may be tight for
  118. poor power, less so for insufficient power.  (c) requires agreeing on
  119. list, (a) is only possibility.  (c) could be vendor specific.  UPS must
  120. report failures that are covered by redundancy.
  121.  
  122. One of the users likes (a) and (d) to cross check vendor settings.  (d)
  123. could be vendor specific.  (c) could be optional but a standard group to
  124. encourage NMSs to do standard screens; require group if capability
  125. present.  How does an NMS determine what's there.  There are standard
  126. ways, which can be agreed.
  127.  
  128. There was no strong consensus for (a) and optional (b).  Check for
  129. strong disagreement.  The MIB should be as much ***d and required as
  130. possible; agreement is best.  An optional standard is weaker than a
  131. required one, but better than enterprise MIBs.
  132.  
  133. There was very weak consensus on an optional threshold group.  Users
  134. don't know what to do with (c), do (a) only.  An expert will need
  135. multiple groups rather than one group.
  136.  
  137. Vendors can leave things out, not be compliant and let the market
  138. decide.  Some groups do not work without some objects, such as indexes.
  139. (c) is not achievable, even as optional.  Group could define parameters
  140. and do general thresholds.  It may not be possible to model parameter;
  141. do (a).  Leave it to (a) and let vendors publish their criteria.  It is
  142. necessary to try defining (c) to see if it's possible.  Could everyone
  143. agree on a value for harmonic distortion?
  144.  
  145. An attempted list of parameters was suggested:  input voltage out of
  146. range, input frequency out of range, phase error from input wiring,
  147. phase angle out of tolerance, other screw-ups.  These are not clear
  148. values.
  149.  
  150. Suddenly there was a strong Group consensus that (c) is not possible and
  151. (a) is the only way.  Blackout counter becomes ``line was bad'' as
  152. defined by vendor and is per line.  Frequency is by line and is zero if
  153. not measurable.
  154.  
  155. Can line index be a/b/c rather than a number?  No.
  156.  
  157. Doe MIB need a line-to-line table and a separate line to neutral table?
  158. Decide when columns are determined.  The line table has an index,
  159. voltage, frequency, and bad line counter.  Lines could all be good, but
  160. an input bad.  Strawman will model one table, with user-friendly label,
  161. line to line, and line to neutral.
  162.  
  163. .  There will be one MIB document with multiple compliance statements.
  164. This may eliminate debate or may add some.  It uses the SNMPv2 tools for
  165. documentation.
  166.  
  167.  
  168.                                    3
  169.  
  170.  
  171.  
  172.  
  173.  
  174. Presentation of a Contact Closure MIB - by Ray Wasson
  175.  
  176. Ray's presentation included the following points:
  177.  
  178.  
  179.    o UPSs need a simple MIB group for contact closure devices.  A
  180.      handout four objects:  upsControlOutputOffDelay,
  181.      upsControlAudioOutput, upsTestBattery, and upsTestBatteryStatus.
  182.      This is a minimum, and less than the previously-proposed basic MIB.
  183.  
  184.    o It could use some additions from the original basic proposal.  Some
  185.      basic objects, such as location, are in MIB-II.
  186.  
  187.    o This is preferable as a simple, separate document, forwarded
  188.      separately.  It is best if basic info is common across all levels
  189.      of MIB. A small MIB is not a direct subset, but picks from groups
  190.      and loses context.
  191.  
  192.    o Jeff will discuss separate documents with SNMP Directorate.
  193.      Compliance groups will cover this without separate documents.
  194.      There is concern that waiting for the whole thing takes too long.
  195.  
  196.    o There was no consensus on the proposal.  The group was not willing
  197.      to decide without understanding new compliance specifications.  The
  198.      group needs to resolve conflicts and move forward.
  199.  
  200.    o For email:  Is the contact closure proposal or the original basic
  201.      MIB a possible separate document.  Complaince should require naming
  202.      compliance groups implemented.  The consensus was for Jeff to see
  203.      if that is allowable.  He expects the SNMP Directorate to allow 2
  204.      but not more.  Jeff will email SNMPv2 compliance document.
  205.  
  206.  
  207. MIB Group Spokesmen
  208.  
  209. Volunteers were found to act as spokesmen to push progress on each MIB
  210. group:
  211.  
  212.  
  213. Configuration       Tom Brennan
  214. Control             Adam Stolinski
  215. Alarm               Terry Zumwalt
  216. Bypass              Roger Draper
  217. Output              Roger Draper
  218. Battery             Phillip Epps
  219. Identity            Steve Held
  220.  
  221.                                    4
  222.  
  223.  
  224.  
  225.  
  226.  
  227. Input               Roger Draper
  228. Test                Doug Rademacher
  229. Traps               Jeff Case
  230.  
  231.  
  232.  
  233.                                    5
  234.