Subject: RE: Updated Alarm MIBs Requirements

From: "Ayers, Mike" <[email-masked]>
Date: Fri, 30 Mar 2001 12:54:58 -0600

> From: Tammy Ferris [mailto:[email-masked]]
> 
> This statement and the requirements definitions do not
> reflect our discussions
> regarding alarms that are not persistent.  Did I miss
> something about a decision
> not to send alarm notifications for alarmed conditions that
> did not persist?  I
> see this discussed regarding Conditions but not Alarms. 
> Does this group feel
> that conditions such as security violations, for example
> invalid login attempt,
> which have no duration are not possible alarms?  Or are you
> expecting to send a
> raise  immediately following by a clear and add a row and
> immediately remove a
> row from the active alarm table?
> 

	I would expect a raise with no clear.  That is, such an alarm should
be administratively (by hand) cleared.  Another way to look at it is that
the intrusion attempt is the alarm trigger, but the alarm is an unhandled
intrusion attempt. We should, I think, verify that our models support such
alarms.

/|/|ike