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

[Mike Thatcher <[e-mail]>]

Randy Presuhn wrote:
> 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.

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?

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

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

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

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