Subject: Re: Alarm MIB WG last call

From: Randy Presuhn <[email-masked]>
Date: Tue, 2 Apr 2002 17:35:14 -0800 (PST)

Hi -

Private email has made it clear that some folks didn't read the
attached message.  Make no mistake:  disman WG last call on the
alarm MIB began March 28 when the draft appeared.  The WG last
call will end 5 p.m. Pacific Daylight Time on April 11, 2002.

 ------------------------------------------------------
 Randy Presuhn          BMC Software, Inc.  1-3141
 [email-masked]  2141 North First Street
 Tel: +1 408 546-1006   San José, California 95131  USA
 ------------------------------------------------------
 My opinions and BMC's are independent variables.
 ------------------------------------------------------

> From [email-masked] Mon Mar 18 13:08:39 PST 2002
> Date: Mon, 18 Mar 2002 13:08:17 -0800 (PST)
> From: Randy Presuhn <rpresuhn>
> Message-Id: <[email-masked]>
> To: [email-masked]
> Subject: Alarm MIB WG last call
> List-Id: IETF disman Working Group mailing list <disman.dorothy.bmc.com>
> 
> Hi -
> 
> We finished a first WG last call on the alarm MIB, and,
> *surprise* found that some revisions were needed.  I've talked
> to some of the folks active in the discussion, and as disman
> WG chair have decided that, when the revision appears, another
> two-week WG last call on the document would be appropriate.
> This last call will begin when the revised I-D becomes available.
> 
> As with the previous last call, I would appreciate a (personal)
> note from those who have read the document but not felt the
> need to comment on the WG mailing list, so that I might better
> assess how much review it has actually received.
> 
>  ------------------------------------------------------
>  Randy Presuhn          BMC Software, Inc.  1-3141
>  [email-masked]  2141 North First Street
>  Tel: +1 408 546-1006   San José, California 95131  USA
>  ------------------------------------------------------
>  My opinions and BMC's are independent variables.
>  ------------------------------------------------------
>

---

From: "David T. Perkins" <[email-masked]>
Date: Tue, 02 Apr 2002 17:57:00 -0800

HI,

The I-D still depends of RFC 3014. Steve Mouton and I plus RamK and
implementor at cisco and implementor at Riverstone are looking into
RFC 3014 and have found problems. Steve Mouton and I are working on
a replacement MIB module to 3014. This replacement MIB module could
result in the I-D being broken in its usage of RFC 3014. Note the
reference in the I-D to RFC 3014 is not simply as an example.
Hint: see the definition of object alarmListName.

So, until the I-D is purged of references to RFC 3014, I find it
inappropriate for it to be forwarded by the WG to the IESG for
consideration as publication as an RFC.

Regards,
/david t. perkins

---

From: [email-masked]
Date: Thu, 11 Apr 2002 22:15:58 +0000 (GMT)

Is alarmActiveSpecificPointer really intended to be
"read-write" or should it be "read-only"?

Reva Bailey

---

From: Tammy Ferris <[email-masked]>
Date: Fri, 12 Apr 2002 15:59:59 -0500

All,
Found another item.  For clarity, I think the following definition:
   alarmActiveDateAndTime OBJECT-TYPE
      SYNTAX      DateAndTime
      MAX-ACCESS  not-accessible
      STATUS      current
      DESCRIPTION
          "The local date and time when the alarm occurred.

          Implementations MUST include the offset from UTC,
          if available.  Implementation in environments in which
          the UTC offset is not available is NOT RECOMMENDED."
      ::= { alarmActiveEntry 2 }

Should be modified to:
   alarmActiveDateAndTime OBJECT-TYPE
      SYNTAX      DateAndTime
      MAX-ACCESS  not-accessible
      STATUS      current
      DESCRIPTION
          "The local date and time when the error occurred.

          Implementations MUST include the offset from UTC,
          if available.  Implementation in environments in which
          the UTC offset is not available is NOT RECOMMENDED."
      ::= { alarmActiveEntry 2 }

Of course, I would not object to two time stamps.  One for the time the error
occurred and another for the time an alarm was reported.
Cheers,
Tammy

Tammy Lehtinen Ferris
[email-masked]
+1 (763)577-5946
Merkita Incorporated
www.merkita.com

---

From: Tammy Ferris <[email-masked]>
Date: Mon, 15 Apr 2002 09:14:07 -0500

All,
I ran across a perceived anomaly related to the first item in one of my previous
mail that I thought would be relevant to point out.

It was explained to me that the table for active alarms is indexed based on time
the error occurred, which allows the manager the ability to not have to retrieve
the whole table all the time but can just query on the "most recent" alarms.

This appears to work fine in the nominal case, however the addition of alarm
suppression feature creates an anomaly using that approach.

If an error occurs while alarm reporting is suppressed and still exists when
alarm reporting is no longer suppressed, the alarm will be reported at the time
the suppression is released but the time stamp will indicate the time the error
occurred not the time the error is reported (as it should be).  Thus, when
supporting both the alarm mib and the arc mib, there is the possibility that
"new" alarms could show up in the active alarm table with time stamps older
(having earlier time stamps) than any other alarm in the active alarm table.

One solution to this, though expensive, would be to have 2 timestamps in the
active alarm table: one for the time the error occured and the other for the
time the alarm notification was sent.

Regards,
Tammy

Tammy Lehtinen Ferris
[email-masked]
+1 (763)577-5946
Merkita Incorporated
www.merkita.com