Subject: RE: Alarm MIB WG last call

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 16 Apr 2002 14:35:59 +0300

You are correct in the analysis of the behavior. However, I think that this is how it should work. 

Assuming that an alarm suppression mechanism is supported you seem to make assumptions about how it should work - timestamps of when the error occurred are somehow kept internally. This is an implementation assumption. What if in another implementation, polling an error conditions starts only after the suppression is released.

Actually Alarm suppression is not part of the scope of the Alarm MIB. Model Specific Alarm MIBs may add such mechanisms, and document the behavior. 

Regards,

Dan

> -----Original Message-----
> From: Tammy Ferris [mailto:[email-masked]]
> Sent: Monday, April 15, 2002 5:14 PM
> Cc: [email-masked]
> Subject: Re: Alarm MIB WG last call
> 
> 
> 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
> 
> 
> >
> > >
> > > 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: Tammy Ferris <[email-masked]>
Date: Tue, 16 Apr 2002 09:14:36 -0500

Dan,
While the ARC MIB is a separate MIB, it was my understanding that it should work together with this Alarm MIB in a compatible fashion and that they both (and possibly other MIBs as well --- such as a Conditions MIB (or should I say Error MIB)) fell under the topic of Alarm Management.

I certainly don't see the Alarm MIB as sufficient to meet my Alarm Management requirements.  However, with the addition of other MIBs, it should hopefully be close enough (It will always lack some of the ad hoc capabilities I have in using other protocols.).

Some implementations may do polling but that would violate the T1 and ITU requirements and not be acceptable for telecommunications applications.  So, while some may do polling, there are definitely some that will not.  Further, polling makes for poor analysis because the receiver of the alarm information, without a valid time
stamp, cannot correlate the occurrence of the error with any other activities that were occurring at the time the error occurred.

Philosophically, I think it would be better to have no time stamp than an incorrect one with no indication that it is incorrect.  But again, an elimination of the time stamp would not meet my requirements.
Regards,
Tammy

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