Re: some questions about rfc3877 (alarm mib)

Hi -

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


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

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.

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

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

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

Randy