Re: [Technical Errata Reported] RFC3877 (1819)

Hi -

Forwarded to the [email protected] mailing list for (I hope!) discussion.

Randy

----- Original Message ----- 
> From: "RFC Errata System" <[email protected]>
> To: <[email protected]>; <[email protected]>; <[email protected]>; <[email protected]>;
<[email protected]>
> Cc: <[email protected]>; <[email protected]>
> Sent: Wednesday, July 29, 2009 9:59 AM
> Subject: [Technical Errata Reported] RFC3877 (1819)
>
>
> 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=1819
>
> --------------------------------------
> Type: Technical
> Reported by: Enda Murphy <[email protected]>
>
> Section: 5.2
>
> Original Text
> -------------
>     -- 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.
>
>
> Corrected Text
> --------------
>     -- 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).
>
> 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