[Disman] FW: [Errata Rejected] RFC3877 (1652)

"Romascanu, Dan (Dan)" <dromasca@avaya.com> Tue, 11 May 2010 12:52 UTC

Return-Path: <dromasca@avaya.com>
X-Original-To: disman@core3.amsl.com
Delivered-To: disman@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 08B8B3A6A4C for <disman@core3.amsl.com>; Tue, 11 May 2010 05:52:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.992
X-Spam-Status: No, score=-1.992 tagged_above=-999 required=5 tests=[AWL=0.607, BAYES_00=-2.599]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id g8VlK5n93WNU for <disman@core3.amsl.com>; Tue, 11 May 2010 05:52:52 -0700 (PDT)
Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (p-us1-iereast-outbound-tmp.us1.avaya.com []) by core3.amsl.com (Postfix) with ESMTP id 656493A680E for <disman@ietf.org>; Tue, 11 May 2010 05:50:36 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.53,206,1272859200"; d="scan'208";a="15343960"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 11 May 2010 06:22:55 -0400
X-IronPort-AV: E=Sophos;i="4.53,206,1272859200"; d="scan'208";a="473773589"
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([]) by co300216-co-erhwest-out.avaya.com with ESMTP; 11 May 2010 06:22:55 -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: Tue, 11 May 2010 12:22:37 +0200
Message-ID: <EDC652A26FB23C4EB6384A4584434A04021BE9DE@307622ANEX5.global.avaya.com>
Thread-Topic: [Errata Rejected] RFC3877 (1652)
Thread-Index: Acrw87IUjlSAahWfSR+FaYiFX0hqcwAACrvA
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: "Disman" <disman@ietf.org>
Subject: [Disman] FW: [Errata Rejected] 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: Tue, 11 May 2010 12:52:54 -0000


-----Original Message-----
From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] 
Sent: Tuesday, May 11, 2010 1:21 PM
To: bidulock@openss7.org; schishol@nortelnetworks.com; Romascanu, Dan
Cc: Romascanu, Dan (Dan); iesg@iesg.org; rfc-editor@rfc-editor.org
Subject: [Errata Rejected] RFC3877 (1652)

The following errata report has been rejected for RFC3877, "Alarm
Management Information Base (MIB)".

You may review the report below and at:

Status: Rejected
Type: Technical

Reported by: Brian Bidulock <bidulock@openss7.org> Date Reported:
2009-01-13 Rejected by: Dan Romascanu (IESG)

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)

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.
While the discrepancy between the documents is unfortunate, there is not
a technical requirement for the enumeration values to be identical, nor
is there a technical requirement for the labels to be identical, even
though there is obviously considerable documentation value in avoiding
gratuitous differences.

What *is* technically important is that the MIB be able to uniquely
represent all the cases from M.3100, and it accomplishes that goal.

In a future version of the document we can add an informative note
alerting implementors to the discrepancies in numbering and spelling, so
their implementations can include appropriate mapping functions to avoid
losing information.


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