Subject: Last WG Meeting Minutes (4/96)

From: [email-masked] (Maria Greene)
Date: Wed, 6 May 1998 14:30:30 -0400

Here are the minutes from the last working group meeting, over two
years ago. Any comment on the suggestions that were made?

By the way, on the action item I had (item 3 in the first section
below), please see draft-ietf-ifmib-testmib-03.txt.

Maria

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

Minutes of the Uninterruptible Power Supply MIB Working Group (UPSMIB)

The UPS MIB Working Group met on Friday, March 8, 1996, at the 35th Meeting
of the Internet Engineering Task Force, in Los Angeles, California, USA.

The progress which could be made during the meeting was limited by light
attendance among the UPS vendors who have been participating in the process.
Two agent implementations were represented and an unusually large level
of MIB design and SNMP experience and expertise was in attendance.

The meeting began with a review of the implementation surveys underway
via the network.  The attendees found the surveys to be understandable,
able to be completed, and generally satisfactory.  One estimate is that it
takes approximately 1-2 hours per product per vendor to complete the agent
implementation survey.

Chris Wellens reported on the results of developing and using a test tool
which identified some common problem areas.  They are as follows:

1.  The descriptions of the alarms need to be clarified.  For example,
    are upsAlarmOutputOffAsRequested and upsAlarmUpsOffAsRequested
    mutually exclusive?

    The mini-conclusion on this topic of discussion was that they should
    be considered mutually exclusive unless there is considerable momentum
    toward a different position.

    It was suggested that there may need additional text to explain if
    "as requested" is only via a management request or if operation action
    via local or remote interfaces are also considered "as requested."

1b. upsAlarmDiagnosticTestFailed

    When does the agent remove such an entry from the alarm table?

    Answer:  upon a reboot or a successful test completed via any way
    a diagnostic test is invoked, i.e., automatic upon reboot, set request,
    operation operation, etc.

2.  Page 30 is unclear and text should be added to indicate that a trap
    should be sent both upon addition and removal from the alarm table and
    test completed.  This conclusion was reached after much discussion
    and consideration of the possibilities for suppressing redundant traps.

3.  Spinlock was problematic for multiple implementations.

    First, the typesetting in RFC 1628 is awful.

    Second, Maria Greene volunteered to submit a new test table for the
    group to consider.

When Chris finished her report, others identified a few items for
consideration.

1.  It was pointed out that the shutdown time should be stated in seconds.
    However, the editor cannot find where it is not already stated in 
    seconds.

2.  The spinlock was discussed further and it was concluded that we need to
    base our decision on further implementation reports.  One approach is
    to change the "must" to "should" in upsTestId.  Another approach is to
    consider deleting the spinlock altogether.

3.  The RFC should be updated to point to the new SNMPv2 documents, RFCs 1902-
    1908.

4.  It was suggested that the compliance groups should be reduced from 3 to 2
    but there was insufficient input to declare consensus on this at this time.

5.  It was suggested that upsIdentModel should be removed from the subset
    group.

6.  It was requested that the enumeration unknown(8) be added to
    upsOutputSource and it was generally agreed to by the small group in
    attendance if and only if there is text which indicates that a compliant
    agent implementation of this object cannot return unknown at all times
    and that it is considered "cheating" to return unknown(8) under all
    circumstances.

7.  One person requested that muted(3) not be required in
    upsConfigAudibleStatus for Basic and Full compliance but there were
    an insufficient number of implementers present to gauge consensus.

8.  It was agreed to clone the text from upsConfigLowBattTime into
    upsConfigLowVoltageTransferPoint and upsConfigHighVoltageTransferPoint
    to make it clear that it can be "multiple choice" from a few discrete
    values rather than requiring acceptance of any and all discrete values
    in the range.

9.  It was agreed that there needs to be a section which describes the
    relationship to other MIB documents, such as MIB-2, which should be
    supported (to serve as a reference epoch for counters, etc) as specified
    in RFC 1213 or as revised.

10.  P11 percent values ranging from 0..200 ... it was suggested that a note
     be added that states that 200 percent is intentional and is not a typo

11.  P15.  upsAlarmDescr

     We need to clarify the clarification of the use of Autonomous Type and
     either delete the clarification or copy a portion of the text from the 
     TC.

The group finished its work a few minutes before the scheduled end of the 
meeting.

Reported by Jeff Case