Re: another question about alarmMib..

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

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

1. The original erratum submitted by [email protected] was
reporting that the mapping=20

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

is not applied consistently in the examples.=20

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

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

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

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

I hope this helps.=20

Happy Holidays,

Dan



> -----Original Message-----
> From: [email protected]=20
> [mailto:[email protected]] On Behalf Of Randy Presuhn
> Sent: Tuesday, December 16, 2008 11:45 PM
> To: [email protected]
> Subject: Re: [Disman] another question about alarmMib..
>=20
> Hi -
>=20
> > From: "Michael Thatcher" <[email protected]>
> > To: "Randy Presuhn" <[email protected]>
> > Cc: <[email protected]>
> > Sent: Tuesday, December 16, 2008 1:19 PM
> > Subject: Re: [Disman] another question about alarmMib..
> ...
> > The description of alarmClearIndex says that "This object=20
> has the same=20
> > value as the alarmActiveIndex that this alarm instance had=20
> when it was=20
> > active".  Does this mean that clear events cannot be placed in this=20
> > table which do not have a related alarm in the alarmActiveTable?
>=20
> It sounds that way.
>=20
> > If there are multiple related entries in the=20
> alarmActiveTable, does it=20
> > matter which alarmActiveIndex value is used?
>=20
> I can't imagine why it would.  It does, however, seem to be=20
> an argument for maintaining a 1:1 correspondence, even though=20
> I doubt that that was the intent.
>=20
> It would be good to hear from the folks who have actually=20
> already implemented or deployed this MIB.
>=20
> Randy
>=20
>=20