Subject: [PCN] errata handling procedures

From: Lars Eggert <[email-masked]>
Date: Tue, 22 Dec 2009 09:30:32 +0200

Hi,

please see below for how we handle errata submissions. Basically, the WG chairs indicate to me which of the three actions to take and whether any change is needed, after the errata have been discussed by the WG.

Lars

> On 2008-10-14, at 8:07, ext Lars Eggert wrote:
>> Hi,
>> 
>> attached to this email you'll find a list of all errata that have
>> been reported on documents produced by the transport area, or on
>> documents that are otherwise related to the transport area
>> (documents that pre-date the current IETF structure or individual
>> submissions).
>> 
>> I'd like to ask the chairs of the WGs that produced the respective
>> documents to please lead the effort to determine whether each listed
>> errata is valid or not. Here's the process you should follow:
>> 
>> (1) Make note of the "id" for each errata posted against one of your
>> WG documents
>> 
>> (2) Go to http://www.rfc-editor.org/errata_search.php?eid=XXX where
>> XXX is that errata ID
>> 
>> (3) Copy the results of that page in to an email to the document
>> authors and ask them to comment on the validity of the errata. CC
>> your ADs. You may also CC the WG list if you feel that broader
>> community input would be helpful and/or if the original authors are
>> unresponsive. Give them a deadline of a two weeks or so.
>> 
>> (4) The purpose of this discussion is to determine that (a) the
>> indicated errata type (technical/editorial) is correct, and (b) to
>> decide how the errata should be handled. For the latter, there are
>> three options:
>> 
>> 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.
>> 
>> (5) After that deadline, judge the consensus on the errata, and
>> conclude the discussion phase by sending an email summarizing your
>> decision to the recipients of the original email. CC your ADs. The
>> ADs will then update the posted errata in the RFC Editor's database.
>> 
>> In order to help you determine the correct handling for the errata
>> in step (4), the IESG has come up with a few guidelines:
>> 
>> 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.
>> 
>> Also note that you should involve your AD at any time when you feel
>> the discussion would benefit from this.
>> 
>> All that said, below are our current errata, for your processing
>> pleasure. Please contact Magnus and me if you have any questions
>> about this process.
>> 
>> Lars

---

From: <[email-masked]>
Date: Tue, 22 Dec 2009 09:08:57 +0100

Lars,

the reviewer seems to take a lot of effort to describe the editorials into the right form sheet. Couldn't he directly correct the editorials in the documents and agree that privately with the authors/chairs? That seems a reasonable way to deal with editorials to me, assuming it doesn't cause additional effort, while being more efficient. If that's making sense and there's a chance to chance IETF internal procedures, I'd appreciate your support.

Otherwise I support the option "Hold for document update". 

If that's sufficient discussion on the list,

Merry christmas & happy new year 

Ruediger

Deutsche Telekom Netzproduktion GmbH
Zentrum Technik Einführung
Rüdiger Geib
Heinrich-Hertz-Straße 3-7, 64295 Darmstadt
+49 6151 628-2747 (Tel.)
+49 251 7985 209 (Fax)
http://www.telekom.com

Erleben, was verbindet.

Deutsche Telekom Netzproduktion GmbH
Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender)
Geschäftsführung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Matheis, Klaus Peren
Handelsregister: Amtsgericht Bonn HRB 14190
Sitz der Gesellschaft: Bonn
USt-IdNr. DE 814645262
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lars Eggert
Sent: Tuesday, December 22, 2009 8:31 AM
To: [email-masked]
Subject: [PCN] errata handling procedures

Hi,

Lars