Re: [Disman] Fw: [Technical Errata Reported] RFC3877 (1652)
"Romascanu, Dan (Dan)" <dromasca@avaya.com> Wed, 09 September 2009 15:59 UTC
Return-Path: <dromasca@avaya.com>
X-Original-To: disman@core3.amsl.com
Delivered-To: disman@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20A1C28C481 for <disman@core3.amsl.com>; Wed, 9 Sep 2009 08:59:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.443
X-Spam-Level:
X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8oIZjfDs07g for <disman@core3.amsl.com>; Wed, 9 Sep 2009 08:59:34 -0700 (PDT)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id C58653A67D8 for <disman@ietf.org>; Wed, 9 Sep 2009 08:59:34 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.44,359,1249272000"; d="scan'208";a="182733105"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 09 Sep 2009 12:00:07 -0400
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-erhwest-out.avaya.com with ESMTP; 09 Sep 2009 12:00:06 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 09 Sep 2009 17:59:56 +0200
Message-ID: <EDC652A26FB23C4EB6384A4584434A0401A0C09C@307622ANEX5.global.avaya.com>
In-Reply-To: <000401c976a8$1c4c1020$6801a8c0@oemcomputer>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Disman] Fw: [Technical Errata Reported] RFC3877 (1652)
thread-index: Acl2p7fFku98zSnWSAKeeRftcUO2sS6vfc1A
References: <000401c976a8$1c4c1020$6801a8c0@oemcomputer>
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: Randy Presuhn <randy_presuhn@mindspring.com>, Disman <disman@ietf.org>, schishol@nortelnetworks.com
Subject: Re: [Disman] Fw: [Technical Errata Reported] RFC3877 (1652)
X-BeenThere: disman@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Distributed Management <disman.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/disman>, <mailto:disman-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/disman>
List-Post: <mailto:disman@ietf.org>
List-Help: <mailto:disman-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/disman>, <mailto:disman-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Sep 2009 15:59:36 -0000
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? Dan > -----Original Message----- > From: disman-bounces@ietf.org > [mailto:disman-bounces@ietf.org] On Behalf Of Randy Presuhn > Sent: Thursday, January 15, 2009 2:28 AM > To: Disman > Subject: [Disman] Fw: [Technical Errata Reported] RFC3877 (1652) > > Hi - > > fwd fyi > > Randy > > ----- Original Message ----- > > From: "Brian F. G. Bidulock" <bidulock@openss7.org> > > To: "Alice Hagens" <hagens@ISI.EDU> > > Cc: <schishol@nortelnetworks.com>; "Dan ((Dan)) Romascanu" > > <dromasca@avaya.com>; "Ron Bonica" <rbonica@juniper.net>; > <randy_presuhn@mindspring.com>; "RFC Errata System" > <rfc-editor@rfc-editor.org> > > 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 <bidulock@openss7.org> > > > > > > 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 <bidulock@openss7.org> > > > > > > > >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 | > > bidulock@openss7.org | 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 | > > >
- [Disman] Fw: [Technical Errata Reported] RFC3877 … Randy Presuhn
- Re: [Disman] [Technical Errata Reported] RFC3877 … Randy Presuhn
- [Disman] Fw: [Technical Errata Reported] RFC3877 … Randy Presuhn
- [Disman] RFC 3877 errata Randy Presuhn
- Re: [Disman] RFC 3877 errata Romascanu, Dan (Dan)
- Re: [Disman] RFC 3877 errata Sharon Chisholm
- Re: [Disman] RFC 3877 errata Romascanu, Dan (Dan)
- Re: [Disman] RFC 3877 errata Michael Thatcher
- Re: [Disman] Fw: [Technical Errata Reported] RFC3… Romascanu, Dan (Dan)
- [Disman] FW: [Errata Rejected] RFC3877 (1652) Romascanu, Dan (Dan)
- Re: [Disman] [Errata Rejected] RFC3877 (1652) Romascanu, Dan (Dan)
- Re: [Disman] [Errata Rejected] RFC3877 (1652) Brian F. G. Bidulock
- Re: [Disman] [Errata Rejected] RFC3877 (1652) Randy Presuhn
- Re: [Disman] [Errata Rejected] RFC3877 (1652) Brian F. G. Bidulock
- Re: [Disman] [Errata Rejected] RFC3877 (1652) Randy Presuhn
- Re: [Disman] [Errata Rejected] RFC3877 (1652) Romascanu, Dan (Dan)
- Re: [Disman] [Errata Rejected] RFC3877 (1652) Romascanu, Dan (Dan)
- Re: [Disman] [Errata Rejected] RFC3877 (1652) Brian F. G. Bidulock
- Re: [Disman] [Errata Rejected] RFC3877 (1652) Brian F. G. Bidulock
- Re: [Disman] [Errata Rejected] RFC3877 (1652) Randy Presuhn
- Re: [Disman] [Errata Rejected] RFC3877 (1652) Romascanu, Dan (Dan)