Subject: [Disman] Fw: [Technical Errata Reported] RFC3877 (1652)

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 13 Jan 2009 21:59:41 -0800

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-masked]>
> To: <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> 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-masked]>
>
> 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

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 14 Jan 2009 11:52:14 -0800

Hi -

More errata.  I don't know why this is not being automatically sent
to the old WG mailing list.

Randy

> From: "Alice Hagens" <[email-masked]>
> To: <[email-masked]>; "Dan ((Dan)) Romascanu" <[email-masked]>; "Ron Bonica" <[email-masked]>;
> Cc: <[email-masked]>; "RFC Errata System" <[email-masked]>
> Sent: Wednesday, January 14, 2009 9:49 AM
> Subject: Re: [Technical Errata Reported] RFC3877 (1652)
>
> Please note that line breaks have been added to the Original/
> Corrected text of this report, as shown below and at:
> 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.
>
> Thank you.
>
> RFC Editor/ah
>
> On Jan 13, 2009, at 8:23 PM, RFC Errata System wrote:
>
> >
> > 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

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 14 Jan 2009 16:27:54 -0800

Hi -

fwd fyi

Randy

----- Original Message ----- 
> From: "Brian F. G. Bidulock" <[email-masked]>
> To: "Alice Hagens" <[email-masked]>
> Cc: <[email-masked]>; "Dan ((Dan)) Romascanu" <[email-masked]>; "Ron Bonica" <[email-masked]>;
<[email-masked]>; "RFC Errata System" <[email-masked]>
> Sent: Wednesday, January 14, 2009 1:44 PM
> Alice,
> Thanks for the line breaks.  It appeared fine on the preview
> and when it was submitted it swallowed them.  There was no
> ability to edit 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:
>
> -- 
> Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
> [email-masked]    ¦ 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 ¦