[rfc-i] Errata process

Martin Rex mrex at sap.com
Mon Apr 22 06:17:07 PDT 2013

Joe Touch wrote:
> The question is whether errata are the Comments intended by "Request for 
> Comments", or whether they are intended as pending updates to the doc.
> AFAICT, they are the latter - they're not listed as comments, but rather 
> errata.

Re-read the IETF Process rfc2026 on the to-be-expected defects of
Proposed Standard documents:


   Implementors should treat Proposed Standards as immature
   specifications.  It is desirable to implement them in order to gain
   experience and to validate, test, and clarify the specification.
   However, since the content of Proposed Standards may be changed if
   problems are found or better solutions are identified,

And the IESG statement on processing of RFC Errata for the IETF Stream:


    * Approved - 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 Approved.
   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.

> As such, it is inappropriate to include comments not vetted and approved 
> by the authors and (where appropriate) the WG and/or IESG.

I strongly disagree.

The author(s) may sometimes be the reason why the problem exists
in the first place.

There is *NOTHING* sacred about author/editor opinion and consensus
when it comes to formally provable defects of a specification,
and the explicit addition of a clarification of a formally provable
implied consequence of the _existing_ specification.

We know painfully well that a lot of implementors do poorly on formal
correctness and will miss non-trivial implications, so adding explicit
clarifications is exactly what the errata process has been designed for.

The question of WG consensus comes up when the specification contains
not just an ambiguity, but also offers several different plausible
solutions/choices for disambiguiation.

> I know of cases where errata were rejected because they were either 
> clearly incorrect, created ambiguity, tried to clarify something that 
> has not been resolved by the community, etc. - or even those that were 
> clearly inappropriate under the categories provided (e.g., new 
> extensions that exceeded the intent of the original doc).

Re-read the IESG statement on Processing Errata.  Rejecting an errata
does *NOT* imply that the errata is factually incorrect.  That would
be something that the AD should write into the verifier notes, if it

> Errata ought to catalog document *errors*. They're not a mechanism to 
> log the ongoing evolution of a protocol, nor comments from the community.

That *IS* what is currently __documented__ for new RFCs, i.e. the
only "feedback" option that is offered on the RFC Editor page that
is quoted on the title page of new RFCs.


More information about the rfc-interest mailing list