Subject: [Disman] another question about alarmMib..

From: Michael Thatcher <[email-masked]>
Date: Mon, 15 Dec 2008 14:05:06 -0800

the alarmActiveTable is indexed by alarmListName, alarmDataAndTime, 
alarmActiveIndex

the alarmActiveVariableTable is indexed by alarmListName, 
alarmActiveIndex, alarmActiveVariableIndex.

How come alarmDataAndTime are not an index into the 
alarmActiveVariableTable, since this table by definition has the varbind 
objects from the corresponding entry in alarmActiveTable?

This also seems to imply that alarmActiveIndex is always unique 
regardless of alarmDataAndTime.  Is this intentional?

miket

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 16 Dec 2008 11:08:37 -0800

Hi -

> From: "Michael Thatcher" <[email-masked]>
> To: <[email-masked]>
> Sent: Monday, December 15, 2008 2:05 PM
> Subject: [Disman] another question about alarmMib..
>

Yes.  This should make it clear why alarmDateAndTime is needed
for the alarmActiveTable (it supports the ordering required for the
most common use cases) and not for the alarmActiveVariableTable
(these are meaningful only in the context of the alarm "containing"
these variables, and a time stamp is not needed to provide uniqueness.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 16 Dec 2008 13:44:55 -0800

Hi -

> To: "Randy Presuhn" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Tuesday, December 16, 2008 1:19 PM
> Subject: Re: [Disman] another question about alarmMib..
...
> The description of alarmClearIndex says that "This object
> has the same value as the alarmActiveIndex that this alarm
> instance had when it was active".  Does this mean that
> clear events cannot be placed in this table which do not
> have a related alarm in the alarmActiveTable?

It sounds that way.

> If there are multiple related entries in the alarmActiveTable,
> does it matter which alarmActiveIndex value is used?  

I can't imagine why it would.  It does, however, seem to be
an argument for maintaining a 1:1 correspondence, even
though I doubt that that was the intent.

It would be good to hear from the folks who have actually
already implemented or deployed this MIB.

Randy

---

From: Michael Thatcher <[email-masked]>
Date: Tue, 16 Dec 2008 13:19:56 -0800

Randy Presuhn wrote:

Hi -

The description of alarmClearIndex says that
"This object has the same value as the alarmActiveIndex that this alarm
instance had when it was active".  Does this mean that clear events
cannot be placed in this table which do not have a related alarm in the
alarmActiveTable?  If there are multiple related entries in the
alarmActiveTable, does it matter which alarmActiveIndex value is used?

mikeT

---

From: Michael Thatcher <[email-masked]>
Date: Tue, 16 Dec 2008 14:52:56 -0800

Randy Presuhn wrote:

Hi -

...

It sounds that way.

I have been hoping for some insight from someone who has implemented
this mib.

mikeT

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 22 Dec 2008 17:38:25 -0800

Hi -

> Sent: Tuesday, December 16, 2008 2:52 PM
...
> I have been hoping for some insight from someone who has implemented this mib.

Any word yet, or is everyone busy celebrating their respective holidays?

Randy

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 23 Dec 2008 16:00:12 +0100

Hi,

Thanks to Michael for catching an d reporting this. I apologize for the
late response. All excuses related to a busy end of the year and a
holiday season that already begun in some legislations apply. 

There is a problem with this erratum and with the document itself. There
are actually two problems. 

1. The original erratum submitted by [email-masked] was
reporting that the mapping 

     alarmModelState -> ituAlarmPerceivedSeverity
            1 -> clear (1)
            2 -> indeterminate (2)
            3 -> warning (6)
            4 -> minor (5)
            5 -> major (4)
            6 -> critical (3) 

is not applied consistently in the examples. 

This is correct, and we acknowledged this problem. The RFC Editor
however inserted a different resolution in the RFC Errata that was
published. 

Right now I see such problems in the examples in 6.1 to 6.3. 

2. In examples 6.2 and 6.3 ituPerceivedSeverity is used instead of
ituAlarmPerceivedSeverity

My proposal is to issue a new erratum to correct the above and to ask
the RFC Editor to cancel or reject the current erratum. 

With everybody's permission we shall do this in the first few weeks of
the new year. 

I hope this helps. 

Happy Holidays,

Dan

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Randy Presuhn
> Sent: Tuesday, December 16, 2008 11:45 PM
> To: [email-masked]
> has the same 
> > value as the alarmActiveIndex that this alarm instance had 
> when it was 
> > active".  Does this mean that clear events cannot be placed in this 
> > table which do not have a related alarm in the alarmActiveTable?
> 
> It sounds that way.
> 
> > If there are multiple related entries in the 
> alarmActiveTable, does it 
> > matter which alarmActiveIndex value is used?
> 
> an argument for maintaining a 1:1 correspondence, even though 
> I doubt that that was the intent.
>

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 23 Dec 2008 11:22:24 -0800

Hi -

Dan's suggestion makes sense to me.

Randy

----- Original Message ----- 
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "Randy Presuhn" <[email-masked]>; <[email-masked]>
Sent: Tuesday, December 23, 2008 7:00 AM
Subject: RE: [Disman] another question about alarmMib..

Hi,

I hope this helps. 

Happy Holidays,

Dan