Subject: [Disman] question regarding the alarm mib

From: "Donald, Keith" <[email-masked]>
Date: Wed, 19 Feb 2003 14:06:05 -0500

I have a question regarding a semantic of the alarm mib that I can't find
directly discussed in the RFC:

What is the expected behaivior when an active alarm transitions to another
active state? (as opposed to a clear state.)  I see a couple of different
possibilities and was wondering which one is the right one:

	1. The previously active state is moved to the "cleared" alarm table to
note it as a "historical" alarm.  The new active state is added to the
activeAlarm table.
		- The problem with this approach is it looks like their are two
different alarms (and one has cleared), when in reality there is only one alarm
that has transitioned from one active state to another over the course of its
life.

	2. The new active alarm state simply "replaces" the previously active
alarm state in the alarmActive table.
		- The problem here is you lose information about the previous
alarm state.  This option seems unacceptable.

	3. The new active alarm state replaces the previous state, and the
previous state is added as a "historical" state for that active alarm instance.
		- This seems like the best solution, but is this supported by
the current model?

Here is an example of what I mean:

Suppose a simple "Temperature" alarm model exists and has states of:
	Temperature Normal (clear)
	Temperature Minor
	Temperature Major
	Temperature Critical

When a "Temperature Minor" alarm condition is detected, the alarm is added to
the activeAlarm table and any triggering event information is associated with
it.  What happens when if the alarm transitions from Minor to Major, or from
Minor to Critical?  Should one activeAlarm instance track these state
transitions explicitly over the course of its life?  Or is each state transition
viewed as a separate alarm?

Thank you for your help,

Keith Donald
[email-masked]