Re: [Technical Errata Reported] RFC3877 (1819)

I suggest to Reject this Errata Request.=20

Technically the submitter is right. However, the change cannot be made
the way suggested in the Errata, but only by deprecating the object and
defining a new object with correct enumerated values. This can be done
only in a future version of the MIB module.=20

Dan

(speaking as contributor and co-author of RFC 3877)=20

> -----Original Message-----
> From: Randy Presuhn [mailto:[email protected]]=20
> Sent: Wednesday, August 05, 2009 8:04 AM
> To: [email protected]; Romascanu, Dan (Dan);=20
> [email protected]; RFC Errata System
> Cc: [email protected]; [email protected]; Disman
> Subject: Re: [Technical Errata Reported] RFC3877 (1819)
>=20
> Hi -
>=20
> Forwarded to the [email protected] mailing list for (I hope!)=20
> discussion.
>=20
> Randy
>=20
> ----- Original Message -----=20
> > From: "RFC Errata System" <[email protected]>
> > To: <[email protected]>; <[email protected]>;=20
> > <[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=20
> > Management Information Base (MIB)".
> >
> > --------------------------------------
> > You may review the report below and at:
> > http://www.rfc-editor.org/errata_search.php?rfc=3D3877&eid=3D1819
> >
> > --------------------------------------
> > 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=20
> the managed
> >     --system may no longer
> >     --be valid. Usage example: The managed
> >     --system issues this alarm after a reinitialization=20
> with severity
> >     --warning to inform the
> >     --management system about the event. No clearing=20
> 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=20
> detects that it=20
> > has lost the time in
> > -- the real time clock but  the clock itself is working. This could=20
> > happen e.g. during a power
> > -- cut in a small NE which does not have battery backup for=20
> 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=20
> the managed
> >     --system may no longer
> >     --be valid. Usage example: The managed
> >     --system issues this alarm after a reinitialization=20
> with severity
> >     --warning to inform the
> >     --management system about the event. No clearing=20
> 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.=20
> > The comment in the MIB after "lossOfRealTimel" (Note also
> rogue "l" at the end!) clearly refers to the PC string=20
> "reinitialized" instead. It is strange how the integers have=20
> continued on from 158 instead of retaining the original=20
> values, but anyway, it appears to be a mismatch between the=20
> two standards. Ironically I noticed it when I saw that=20
> "versionMismatch" had different values (166 and 167).
> >
> > Instructions:
> > -------------
> > This errata is currently posted as "Reported". If necessary, please=20
> > use "Reply All" to discuss whether it should be verified or=20
> rejected.=20
> > When a decision is reached, the verifying party (IESG) can=20
> log in to=20
> > 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
>=20
>=20
>=20