Re: Updated IESG Statement "IESG Processing of RFC Errata for the IETF Stream"
Brian E Carpenter <brian.e.carpenter@gmail.com> Sat, 08 May 2021 02:30 UTC
Return-Path: <brian.e.carpenter@gmail.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 4CFE23A27AD for <ietf@ietfa.amsl.com>; Fri, 7 May 2021 19:30:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0xpdSH6_qUD for <ietf@ietfa.amsl.com>; Fri, 7 May 2021 19:30:08 -0700 (PDT)
Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99C763A27A5 for <ietf@ietf.org>; Fri, 7 May 2021 19:30:08 -0700 (PDT)
Received: by mail-pg1-x534.google.com with SMTP id i14so8689037pgk.5 for <ietf@ietf.org>; Fri, 07 May 2021 19:30:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=3LdLMJJuUR/uY9iLloiNDY0QkjBUBfdswlmrWk6UhPU=; b=IO3uJVySKY1byi3iO7P1/jS5cKfYswBCDCAxH63e0n1YXk3wIw83cc7BW0lPG0TeFp wNUL0EUlK7RjwEAtOcZ3jfYa+NSvLefcxRzPEVjm9vMFaxemMwi4iaBMquYsDD68j5zT XNbusfWIuIDOmJGJYOfbLtGSzBD84Lk7/OprfkYHyOf2aNgQjG3S92P0w81SHrd2a6bM 35Ih+7F2aetTrn6Gwc0Uquwt3w2KeiFF7si3g6gIhDzlhyxDtuWK5wSuxrB57Vxbt2nV /ooCdO0VYKLSK0mCQOM6CrDh6PZQRpqbCjpxsWiJjQ4CQkK59K8CF9w4MZ0Zs/bznmko ya0w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=3LdLMJJuUR/uY9iLloiNDY0QkjBUBfdswlmrWk6UhPU=; b=l6zYb9p/IScjTPH3oQauYeSqUiVy0y2fBp/ySjw6TuMqpeBwDWFY6BTsvJ5JYUAZU2 EGx0YBUCsHmFVCdzD88xjx9VqsZz4Rdeg+CP0hz3CckZZECYvBMySZ12NlYTd5fK0gyQ 6jgEsme807Cnikz3nLH1gAyelawe0+/D4TjadEDNMdBLmAJM4rpIArDH9lSVh+hX65KS 6Gw4afyFbJeja7LOOwgShRdWOklofuuePnJ+nkFF3uBbPDRqBGMz6Fr1Q2GlclfpmnAz 62mOLMHNmA6X+5yMgbUj0RY7gFa4mznxqIBs8cd3S7dfqKbeXRXZI1DVn8+zRnDc4cyG TxbQ==
X-Gm-Message-State: AOAM5319kQxM77vcxD0CW1xwIBwEQUGzAXAGT9gpuQx90biJjEq4n2xw mr2anxx/fjxBtmi/o5Dj4xPZUoNRUBuBHA==
X-Google-Smtp-Source: ABdhPJw9lHJhhi5ZwxUPmYCxqesb0m0ARfTcpPT3RhSXrzifeh/plgnVfzTuHIjuM7p5KcRXsy1MZQ==
X-Received: by 2002:a63:5503:: with SMTP id j3mr13242069pgb.256.1620441007081; Fri, 07 May 2021 19:30:07 -0700 (PDT)
Received: from [192.168.8.102] (122-56-234-156.mobile.spark.co.nz. [122.56.234.156]) by smtp.gmail.com with ESMTPSA id e5sm5403315pjv.22.2021.05.07.19.30.05 for <ietf@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 07 May 2021 19:30:06 -0700 (PDT)
Subject: Re: Updated IESG Statement "IESG Processing of RFC Errata for the IETF Stream"
To: IETF discussion list <ietf@ietf.org>
References: <162040549861.22240.16336069769197991691@ietfa.amsl.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <18d87dd8-3363-ef49-36f6-a34ff8c60e59@gmail.com>
Date: Sat, 08 May 2021 14:30:02 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <162040549861.22240.16336069769197991691@ietfa.amsl.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/eyagwXD0Q42kZxjh5JL5D35GP9I>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Sat, 08 May 2021 02:30:13 -0000
Hi, Does the IESG plan to catch up on old reported errata that have never been processed? There are three here for example: https://www.rfc-editor.org/errata/rfc6275, as much as 4 years old. There may be a lot more lurking. Regards Brian Carpenter On 08-May-21 04:38, IESG Secretary wrote: > IESG Processing of RFC Errata for the IETF Stream > > Online: <https://www.ietf.org/about/groups/iesg/statements/processing-errata-ietf-stream/> > > This document describes how the IESG processes RFC Errata for the IETF Stream. > > These are strong guidelines, not immutable rules. The Area Directors (ADs) should use > common sense and good judgment to decide what the right thing to do is. They apply to new > errata and not to errata that have already been processed. > > Errata are meant to fix "bugs" in the specification and should not be used to change what the > community meant when it approved the RFC. Here are some things to consider when > submitting an errata report: > > * Errata are items that were errors at the time the document was published -- things that > were missed during the last call, approval, and publication process. If new information, > new capabilities, or new thinking has come up since publication, or if you disagree with > the content of the RFC, that is not material for an errata report. Such items are better > brought to relevant working groups, technical area discussions, or the IESG. > * Errata reports are usually for errors in the text version of a document. It is possible to > report errors in other outputs (e.g., HTML or PDF) for RFCs published in the v3 format > (i.e., RFC 8650+). > * Errata are classified as "technical" or "editorial". Please mark the report appropriately. > Technical errata are expected to be things that would likely cause significant > misunderstandings of the technical specification and might result in faulty > implementations if they are not corrected. Editorial errata are, as the name implies, > editorial - for example, typos, missing commas, etc. Errors in examples will generally be > editorial, though marking them as technical could sometimes be justified. > * Please clearly explain the issue in the Comments section. This is especially important for > editorial issues, where the Original Text and Corrected Text may look almost identical. > > When a technical erratum is reported, a report is sent to the authors, chairs, and Area Directors > (ADs) of the WG in which the document originated. If the WG has closed or the document was > not associated with a WG, then the report will be sent to the ADs for the Area most closely > associated with the subject matter. > > When an editorial erratum is reported, the RFC Editor will do an initial review and handle errata > that are clearly editorial in nature. If the erratum cannot be handled by the RFC Editor, the AD > will be asked to review. > > While ADs are ultimately responsible for processing the reports, they may delegate the review > or perform it personally. The reviewer will classify the erratum as falling under one of the > following states: > > * Verified - The erratum is appropriate under the criteria below and should be available to > implementers or people deploying the RFC. > * Rejected - The erratum is invalid or proposes a significant change to the RFC that > should be done by publishing a new RFC that replaces or updates the current one. In > the latter case, if the change is to be considered for future updates of the document, it > should be proposed using channels other than the errata process, such as a WG mailing > list. > * Hold for Document Update - The erratum is not a necessary update to the RFC. > However, any future update of the document might consider it and determine whether it > merits including in an update. > > Guidelines for review are: > > 1. Grammar corrections and typographical errors should be classified as Verified. > 2. Broken URIs that were likely valid at the time of publication are, strictly speaking, not > subject to errata reports. That said, the AD must judge the importance of correcting > such a reference and may classify the report as Verified. > 3. Changes that are stylistic issues or simply make things read better should be classified > as Hold for Document Update. > 4. Technical items that have a clear resolution in line with the original intent should be > classified as Verified. If the resolution is not clear or requires further discussion, the > report should be classified as Hold for Document Update. In both cases, only items that > are clearly wrong should be considered. > 5. Changes that modify the working of a protocol to something that might be different from > the intended consensus when the document was approved should generally be > Rejected. Significant clarifications should not be handled as errata reports and need to > be discussed by the relevant technical community. > 6. Changes that modify the working of a process, such as changing an IANA registration > procedure, to something that might be different from the intended consensus when the > document was approved should be Rejected. > 7. Errata on obsolete RFCs should be considered according to whether the error persists in > the obsoleting RFC. If it does, the report should Rejected with a pointer to new errata > against the obsoleting RFC. If it does not, it should be Rejected with an explanation that > the error is corrected in the obsoleting RFC (cited by number). > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce >
- Re: Updated IESG Statement "IESG Processing of RF… Brian E Carpenter
- Re: Updated IESG Statement "IESG Processing of RF… Eric Vyncke (evyncke)
- Re: Updated IESG Statement "IESG Processing of RF… Michael Richardson
- Re: Updated IESG Statement "IESG Processing of RF… Brian E Carpenter
- Re: Updated IESG Statement "IESG Processing of RF… Bob Hinden
- Re: Updated IESG Statement "IESG Processing of RF… Stewart Bryant
- Re: Updated IESG Statement "IESG Processing of RF… Spencer Dawkins at IETF
- Re: Updated IESG Statement "IESG Processing of RF… Spencer Dawkins at IETF
- Re: Updated IESG Statement "IESG Processing of RF… Carsten Bormann
- Re: Updated IESG Statement "IESG Processing of RF… tom petch
- Re: Updated IESG Statement "IESG Processing of RF… John C Klensin
- Re: Updated IESG Statement "IESG Processing of RF… Spencer Dawkins at IETF
- Re: Updated IESG Statement "IESG Processing of RF… otroan
- Re: Updated IESG Statement "IESG Processing of RF… Carsten Bormann
- Re: Updated IESG Statement "IESG Processing of RF… Lloyd W
- Re: Updated IESG Statement "IESG Processing of RF… John C Klensin
- Re: Updated IESG Statement "IESG Processing of RF… Michael Richardson
- Re: Updated IESG Statement "IESG Processing of RF… Alvaro Retana
- Re: Updated IESG Statement "IESG Processing of RF… Brian E Carpenter
- Re: Updated IESG Statement "IESG Processing of RF… Spencer Dawkins at IETF
- Re: Updated IESG Statement "IESG Processing of RF… Lloyd W
- Re: Updated IESG Statement "IESG Processing of RF… Spencer Dawkins at IETF
- Re: Updated IESG Statement "IESG Processing of RF… lloyd.wood@yahoo.co.uk
- Re: Updated IESG Statement "IESG Processing of RF… Carsten Bormann
- Re: Updated IESG Statement "IESG Processing of RF… Julian Reschke
- Re: Updated IESG Statement "IESG Processing of RF… Stewart Bryant
- Re: Updated IESG Statement "IESG Processing of RF… Bob Hinden
- Re: Updated IESG Statement "IESG Processing of RF… John C Klensin
- Re: Updated IESG Statement "IESG Processing of RF… Stewart Bryant
- Re: Updated IESG Statement "IESG Processing of RF… Carsten Bormann
- Re: Updated IESG Statement "IESG Processing of RF… John C Klensin
- Re: Updated IESG Statement "IESG Processing of RF… Ole Jacobsen
- Re: Updated IESG Statement "IESG Processing of RF… John C Klensin
- Re: Updated IESG Statement "IESG Processing of RF… John C Klensin
- Re: Updated IESG Statement "IESG Processing of RF… Spencer Dawkins at IETF
- Re: Updated IESG Statement "IESG Processing of RF… tom petch
- Re: Updated IESG Statement "IESG Processing of RF… Stewart Bryant