Re: [Technical Errata Reported] RFC3877 (1819)

The appropriate recommendation would be actually Hold for Document
Update.=20

Dan
=20

> -----Original Message-----
> From: [email protected]=20
> [mailto:[email protected]] On Behalf Of Romascanu, Dan (Dan)
> Sent: Wednesday, September 09, 2009 6:29 PM
> To: Randy Presuhn; [email protected];=20
> [email protected]; RFC Errata System
> Cc: [email protected]; Disman; [email protected]
> Subject: Re: [Disman] [Technical Errata Reported] RFC3877 (1819)
>=20
> I suggest to Reject this Errata Request.=20
>=20
> Technically the submitter is right. However, the change=20
> cannot be made the way suggested in the Errata, but only by=20
> deprecating the object and defining a new object with correct=20
> enumerated values. This can be done only in a future version=20
> of the MIB module.=20
>=20
> Dan
>=20
> (speaking as contributor and co-author of RFC 3877)=20
>=20
> > -----Original Message-----
> > From: Randy Presuhn [mailto:[email protected]]
> > 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 -----
> > > 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=20
> 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
> > 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=20
> 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.=20
> This could=20
> > > 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=20
> alarm related
> > >     -- probable causes.
> > >
> > >
> > > Notes
> > > -----
> > > It seems to be a copy/paste error from the M.3100=20
> 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"=20
> > instead. It is strange how the integers have continued on from 158=20
> > instead of retaining the original values, but anyway, it=20
> appears to be=20
> > a mismatch between the two standards. Ironically I noticed=20
> it when I=20
> > saw that "versionMismatch" had different values (166 and 167).
> > >
> > > Instructions:
> > > -------------
> > > This errata is currently posted as "Reported". If=20
> necessary, please=20
> > > use "Reply All" to discuss whether it should be verified or
> > rejected.=20
> > > 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
> >=20
> >=20
> >=20
>=20