Re: [Disman] [Technical Errata Reported] RFC3877 (1819)

["Romascanu, Dan (Dan)" <[e-mail]>]

The appropriate recommendation would be actually Hold for Document
Update. 

Dan
 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Romascanu, Dan (Dan)
> Sent: Wednesday, September 09, 2009 6:29 PM
> To: Randy Presuhn; [e-mail]; 
> [e-mail]; RFC Errata System
> Cc: [e-mail]; Disman; [e-mail]
> Subject: Re: [Disman] [Technical Errata Reported] RFC3877 (1819)
> 
> I suggest to Reject this Errata Request. 
> 
> 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. 
> 
> Dan
> 
> (speaking as contributor and co-author of RFC 3877) 
> 
> > -----Original Message-----
> > From: Randy Presuhn [mailto:[e-mail]]
> > Sent: Wednesday, August 05, 2009 8:04 AM
> > To: [e-mail]; Romascanu, Dan (Dan); 
> > [e-mail]; RFC Errata System
> > Cc: [e-mail]; [e-mail]; Disman
> > Subject: Re: [Technical Errata Reported] RFC3877 (1819)
> > 
> > Hi -
> > 
> > Forwarded to the [e-mail] mailing list for (I hope!) 
> > discussion.
> > 
> > Randy
> > 
> > ----- Original Message -----
> > > From: "RFC Errata System" <[e-mail]>
> > > To: <[e-mail]>; <[e-mail]>; 
> > > <[e-mail]>; <[e-mail]>;
> > <[e-mail]>
> > > Cc: <[e-mail]>; <[e-mail]>
> > > 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 <[e-mail]>
> > >
> > > 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
> > 
> > 
> > 
>