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

John C Klensin <john-ietf@jck.com> Thu, 09 August 2012 14:59 UTC

Return-Path: <john-ietf@jck.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 3B87B21F8720 for <ietf@ietfa.amsl.com>; Thu, 9 Aug 2012 07:59:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.584
X-Spam-Level:
X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 mT2Zz3Mf3t+G for <ietf@ietfa.amsl.com>; Thu, 9 Aug 2012 07:59:48 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 43AEA21F8743 for <ietf@ietf.org>; Thu, 9 Aug 2012 07:59:43 -0700 (PDT)
Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1SzU77-000Ors-U9; Thu, 09 Aug 2012 10:53:29 -0400
Date: Thu, 09 Aug 2012 10:59:27 -0400
From: John C Klensin <john-ietf@jck.com>
To: Yoav Nir <ynir@checkpoint.com>
Subject: Re: RFC Errata: when to file, and when not to
Message-ID: <03F0AB7F579E78F38CB37092@JcK-HP8200.jck.com>
In-Reply-To: <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> <4F18A4B6-3D63-4135-A367-F3CAAF4132CF@checkpoint.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: Alessandro Vesely <vesely@tana.it>, 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:59:49 -0000

--On Thursday, August 09, 2012 17:11 +0300 Yoav Nir
<ynir@checkpoint.com> wrote:

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

Personal opinion:  I don't know about "need to be", but
replacing an RFC with an error of that type would be desirable
to avoid any possible misunderstanding, however unlikely.  IMO,
it would also be desirable to have some self-examination in the
community about why that error slipped past IETF Last Call, AD
reviews, and AUTH48).

   john