Subject: Re: [Disman] question regarding the alarm mib

From: "Randy Presuhn" <[email-masked]>
Date: Sun, 16 Mar 2003 22:59:08 -0800

Hi -

I haven't seen a response to this query, so I've taken a stab at
it, in-line below.

Perhaps it would make sense address it  explicitly in the update
to the I-D, which we need to do anyway to address IESG concerns.
Comments?

Randy

> From: "Donald, Keith" <[email-masked]>
> To: "Disman (E-mail)" <[email-masked]>
> Sent: Wednesday, February 19, 2003 11:06 AM
> Subject: [Disman] question regarding the alarm mib
>

> 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.

I think this is *not* intended.  The description of alarmClearTable and its
columns makes it (relatively) clear that only a cleared alarm (alarmModelState
value 1) would go there.

> 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.

I believe this is the intent.  I don't see why it would be unacceptable.
If one cared about previous alarms, a log (as in RFC 3014) would seem
to be a more appropriate mechanism.

> 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?

No.

> 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?

Let's be careful with the terminology.  There would be a single "active alarm"
which would reflect the severity levels associated with the various alarms
(in the X.733 sense) processed.

> Thank you for your help,
> Keith Donald
> [email-masked]

---

From: "Donald, Keith" <[email-masked]>
Date: Wed, 19 Mar 2003 09:24:46 -0500

Randy,

Thanks for the response.  I agree a log would be an acceptable way to view
historical alarms.  Thinking back to when I wrote the email, I was concerned an
operator would want to see the state history of a single active alarm.  For
example, that high temperature went from normal->minor, minor->critical,
critical->minor, minor->clear would be the history of a single alarm that
transitioned through several states over the course of its life.

Basicially, I saw the following 'view' as most useful to the operator for
historical alarms:

      12:00 alarm 'high-temp' active, resource: my_chassis, initial state
'minor'
		1:00 alarm state changed to critical
		2:00 alarm state changed to minor
		3:00 alarm cleared

then, sometime later...

	5:00 alarm 'high-temp' active, resource: my_chassis, initial state
'critical'
		6:00 alarm cleared

This is in contrast to this view:

	12:00 alarm 'high-temp' minor active, resource: my_chassis
	1:00 alarm 'high-temp' critical active, resource: my_chassis
	2:00 alarm 'high-temp' minor active, resource: my_chassis
	3:00 alarm 'high-temp' cleared active, resource: my_chassis
	5:00 alarm 'high-temp' critical active, resource: my_chassis
	6:00 alarm 'high-temp' cleared, resource: my_chassis

In this typical 'alarm event view', it's more difficult to identify the two
alarm conditions on the resource.  I still think you need this view, but I was
confused as to how one could build the first view above without making the
relationship between an alarm and its state transitions more explicit.

As you mentioned, a log seems the best place for this.  It seems one could use
the "alarm active index" to associate an alarm with its state history in a log.
For example:

	3:00 alarm 'high-temp' active, initial state 'minor', resource:
my_chassis
		-> insert new activeAlarmTable record, assign activeIndex = n,
log...
		5:00 alarm state changed to critical
			--> update activeAlarmTable record, log and associate
state change with activeIndex == n.
		6:00 alarm cleared
			--> delete activeAlarmTable record, log and associate
state change with activeIndex == n.
	
	(or something like that...)
	
Thanks,
Keith

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]]
Sent: Monday, March 17, 2003 1:59 AM
To: Disman (E-mail)
Subject: Re: [Disman] question regarding the alarm mib

Hi -

Randy

No.