FW: [Errata Rejected] RFC3877 (1652)

=20

-----Original Message-----
From: RFC Errata System [mailto:[email protected]]=20
Sent: Tuesday, May 11, 2010 1:21 PM
To: [email protected]; [email protected]; Romascanu, Dan
(Dan)
Cc: Romascanu, Dan (Dan); [email protected]; [email protected]
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:
http://www.rfc-editor.org/errata_search.php?rfc=3D3877&eid=3D1652

--------------------------------------
Status: Rejected
Type: Technical

Reported by: Brian Bidulock <[email protected]> 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)

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.
 --VERIFIER NOTES--
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.

  =20

--------------------------------------
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