Re: [Disman] some questions about rfc3877 (alarm mib)

["Randy Presuhn" <[e-mail]>]

Hi -

> From: "Michael Thatcher" <[e-mail]>
> To: <[e-mail]>
> Sent: Friday, December 12, 2008 10:56 AM
> Subject: [Disman] some questions about rfc3877 (alarm mib)
>

> 1. I don't understand the errata (http://www.rfc-editor.org/errata_search.php?rfc=3877)
> which says that ituPerceivedSeverity must be changed to alarmModelState.
> Why this change? Isn't this just a typo where ituPerceivedSeverity should be
> ituAlarmPerceivedSeverity?  There are multiple occurrances of
> ituPerceivedSeverity in 6.2 & 6.3 which seem to me should be
> ituAlarmPerceivedSeverity.

FWIW, I don't recall being involved in the processing of this erratum, so
take what I say with a grain of salt...

It looks like there are two things going on, and the report seems a bit
garbled.  You are correct that the occurrances of ituPerceivedSeverity
should in general be replaced with ituAlarmPerceivedSeverity.

However, the report's notes  say 
     However, ituAlarmPerceivedSeverity critical (3)
     should be mapped to alarmModelState 6
     To match the mapping shown in Section 5.4:
     alarmModelState -> ituAlarmPerceivedSeverity
            1 -> clear (1)
            2 -> indeterminate (2)
            3 -> warning (6)
            4 -> minor (5)
            5 -> major (4)
            6 -> critical (3)

I think the "mapped" refers to the steps through this particular
alarm model's state machine, *NOT* a directive "that
ituPerceivedSeverity must be changed to alarmModelState"
and is consequently a request to change the *value* of alarmModelState.
Someone would need to sit down with pencil and paper to
construct the state machine for this example to verify.

> 2. None of the examples use the index attribute alarmListName
> for objects which have this as an index, such as the value for
> ituAlarmGenericModel.  To be complete shouldn't the examples
> define an alarmListName (or use 0 as the index value indicating no name)?

By "0" I assume you mean a zero-length string, since that is
the "no name" convention for this object...  Yes, that might have
been nice, though probably not very interesting.

> 3. It's not clear to me how one matches a clear event to an
> existing active alarm so it can be removed from the active table
> and the alarmActiveIndex value used for the clear event in
> the clear table.  It's (relatively) easy if the notification and
> resource IDs are the same for the clear and current active.
> When the notification ids are different between clear and raise,
> or if there are multiple active alarms, it seems that some other
> methodology is required which I don't particularly see.
>  Any insights would be appreciated.

See example 6.1 for an example with different notification IDs.
If there are multiple active alarms, whichever one(s) have matching
clear patters will be cleared.

Randy