[rfc-i] Errata process
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
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