Re: RFC Errata: when to file, and when not to

Yoav Nir <ynir@checkpoint.com> Thu, 09 August 2012 14:12 UTC

Return-Path: <ynir@checkpoint.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D60D321F866E for <ietf@ietfa.amsl.com>; Thu, 9 Aug 2012 07:12:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.392
X-Spam-Level:
X-Spam-Status: No, score=-10.392 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3Vcec44N4iX for <ietf@ietfa.amsl.com>; Thu, 9 Aug 2012 07:12:28 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 9F89D21F8669 for <ietf@ietf.org>; Thu, 9 Aug 2012 07:12:27 -0700 (PDT)
Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id q79ECF16015973; Thu, 9 Aug 2012 17:12:24 +0300
X-CheckPoint: {5023C24F-1-1B221DC2-4FFFF}
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 9 Aug 2012 17:11:59 +0300
From: Yoav Nir <ynir@checkpoint.com>
To: John C Klensin <john-ietf@jck.com>
Date: Thu, 09 Aug 2012 17:11:58 +0300
Subject: Re: RFC Errata: when to file, and when not to
Thread-Topic: RFC Errata: when to file, and when not to
Thread-Index: Ac12OPApVuHT5Xo+SauxF2rTXSGDrg==
Message-ID: <4F18A4B6-3D63-4135-A367-F3CAAF4132CF@checkpoint.com>
References: <CALaySJKV96tdXhzfPD1e1Mro_+gp5aDarF7Z06QrA+iQtnHkLw@mail.gmail.com> <501A5656.2050407@it.aoyama.ac.jp> <501BEC0D.1060404@tana.it> <009101cd7476$bb522c20$4001a8c0@gateway.2wire.net> <599B1629-543A-49BC-A0E7-FA2096C538AD@checkpoint.com> <03e701cd749f$73891c40$4001a8c0@gateway.2wire.net> <50229D32.8000605@tana.it> <006701cd7606$17ff48a0$4001a8c0@gateway.2wire.net> <CAKHUCzzsf6veDR+uwxnMw4Koh0Kj7FqoQpsUbENMb_r3v0G89A@mail.gmail.com> <5256BF9BC9AE13013F066C4E@JcK-HP8200.jck.com> <CAKHUCzza0ba9eDsEHF+y_icmeWTB8Y=3vb3zw83dGi+4-uh77Q@mail.gmail.com> <EA2F8447-D700-4E22-85A6-30BAD12DF3E6@checkpoint.com> <E3A4486529AAE3D8CD2A0098@JcK-HP8200.jck.com>
In-Reply-To: <E3A4486529AAE3D8CD2A0098@JcK-HP8200.jck.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Alessandro Vesely <vesely@tana.it>, "ietf@ietf.org" <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Aug 2012 14:12:29 -0000

On Aug 9, 2012, at 3:34 PM, John C Klensin wrote:

> 
> 
> --On Thursday, August 09, 2012 14:53 +0300 Yoav Nir
> <ynir@checkpoint.com> wrote:
> 
>> 
>> This means that there would be two documents with the same RFC
>> number. The quasi-leagal "as published" one, and the one of
>> the tools site. Which should I follow when I go to implement?
> 
> Exactly
> 
>> If the errors amount to something that would really make a
>> difference in implementation, you really need a new RFC, and
>> can't handle this in an erratum.
>> 
>> See for example RFC 4753. The erratum changed bits on the
>> wire, so a replacement RFC (5903) had to be published.
> 
> And, if I correctly understood it at the time, that is exactly
> why the RFC Editor opposed the idea of formal errata for years.
> If there were real, substantive, errors, a replacement RFC
> should be published as soon as practical.  For anything else,
> the most that was desirable would be a collected list of
> comments and suggestions that could be considered if/when the
> document was revised.

There are still the spelling mistakes and obvious errors. Take for example this one from RFC 5296:

   The EMSKname is in the username part of the NAI and is encoded in
   hexadecimal values.  The EMSKname is 64 bits in length and so the 
   username portion takes up 128 octets.

Encoding 64 bits in hex requires 16 octets, not 128. I think anyone implementing this would figure this out, but it is substantive. The RFC was being revised anyway, but do you think a replacement RFC would need to be published if that were not the case?

Yoav