Subject: RE: Alarm MIB WG last call

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 17 Apr 2002 11:50:57 +0300

Tammy,

I think that we are back on an already beaten track. I would suggest that we do not get back to these discussions, if we want this work to progress and eventually make it to a standard. 'Your' Alarm MIB requirements exceed the agreed scope of this work. The Alarm MIB does not assume the ARC MIB as mandatory. The T1 and ITU requirements are not mandatory as well, and the telecom applications are just one of the Alarm MIB applications. There are many other, and this is why the Alarm MIB architecture is modular, and allows to accommodate different type of requirements. The core Alarm MIB needs to be kept simple. 

Regards,

Dan

> -----Original Message-----
> From: Tammy Ferris [mailto:[email-masked]]
> Sent: Tuesday, April 16, 2002 5:15 PM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]
> Subject: Re: Alarm MIB WG last call
> 
> 
> 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
> 
> "Romascanu, Dan (Dan)" wrote:
> 
> > 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: Wed, 17 Apr 2002 10:13:47 -0500

Dan,

Your response here really surprises me!  If this Alarm MIB work disregards ITU requirements than why are there so many e-mails discussing support for ITU alarm codes?  Just forget about that then and make up your own.

I never have pushed to make the ARC MIB mandatory.   But, I believe if an application requires both the ARC MIB and the Alarm MIB then the addition of the ARC MIB should not break the Alarm MIB.  The way the Alarm MIB is designed currently, addition of the ARC MIB breaks it.

I proposed a fix of having 2 timestamps in the active alarm table rather than one :  One time stamp (the time the alarm was reported) be the one to use for indexing and a second time stamp (the time the error occured).

Maybe there is another way to fix this by using different attributes for indexing?  I don't know.  I haven't studied that.

I think that there is fine line between simplicity and stupidity.  While I agree that unecessary bells and whistles should be avoided to allow for a broader application base, this should not be acheived at the expense of MIB integrity.

Tammy

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