Re: Fw: [Technical Errata Reported] RFC3877 (1652)

I do not believe that we have concluded the discussions and reached a
resolution for this erratum. Sharon, did you ever propose a consolidated
resolution?=20

Dan
=20

> -----Original Message-----
> From: [email protected]=20
> [mailto:[email protected]] On Behalf Of Randy Presuhn
> Sent: Thursday, January 15, 2009 2:28 AM
> To: Disman
> Subject: [Disman] Fw: [Technical Errata Reported] RFC3877 (1652)
>=20
> Hi -
>=20
> fwd fyi
>=20
> Randy
>=20
> ----- Original Message -----=20
> > From: "Brian F. G. Bidulock" <[email protected]>
> > To: "Alice Hagens" <[email protected]>
> > Cc: <[email protected]>; "Dan ((Dan)) Romascanu"=20
> > <[email protected]>; "Ron Bonica" <[email protected]>;
> <[email protected]>; "RFC Errata System"=20
> <[email protected]>
> > Sent: Wednesday, January 14, 2009 1:44 PM
> > Subject: Re: [Technical Errata Reported] RFC3877 (1652)
> >
> > Alice,
> >
> > Thanks for the line breaks.  It appeared fine on the=20
> preview and when=20
> > it was submitted it swallowed them.  There was no ability to edit=20
> > after that...
> >
> > Also, the following is from GDMOs for ITU-T Rec. M.3100 (2005):
> >
> >   alarmStatus ATTRIBUTE
> >     WITH ATTRIBUTE SYNTAX ASN1DefinedTypesModule.AlarmStatus;
> >     MATCHES FOR EQUALITY;
> >     BEHAVIOUR
> >       alarmStatusBehaviour BEHAVIOUR
> >         DEFINED AS
> >           "The Alarm Status attribute type indicates the
> >            occurrence of an abnormal condition relating to an
> >            object. This attribute may also function as a summary
> >            indicator of alarm conditions associated with a
> >            specific resource. It is used to indicate the
> >            existence of an alarm condition, a pending alarm
> >            condition such as threshold situations, or (when used
> >            as a summary indicator) the highest severity of
> >            active alarm conditions. When used as a summary
> >            indicator, the order of severity (from highest to
> >            lowest) is:
> >
> >            activeReportable-Critical
> >            activeReportable-Major
> >            activeReportable-Minor
> >            activeReportable-Indeterminate
> >            activeReportable-Warning
> >            activePending
> >            cleared.";;
> >   REGISTERED AS { m3100Attribute 6 };
> >
> > --brian
> >
> > On Wed, 14 Jan 2009, Alice Hagens wrote:
> >
> > > Please note that line breaks have been added to the Original/=20
> > > Corrected text of this report, as shown below and at:
> > > http://www.rfc-editor.org/errata_search.php?rfc=3D3877&eid=3D1652
> > >
> > > Type: Technical
> > > Reported by: Brian Bidulock <[email protected]>
> > >
> > > Section: 5.4
> > >
> > > Original Text
> > > -------------
> > >
> > > alarmModelState -> ituAlarmPerceivedSeverity
> > >        1        ->         clear (1)
> > >        2        ->         indeterminate (2)
> > >        3        ->         warning (6)
> > >        4        ->         minor (5)
> > >        5        ->         major (4)
> > >        6        ->         critical (3)
> > >
> > > Corrected Text
> > > --------------
> > >
> > > alarmModelState -> ituAlarmPerceivedSeverity
> > >        1        ->         clear (1)
> > >        2        ->         warning (6)
> > >        3        ->         indeterminate (2)
> > >        4        ->         minor (5)
> > >        5        ->         major (4)
> > >        6        ->         critical (3)
> > >
> > > Notes
> > > -----
> > > alarmModelState requires that the states be defined from=20
> less severe=20
> > > to more severe; however, under ITU-T PerceivedSeverity from ITU-T=20
> > > Rec. X.721 | ISO/IEC 10165-2 "indeterminate" is more severe than=20
> > > "warning".  This change corrects the order to match the=20
> requirement=20
> > > for order of severity for alarmModelState.
> > >
> > > Thank you.
> > >
> > > RFC Editor/ah
> > >
> > > On Jan 13, 2009, at 8:23 PM, RFC Errata System wrote:
> > >
> > > >
> > > >The following errata report has been submitted for=20
> RFC3877, "Alarm=20
> > > >Management Information Base (MIB)".
> > > >
> > > >--------------------------------------
> > > >You may review the report below and at:
> > > >http://www.rfc-editor.org/errata_search.php?rfc=3D3877&eid=3D1652
> > > >
> > > >--------------------------------------
> > > >Type: Technical
> > > >Reported by: Brian Bidulock <[email protected]>
> > > >
> > > >Section: 5.4
> > > >
> > > >Original Text
> > > >-------------
> > > >alarmModelState -> ituAlarmPerceivedSeverity        1        -
> > > >>         clear (1)        2        ->         indeterminate
> > > >(2)        3        ->         warning (6)        4        -
> > > >>         minor (5)        5        ->         major (4)
> > > >6        ->         critical (3)
> > > >
> > > >Corrected Text
> > > >--------------
> > > >alarmModelState -> ituAlarmPerceivedSeverity        1        -
> > > >>         clear (1)        2        ->         warning (6)
> > > >3        ->         indeterminate (2)        4        ->
> > > >minor (5)        5        ->         major (4)        6        -
> > > >>         critical (3)
> > > >
> > > >Notes
> > > >-----
> > > >alarmModelState requires that the states be defined from less=20
> > > >severe to more severe; however, under ITU-T=20
> PerceivedSeverity from=20
> > > >ITU-T Rec. X.721 | ISO/IEC 10165-2 "indeterminate" is=20
> more severe=20
> > > >than "warning".  This change corrects the order to match the=20
> > > >requirement for order of severity for alarmModelState.
> > > >
> > > >Instructions:
> > > >-------------
> > > >This errata is currently posted as "Reported". If=20
> necessary, please=20
> > > >use "Reply All" to discuss whether it should be verified or=20
> > > >rejected. When a decision is reached, the verifying party (IESG)=20
> > > >can log in to change the status and edit the report, if=20
> necessary.
> > > >
> > > >--------------------------------------
> > > >RFC3877 (draft-ietf-disman-alarm-mib-18)
> > > >--------------------------------------
> > > >Title               : Alarm Management Information Base (MIB)
> > > >Publication Date    : September 2004
> > > >Author(s)           : S. Chisholm, D. Romascanu
> > > >Category            : PROPOSED STANDARD
> > > >Source              : Distributed Management
> > > >Area                : Operations and Management
> > > >Stream              : IETF
> > > >Verifying Party     : IESG
> >
> > --=20
> > Brian F. G. Bidulock    | The reasonable man adapts himself to the |
> > [email protected]    | world; the unreasonable one persists in  |
> > http://www.openss7.org/ | trying  to adapt the  world  to himself. |
> >                         | Therefore  all  progress  depends on the |
> >                         | unreasonable man. -- George Bernard Shaw |
>=20
>=20
>=20