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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf-announce
