Re: RFC Errata: when to file, and when not to
Yoav Nir <ynir@checkpoint.com> Thu, 09 August 2012 11:53 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 02FAB21F8670 for <ietf@ietfa.amsl.com>; Thu, 9 Aug 2012 04:53:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.388
X-Spam-Level:
X-Spam-Status: No, score=-10.388 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 rwtH66DNZA4y for <ietf@ietfa.amsl.com>; Thu, 9 Aug 2012 04:53:18 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id DC99221F86A7 for <ietf@ietf.org>; Thu, 9 Aug 2012 04:53:17 -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 q79BrDFG016541; Thu, 9 Aug 2012 14:53:13 +0300
X-CheckPoint: {5023A1BA-0-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 14:53:12 +0300
From: Yoav Nir <ynir@checkpoint.com>
To: Dave Cridland <dave@cridland.net>
Date: Thu, 09 Aug 2012 14:53:12 +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: Ac12JY1x18in8MdwQF+5uPrMkD9yhg==
Message-ID: <EA2F8447-D700-4E22-85A6-30BAD12DF3E6@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>
In-Reply-To: <CAKHUCzza0ba9eDsEHF+y_icmeWTB8Y=3vb3zw83dGi+4-uh77Q@mail.gmail.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: multipart/alternative; boundary="_000_EA2F8447D7004E2285A630BAD12DF3E6checkpointcom_"
MIME-Version: 1.0
Cc: John C Klensin <john-ietf@jck.com>, "ietf@ietf.org" <ietf@ietf.org>, Alessandro Vesely <vesely@tana.it>
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 11:53:19 -0000
On Aug 9, 2012, at 2:35 PM, Dave Cridland wrote: It seems entirely reasonable that there needs to be a version available that's precisely as-published, for legal (and quasi-legal) reasons, as you say - however, that's the version produced by the RFC Editor, and not the tools version (which is already non-normative, technically, due to the markup). What I'm driving at is whether the right way to handle errata is by changing the document on tools (perhaps by diff submission). This should reduce the mechanical workload of errata handling to near-zero, and leave the judgement calls of whether to accept them as the cost. 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? 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. RFC 5903 also has two errata, which were rejected. But they are editorial, so even had they been accepted, they would not require a new RFC.
- RFC Errata: when to file, and when not to Barry Leiba
- Re: RFC Errata: when to file, and when not to Abdussalam Baryun
- Re: RFC Errata: when to file, and when not to Martin J. Dürst
- Re: RFC Errata: when to file, and when not to Barry Leiba
- Re: RFC Errata: when to file, and when not to Alessandro Vesely
- Re: RFC Errata: when to file, and when not to Barry Leiba
- Re: RFC Errata: when to file, and when not to Alessandro Vesely
- Re: RFC Errata: when to file, and when not to t.p.
- Re: RFC Errata: when to file, and when not to Yoav Nir
- Re: RFC Errata: when to file, and when not to t.p.
- Re: RFC Errata: when to file, and when not to Alessandro Vesely
- Re: RFC Errata: when to file, and when not to t.p.
- Re: RFC Errata: when to file, and when not to Dave Cridland
- Re: RFC Errata: when to file, and when not to John C Klensin
- Re: RFC Errata: when to file, and when not to Dave Cridland
- Re: RFC Errata: when to file, and when not to Yoav Nir
- Re: RFC Errata: when to file, and when not to John C Klensin
- Re: RFC Errata: when to file, and when not to Yoav Nir
- Re: RFC Errata: when to file, and when not to John C Klensin
- RE: RFC Errata: when to file, and when not to Worley, Dale R (Dale)
- Re: RFC Errata: when to file, and when not to Stephan Wenger