Fw: [Technical Errata Reported] RFC3877 (1652)

"Randy Presuhn" <[email protected]> Tue, 13 Jan 2009 21:59:41 -0800
Newsgroups gmane.ietf.disman
Message-ID <003101c9760d$4b879940$6801a8c0@oemcomputer>
Hi -

I'm not sure why this didn't automatically go to the disman mailing
list, but here it is.  Comments?

Randy

----- Original Message ----- 
> From: "RFC Errata System" <[email protected]>
> To: <[email protected]>; <[email protected]>; <[email protected]>; <[email protected]>;
<[email protected]>
> Cc: <[email protected]>; <[email protected]>
> Sent: Tuesday, January 13, 2009 8:23 PM
> Subject: [Technical Errata Reported] RFC3877 (1652)
>
>
> The following errata report has been submitted for RFC3877,
> "Alarm Management Information Base (MIB)".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=3877&eid=1652
>
> --------------------------------------
> 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 severe to more severe; however, under ITU-T PerceivedSeverity from
ITU-T Rec. X.721 | ISO/IEC 10165-2 "indeterminate" is more severe than "warning".  This change corrects the order to match the
requirement for order of severity for alarmModelState.
>
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if 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