RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 3 records.

Status: Verified (1)

RFC 3877, "Alarm Management Information Base (MIB)", September 2004

Source of RFC: disman (ops)

Errata ID: 219
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Andreas Politze
Date Reported: 2005-08-08

Section 6.3 says:

ituAlarmPerceivedSeverity        critical (3)

It should say:

alarmModelState                  3

Notes:


However,
ituAlarmPerceivedSeverity critical (3)
should be mapped to
alarmModelState 6
To match the mapping shown in Section 5.4:
alarmModelState -> ituAlarmPerceivedSeverity
1 -> clear (1)
2 -> indeterminate (2)
3 -> warning (6)
4 -> minor (5)
5 -> major (4)
6 -> critical (3)

Status: Held for Document Update (1)

RFC 3877, "Alarm Management Information Base (MIB)", September 2004

Source of RFC: disman (ops)

Errata ID: 1819
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Enda Murphy
Date Reported: 2009-07-29
Held for Document Update by: Dan Romascanu

Section 5.2 says:

    -- The following are used with Processing error alarm.
                storageCapacityProblem (151),
                memoryMismatch  (152),
                corruptData  (153),
                outOfCPUCycles   (154),
                sfwrEnvironmentProblem  (155),
                sfwrDownloadFailure  (156),
                lossOfRealTimel (157),
    --A processing error alarm to be issued after the system has
    --reinitialised. This will indicate
    --to the management systems that the view they have of the managed
    --system may no longer
    --be valid. Usage example: The managed
    --system issues this alarm after a reinitialization with severity
    --warning to inform the
    --management system about the event. No clearing notification will
    --be sent.
                applicationSubsystemFailure (158),
                configurationOrCustomisationError (159),
                databaseInconsistency (160),
                fileError (161),
                outOfMemory (162),
                softwareError (163),
                timeoutExpired (164),
                underlayingResourceUnavailable (165),
                versionMismatch (166),
    --Values 168-200 are reserved for processing error alarm related
    -- probable causes.

It should say:

    -- The following are used with Processing error alarm.
                storageCapacityProblem (151),
                memoryMismatch  (152),
                corruptData  (153),
                outOfCPUCycles   (154),
                sfwrEnvironmentProblem  (155),
                sfwrDownloadFailure  (156),
                lossOfRealTime (157),
-- A processing error alarm to be issued if the system detects that it has lost the time in
-- the real time clock but  the clock itself is working. This could happen e.g. during a power 
-- cut in a small NE which does not have battery backup for the real time clock.
                reinitialized (158),
    --A processing error alarm to be issued after the system has
    --reinitialised. This will indicate
    --to the management systems that the view they have of the managed
    --system may no longer
    --be valid. Usage example: The managed
    --system issues this alarm after a reinitialization with severity
    --warning to inform the
    --management system about the event. No clearing notification will
    --be sent.
                applicationSubsystemFailure (159),
                configurationOrCustomisationError (160),
                databaseInconsistency (161),
                fileError (162),
                outOfMemory (163),
                softwareError (164),
                timeoutExpired (165),
                underlayingResourceUnavailable (166),
                versionMismatch (167),
    --Values 168-200 are reserved for processing error alarm related
    -- probable causes.

Notes:

It seems to be a copy/paste error from the M.3100 Standard PC text. The comment in the MIB after "lossOfRealTimel" (Note also rogue "l" at the end!) clearly refers to the PC string "reinitialized" instead. It is strange how the integers have continued on from 158 instead of retaining the original values, but anyway, it appears to be a mismatch between the two standards. Ironically I noticed it when I saw that "versionMismatch" had different values (166 and 167).

Status: Rejected (1)

RFC 3877, "Alarm Management Information Base (MIB)", September 2004

Source of RFC: disman (ops)

Errata ID: 1652
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Brian Bidulock
Date Reported: 2009-01-13
Rejected by: Dan Romascanu
Date Rejected: 2010-05-11

Section 5.4 says:

alarmModelState -> ituAlarmPerceivedSeverity
       1        ->         clear (1)
       2        ->         indeterminate (2)
       3        ->         warning (6)
       4        ->         minor (5)
       5        ->         major (4)
       6        ->         critical (3)

It should say:

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.

Report New Errata



Advanced Search