Subject: IESG Processing of RFC Errata for the IETF Stream

From: The IESG <[email-masked]> (by way of Russ Housley <[email-masked]>)
Date: Wed, 30 Jul 2008 14:26:50 -0400

The attached 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.

Thanks,
IESG Secretariat

------------------------------

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:

o Approved - The erratum is appropriate under the criteria below and
should be available to implementors or people deploying the RFC.

o 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.

o 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.

_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 31 Jul 2008 08:37:41 +0100

> be updated to also permit "hold for document update" as errata states.
I assume that these will be made prominently visible in the RFC Editor's 
errata list.
> proposed using channels other than the errata process, such as a
I assume that these errata will not be visible in the RFC Editor's 
errata list.
> merits including in the update.
Are these intended to be visible in the errata list, or not?
(I would prefer them to be visible.)
> some people are still making use of the related technology. 
What's the "Else" here - if there is no such strong evidence, is the 
errata Accepted under a different set of conditions, Rejected or Hold 
for Document Update? (I would prefer the latter, unlikely as such an 
event may be, if my interpretation of intended visibility is right).

                        Harald

---

From: Russ Housley <[email-masked]>
Date: Thu, 31 Jul 2008 04:00:34 -0400

Harald:

I'd like to see this discussed on the rfc-interest mail list.

Previously, you suggested that all errata and their disposition be 
available for historical review, regardless of the state that the 
errata is put into.  I think that this is the plan, but these details 
are for the RFC Editor to implement.

Russ

At 03:37 AM 7/31/2008, Harald Alvestrand wrote:
>I assume that these will be made prominently visible in the RFC 
>Editor's errata list.
>>
>errata Accepted under a different set of conditions, Rejected or 
>Hold for Document Update? (I would prefer the latter, unlikely as 
>such an event may be, if my interpretation of intended visibility is right).
>
>                        Harald
>

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 31 Jul 2008 15:54:54 +0100

> are for the RFC Editor to implement.
OK - message forwarded to rfc-interest.

The answers affect whether or not I think the suggested IESG process is 
reasonable, which is why I was asking the questions.

                    Harald