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

["Randy Presuhn" <[e-mail]>]

Hi -

fwd fyi

Randy

----- Original Message ----- 
> From: "Brian F. G. Bidulock" <[e-mail]>
> To: "Alice Hagens" <[e-mail]>
> Cc: <[e-mail]>; "Dan ((Dan)) Romascanu" <[e-mail]>; "Ron Bonica" <[e-mail]>;
<[e-mail]>; "RFC Errata System" <[e-mail]>
> 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 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:
>
> > Please note that line breaks have been added to the Original/
> > Corrected text of this report, as shown below and at:
> > http://www.rfc-editor.org/errata_search.php?rfc=3877&eid=1652
> >
> > Type: Technical
> > Reported by: Brian Bidulock <[e-mail]>
> >
> > 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.
> >
> > 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 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 <[e-mail]>
> > >
> > >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
>
> -- 
> Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
> [e-mail]    ¦ 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 ¦