headers
Randy Presuhn | 5 Aug 2009 07:03
Picon

Re: [Technical Errata Reported] RFC3877 (1819)

Hi -

Forwarded to the disman <at> ietf.org mailing list for (I hope!) discussion.

Randy

----- Original Message ----- 
> From: "RFC Errata System" <rfc-editor <at> rfc-editor.org>
> To: <schishol <at> nortelnetworks.com>; <dromasca <at> avaya.com>; <dromasca <at> avaya.com>; <rbonica <at> juniper.net>;
<randy_presuhn <at> mindspring.com>
> Cc: <Enda.Murphy <at> ericsson.com>; <rfc-editor <at> rfc-editor.org>
> 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 <Enda.Murphy <at> ericsson.com>
>
> Section: 5.2
>
> Original Text
> -------------
(Continue reading)

Permalink | Reply |
headers
Romascanu, Dan (Dan | 9 Sep 2009 17:28
Favicon

Re: [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:randy_presuhn <at> mindspring.com] 
> Sent: Wednesday, August 05, 2009 8:04 AM
> To: schishol <at> nortelnetworks.com; Romascanu, Dan (Dan); 
> rbonica <at> juniper.net; RFC Errata System
> Cc: Enda.Murphy <at> ericsson.com; rfc-editor <at> rfc-editor.org; Disman
> Subject: Re: [Technical Errata Reported] RFC3877 (1819)
> 
> Hi -
> 
> Forwarded to the disman <at> ietf.org mailing list for (I hope!) 
> discussion.
> 
> Randy
> 
> ----- Original Message ----- 
> > From: "RFC Errata System" <rfc-editor <at> rfc-editor.org>
> > To: <schishol <at> nortelnetworks.com>; <dromasca <at> avaya.com>; 
> > <dromasca <at> avaya.com>; <rbonica <at> juniper.net>;
(Continue reading)

Permalink | Reply |
headers
Romascanu, Dan (Dan | 9 Sep 2009 18:05
Favicon

Re: [Technical Errata Reported] RFC3877 (1819)

The appropriate recommendation would be actually Hold for Document
Update. 

Dan

> -----Original Message-----
> From: disman-bounces <at> ietf.org 
> [mailto:disman-bounces <at> ietf.org] On Behalf Of Romascanu, Dan (Dan)
> Sent: Wednesday, September 09, 2009 6:29 PM
> To: Randy Presuhn; schishol <at> nortelnetworks.com; 
> rbonica <at> juniper.net; RFC Errata System
> Cc: Enda.Murphy <at> ericsson.com; Disman; rfc-editor <at> rfc-editor.org
> 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:randy_presuhn <at> mindspring.com]
> > Sent: Wednesday, August 05, 2009 8:04 AM
> > To: schishol <at> nortelnetworks.com; Romascanu, Dan (Dan);
(Continue reading)

Permalink | Reply |
headers
Randy Presuhn | 9 Sep 2009 22:25
Picon

Re: [Technical Errata Reported] RFC3877 (1819)

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)" <dromasca <at> avaya.com>
To: "Romascanu, Dan (Dan)" <dromasca <at> avaya.com>; "Randy Presuhn" <randy_presuhn <at> mindspring.com>; <schishol <at> nortelnetworks.com>;
<rbonica <at> juniper.net>; "RFC Errata System" <rfc-editor <at> rfc-editor.org>
Cc: <Enda.Murphy <at> ericsson.com>; "Disman" <disman <at> ietf.org>; <rfc-editor <at> rfc-editor.org>
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
(Continue reading)

Permalink | Reply |
headers
Romascanu, Dan (Dan | 13 Sep 2009 11:44
Favicon

Re: [Technical Errata Reported] RFC3877 (1819)

Randy,

To a certain extent the status 'Hold for Document update' plays the role
of this note, as it shows the discrepancies as reported. When and if RFC
3877 will be revised the content of the erratum will be discussed. 

Did you gave any other place for the note to be posted? 

Dan

> -----Original Message-----
> From: Randy Presuhn [mailto:randy_presuhn <at> mindspring.com] 
> Sent: Wednesday, September 09, 2009 11:25 PM
> To: Romascanu, Dan (Dan); schishol <at> nortelnetworks.com; 
> rbonica <at> juniper.net; RFC Errata System
> Cc: Enda.Murphy <at> ericsson.com; Disman; rfc-editor <at> rfc-editor.org
> Subject: Re: [Disman] [Technical Errata Reported] RFC3877 (1819)
> 
> 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
(Continue reading)

Permalink | Reply |

Gmane