Subject: RE: Some Notes from Alarm Discussions

From: Dan Romascanu <[email-masked]>
Date: Tue, 27 Mar 2001 12:03:06 +0200

Hi,

Are 'conditions that are not alarmed' part of the scope of the Alarm MIB?

I think that they are not. My reluctant agreement to support conditions is
based to the fact that looking at conditions on the Alarm MIB interface
helps to understand what is the subsystem source, location, etc. of a
current pending alarm.
 
I do not think that everybody agrees with this. 

Regards,

Dan

> -----Original Message-----
> From:	Tammy Ferris [SMTP:[email-masked]]
> Sent:	Tue March 27 2001 1:04
> To:	Sharon Chisholm
> Cc:	[email-masked]
> Subject:	Re: Some Notes from Alarm Discussions
> 
> 
> Sharon,
> 
> Per your statement:
> Conditions include non-alarm information and are not
> persistent for the duration of the problem.
> 
> I thought we agreed to:
> Conditions include conditions that are not alarmed.  Conditions,
> independent of whether or not they are alarmed, may or may not be
> persistent (some models use the term standing conditions for persistent
> conditions).  Often transient conditions that are alarmed conditions will
> not be explicitly cleared (no clear notification is sent).  As long as
> the condition persists, it is visable over the management interface via a
> query of the active conditions table.
> 
> Tammy
> 
>

---

From: Tammy Ferris <[email-masked]>
Date: Tue, 27 Mar 2001 10:16:16 -0600

Dan,
I would like to know why you think conditions are not part of this scope of
work.

I think they are for at least the following reasons:
1) Any condition that is not alarmed now may be alarmed later and vice verse.
2) I think that, after our discussions, the term alarm included condition in
several peoples minds from the beginning it is just that people were applying
different meaning to the term alarm.
3) It makes no sense to ARC on active alarms as we have sliced and diced it.
Tammy