IESG Errata Processing
Cisco
170 West Tasman Drive
MS: SJC-21/2
San Jose
CA
95134
USA
+1 408 421-9990
fluffy@cisco.com
GEN
This brief note discusses plans the IESG is considering on errata
processing. It is not intended to become an RFC but is only a draft for
the IESG to solicit input from the community on how the IESG to should
handle errata.
The RFC editor has instigated a new errata process and as part of
this the IESG will need to decide how to approve errata. The IESG is
considering the following guidelines to be used for approving errata on
documents in the IETF stream.
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:
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 my 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:
Only errors that could cause implementation or deployment
problems or significant confusion should be Approved.
Things that are clearly wrong but could not cause an
implementation or deployment problem should be Hold for Document
Update.
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.
Trivial grammar corrections should be Hold for Document
Update.
Typographical errors which would not cause any confusions to
implementation or deployments should be Hold for Document
Update.
Changes which are simply stylistic issues or simply make things
read better should be Hold for Document Update.
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.
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.
Future RFC’s from IETF track should include a line that tell
people reading the RFC were they might find errata. When the RFC was
first published it would include text along the lines of:
There may be errata and other information for this RFC which can
be found at http://www.rfc-editor.org/errata/rfcXXXX
This errata list should show just Approved errata on the first page -
perhaps with links to pages with other types such as Rejected or Hold
for Document Update.
When searching for all errata it would be nice to be able to filter
by area and by working group name. It would also be nice to be able to
filter on Type and Status. Ideally the results of a search could be
sorted by Date-Reported, RFC number, or by errata submitter name.
This draft has no IANA considerations.
Several members of IESG sent comments but special thanks to Sandy
Ginoza who found and fixed many mistakes in this text.