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

From: Michael Thatcher <[email-masked]>
Date: Fri, 12 Dec 2008 10:56:33 -0800

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.

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

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.

miket

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 13 Dec 2008 10:03:24 -0800

Hi -

> From: "Michael Thatcher" <[email-masked]>
> To: <[email-masked]>
> 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

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

---

From: Mike Thatcher <[email-masked]>
Date: Sat, 13 Dec 2008 20:25:05 -0800

> construct the state machine for this example to verify.

If I understand you correctly,  what the errata is trying to say is that 
the value of alarmModelState in the example should be changed to 6 to 
correctly implement the requirements of the ituAlarmTable?

> been nice, though probably not very interesting.

yes, 0 being a zero length string and a not interesting case but at 
least accurate :)

> clear patters will be cleared.

I think you misunderstand the question. I'm looking for what determines 
the selection from the active table.  That is, given a notification 
which is a clear for some previously raised alarm, how does one find the 
row(s) in the alarmActiveTable to clear?  What exactly does one match. 
It can't always be the notificationId since they may not be the same. 
It can't be the row pointer to the alarmModel table because they are 
different between clear and alarm raise events (although they are 
different only in the last subid).  I'm assuming the resourceId has to 
be one object which matches between the clear notification and the 
row(s) the alarmActive table.  It seems to me that there has to be other 
objects used as well as part of the selection.

The other part of this question is that it seems that there could be 
multiple entries in the active table which could be selected.  Do all of 
them get cleared (i.e. moved to clear table)? Only the one with the 
highest valued alarmModelState?

mikeT

---

From: "Randy Presuhn" <[email-masked]>
Date: Sun, 14 Dec 2008 17:42:05 -0800

Hi -

> From: "Mike Thatcher" <[email-masked]>
> To: <[email-masked]>
> Sent: Saturday, December 13, 2008 8:25 PM
> Subject: Re: [Disman] some questions about rfc3877 (alarm mib)

....
> correctly implement the requirements of the ituAlarmTable?

I *think* that's what was intended.  I'd love to hear from the
document's editors.  I haven't looked at this stuff in long time.

...
> objects used as well as part of the selection.

The alarmModelIndex and extracted resource information from
the clear can be matched up with alarmActiveModelPointer
and alarmActiveResourceId to identify the row(s) of interest
from the activeAlarmTable.

> highest valued alarmModelState?

I would assume all should be cleared.  We didn't go down the path
of providing anything like CMIP-land's correlated notifications.

Randy