I read this document. On a quick read, this seemed very reasonable.
[mailto:ietf-announce-bounces(_at_)ietf(_dot_)org] On Behalf Of The IESG
Sent: Wednesday, April 16, 2008 8:17 AM
To: IETF Announcement list
Cc: iaoc(_at_)ietf(_dot_)org; iab(_at_)iab(_dot_)org;
Subject: Proposed IESG Statement Regarding RFC Errata for
IETF Sream RFCs
The IESG is considering the following statement to guide the
RFC Errata for IETF Stream RFCs. Your review and comment on
on Behalf of the IESG
- - - - - - - - - - - -
Proposed IESG Statement Regarding RFC Errata for IETF Sream RFCs
These are strong guidelines and not immutable rules. Common
and good judgment should be used by the IESG to decide what is
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 had already been approved.
After an erratum is reported, a report will be sent to the
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
to the subject matter. The ADs for the area will review it,
themselves or by delegating, and classify it as falling under
one of the following states:
o Approved - The errata is appropriate under the criteria
should be available to implementors or people deploying the
o Rejected - The errata is in error, or proposes a change
to the RFC
that is clearly inappropriate to do with an errata. In
case, if the change is to be considered for future
updates of the
document, it should be proposed using other channels
such as a WG mailing list.
o Archived - The errata is not a necessary update to the RFC.
However, any future update of the document should consider
errata, and determine whether it is correct and merits
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 Archived.
3. Errata on obsolete RFCs should treated the same as errata on
non-obsolete RFC where there is strong evidence that some
people are still making use of the related technology.
4. Trivial grammar corrections should be Archived.
5. Ugly typos that are clearly bogus typos but would not cause
confusions to implementation or deployments should be
6. Changes which are simply stylistic issues or simply make
read better should be Archived.
7. Changes that modified the working of a protocol to
might be different from the intended consensus when
was approved should be either Archived or Rejected. Deciding
between these two depends on judgment. Changes that are
modifications to the intended consensus, or are of major
importance, should be Rejected. In unclear situations, small
changes can be Archived.
8. Changes that modify the working of a process, such as
an IANA registration procedure, to something that might be
different from the intended consensus when the document was
approved should be Archived.
IETF-Announce mailing list
IETF mailing list