Subject: RE: Alarm terminology, part 2 (was: terminology clarification)(wa s: Proposed disman charter addition: alarm tracking)(was: other stuff)

From: "Sharon Chisholm" <[email-masked]>
Date: Fri, 5 Jan 2001 10:04:13 -0500

hi

I've removed my old comments, so <SharonC> is new stuff.

-----Original Message-----
From: Ayers, Mike [mailto:[email-masked]]
Sent: Thursday, January 04, 2001 6:53 PM
To: [email-masked]'
Subject: Alarm terminology, part 2 (was: terminology clarification)(was:
Proposed disman charter addition: alarm tracking)(was: other stuff)

<clip>
<MikeA>

	I partially agree.  Certainly a ringing bell is not a fire, but a
ringing bell is not a transient condition either.  May I propose some
definitions:

	fault - a persistent error or warning condition.

	alarm - the propogation of information concerning a fault.  An alarm
is a pure information object.  There are two processes (and their inverses)
of interest for an alarm - activation and realization.

	activation - the process of fault detection, information gathering,
and information propogation.

	realization - the receipt of the complete set of information of an
alarm.

</MikeA>

<SharonC> 
I think the definition of alarm needs to include some concept
that it is persistent so long as the fault is occurring.  The fire alarm
does not stop ringing until the fire is out.  The error light on the 
switch does not go off until the condition has been corrected. Obviously 
we don't send out a constant stream of notifications, but just at the
start and stop of the alarm.  I thought David's definition worked from
this perspective.
</SharonC>

<clip>

5.  ALARMS AND NOTIFICATIONS

<MikeA>

	In its current form, the Active Alarm MIB appears to realize alarms
from notifications.  This method probably supports many existing
deployments, and is quite practical.  Several contributors have also seen
alarms as defined by their edge notifications.  However, I do not see this
as the only possible way to realize alarms.  It should be possible for a
device to populate its alarm MIB without notifications, since there are
management environments in which notifications over the wire are
undesirable, and requiring notifications for alarms in devices designed for
such environments is just hoop-jumping.  I am pressing for the decoupling of
alarms and notifications, even though I am well aware that in practice they
will almost inevitably work together.

</MikeA>

<SharonC>
Well, all that is actually required is the definition of the notification
in SMI.  There is nothing in the MIB that technically requires the
notification
to be sent. 
</SharonC>
6.  DEFINING ALARMS

<MikeA>

	The Active Alarm MIB currently uses the AlarmDetailsTable to
describe what notifications are perceived as alarms, but does not permit
this table to be configured.  I fail to see any reason not to allow
configuration of this table.

</MikeA>

<SharonC>
Well, I think the reason I didn't make this configurable, is I was trying
to make the device the master source for information. If this 
information is configurable you run the risk of the device and
the middle manager having very different alarm lists for the same device.
This is probably not a good enough reason to not make it configurable
though.

Plus, today, the manager is often in charge of defining what is an alarm
and the raise/clear relationship, since many devices can't do it. It
probably 
makes sense to allow the manager to configure these objects.
</SharonC>

Sharon

---

From: "Ayers, Mike" <[email-masked]>
Date: Fri, 5 Jan 2001 12:07:29 -0600

New stuff marked as <MikeA2>

<clip>
<MikeA>

	I partially agree.  Certainly a ringing bell is not a
fire, but a
ringing bell is not a transient condition either.  May I propose some
definitions:

	alarm - the propogation of information concerning a
fault.  An alarm
is a pure information object.  There are two processes (and
their inverses)
of interest for an alarm - activation and realization.

	activation - the process of fault detection,
information gathering,
and information propogation.

	realization - the receipt of the complete set of
information of an
alarm.

</MikeA>

<SharonC>
I think the definition of alarm needs to include some concept
that it is persistent so long as the fault is occurring.  The
fire alarm
does not stop ringing until the fire is out.  The error light on the
switch does not go off until the condition has been
corrected. Obviously
we don't send out a constant stream of notifications, but just at the
start and stop of the alarm.  I thought David's definition worked from
this perspective.
</SharonC>
<MikeA2>

	Actually, that's what I wanted, but upon rereading, I clearly didn't
state that.  How about:

	alarm - the set of information concerning a fault, active while the
fault exists.  An alarm is a pure information object.  There are two
processes (and their inverses) of interest for an alarm - activation and
realization.  An alarm is activated when the fault detection subsystem of a
device detects a fault for which an alarm is configured.  The alarm is
realized at any level (e.g. device, manager station, console operator) when
its full set of information (or subset of information considered to be of
interest at that level) has been gathered and processed at that level.
Deactivation and unrealization work in the same fashion, so that for the
lifespan of any fault/alarm pair, there are five stages:
inactive/unrealized, active/unrealized, active/realized, inactive/realized,
inactive/unrealized.  Note that "unrealized" has the double meaning "not yet
realized" and "removed from realization" - does anyone find this confusing?

</MikeA2>
<clip>

<MikeA>

	In its current form, the Active Alarm MIB appears to
realize alarms
from notifications.  This method probably supports many existing
deployments, and is quite practical.  Several contributors
have also seen
alarms as defined by their edge notifications.  However, I do
not see this
as the only possible way to realize alarms.  It should be
possible for a
device to populate its alarm MIB without notifications, since
there are
management environments in which notifications over the wire are
undesirable, and requiring notifications for alarms in
devices designed for
such environments is just hoop-jumping.  I am pressing for
the decoupling of
alarms and notifications, even though I am well aware that in
practice they
will almost inevitably work together.

</MikeA>

<SharonC>
Well, all that is actually required is the definition of the
notification
in SMI.  There is nothing in the MIB that technically requires the
notification
to be sent.
</SharonC>
<MikeA2>

	Sounds good, but I'd like explicit text that states that
notifications need not be sent for a self-sourced alarm MIB, since there is
too much potential for confusion.

</MikeA2>

6.  DEFINING ALARMS

<MikeA>

	The Active Alarm MIB currently uses the AlarmDetailsTable to
describe what notifications are perceived as alarms, but does
not permit
this table to be configured.  I fail to see any reason not to allow
configuration of this table.

</MikeA>

<SharonC>
Well, I think the reason I didn't make this configurable, is
I was trying
to make the device the master source for information. If this
information is configurable you run the risk of the device and
the middle manager having very different alarm lists for the
same device.
This is probably not a good enough reason to not make it configurable
though.

Plus, today, the manager is often in charge of defining what
is an alarm
and the raise/clear relationship, since many devices can't do it. It
probably
makes sense to allow the manager to configure these objects.
</SharonC>
<MikeA2>

	In any case, we've got VACM and USM, so we can let the
administrators decide3 whether they want their alarm MIBs configurable.

</MikeA2>