Updated IESG Statement "IESG Processing of RFC Errata for the IETF Stream"

[IESG Secretary <[e-mail]>]

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).