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
>