IESG Processing of RFC Errata for the IETF Stream

7 May 2021

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