Subject: RE: Doubling notifications (was: RE: Comments on the Analysis of Alar m MIBs was: RE: Notifications != Alarms)

From: "Sharon Chisholm" <[email-masked]>
Date: Sun, 4 Mar 2001 13:37:34 -0500

hi

Apologies if I'm producing a mini email storm.  I'm trying
to play catch-up before sending out the compiled requirements.

-----Original Message-----
From: David T. Perkins [mailto:[email-masked]]
Sent: Thursday, March 01, 2001 3:09 PM
To: [email-masked]
Subject: Re: Doubling notifications (was: RE: Comments on the Analysis
of Alar m MIBs was: RE: Notifications != Alarms)

<clip>
<daveP>
Alarms can occur on a system without being reported. Defining faults
and the alarm conditions needs to be done without concern for how
alarms are reported to "managers".
</daveP>

<sharonC>
This statement makes me somewhat nervous.  I've also had "tree
falling in a forest" going through me head since I read it.
I think you're just looking to decouple the alarm definition
from the storage and notification mechanisms, but I'm not sure.
Reporting alarms to a manager is the only reason to have alarms
in the first place, so we want to be careful about making
this a secondary consideration.
</sharonC>

<clip>

<daveP>
What the ITU-T model does is to require that alarm conditions be
"well defined" and associate attributes with each, such as severity,
and probably cause. Since the ITU-T model is written in the CMIP
framework, it uses CMIP mechanisms to define alarms and report
them to managers.
<daveP>
<sharonC>
The biggest assumption in the ITU alarms is that the alarm is
bound to the object experiencing the alarm.  This obviously
does not apply in SNMP, and therefore represents the biggest
problem.  This can be solved several ways: domain specific
definitions (ifIndex, fanNumber, etc); entity MIB; etc.

Sharon
</sharonC>