IESG Processing of RFC Errata for the IETF Stream

30 Jul 2008

This Statement describes the manner in which the IESG will be processing RFC Errata for the IETF Stream.

NOTE: This IESG Statement is replaced by the IESG Statement "IESG Processing of RFC Errata for the IETF Stream" dated 7 May 2021.

The [below] describes the manner in which the IESG will be processing RFC Errata for the IETF Stream. The current tools on the RFC Editor site support "approved" and "rejected", but they need to be updated to also permit "hold for document update" as errata states.

These are strong guidelines and not immutable rules. Common sense and good judgment should be used by the IESG to decide what is the right thing to do. 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. These guidelines only apply to errata on RFCs in the IETF stream. They apply to new errata and not errata that have already been approved. 

After an erratum is reported, a report will be sent to the authors, chairs, and Area Directors (ADs) of the WG in which it 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 to the subject matter. The ADs are responsible for ensuring review; 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 implementors or people deploying the RFC.
• Rejected - The erratum is in error, or proposes a change to the RFC that should be done by publishing a new RFC that replaces the current RFC. 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 this erratum, and determine whether it is correct and merits including in the update.

Guidelines for review are: 

1. Only errors that could cause implementation or deployment problems or significant confusion should be Verified.
2. Things that are clearly wrong but could not cause an implementation or deployment problem should be Hold for Document Update.
3. Errata on obsolete RFCs should be treated the same as errata on RFCs that are not obsolete where there is strong evidence that some people are still making use of the related technology.
4. Trivial grammar corrections should be Hold for Document Update.
5. Typographical errors which would not cause any confusions to implementation or deployments should be Hold for Document Update.
6. Changes which are simply stylistic issues or simply make things read better should be Hold for Document Update.
7. Changes that modify the working of a protocol to something that might be different from the intended consensus when the document was approved should be either Hold for Document Update or Rejected. Deciding between these two depends on judgment. Changes that are clearly modifications to the intended consensus, or involve large textual changes, should be Rejected. In unclear situations, small changes can be Hold for Document Update.
8. 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.