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

["Randy Presuhn" <[e-mail]>]

Hi -

I agree that we cannot accept the erratum as proposed.
While the discrepancy between the documents is unfortunate,
as far as I can determine 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.

My recommendation would be to post an informative note
alerting implementors to the discrepancies in numbering
and spelling, so their implementations can include appropriate
mapping functions to avoid losing information.

Randy

----- Original Message ----- 
From: "Romascanu, Dan (Dan)" <[e-mail]>
To: "Romascanu, Dan (Dan)" <[e-mail]>; "Randy Presuhn" <[e-mail]>; <[e-mail]>;
<[e-mail]>; "RFC Errata System" <[e-mail]>
Cc: <[e-mail]>; "Disman" <[e-mail]>; <[e-mail]>
Sent: Wednesday, September 09, 2009 9:05 AM
Subject: RE: [Disman] [Technical Errata Reported] RFC3877 (1819)


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
> >
> >
> >
>