[rfc-i] [FWD: Thoughts on draft-rfc-editor-errata-process-00.txt]

RFC Editor rfc-editor at rfc-editor.org
Thu Sep 13 09:23:22 PDT 2007

----- Forwarded message from Adrian Farrel <adrian at olddog.co.uk> -----

From: "Adrian Farrel" <adrian at olddog.co.uk>
To: "RFC Editor" <rfc-editor at rfc-editor.org>
Cc: "Ross Callon" <rcallon at juniper.net>
Subject: Thoughts on draft-rfc-editor-errata-process-00.txt
Date: Thu, 13 Sep 2007 12:04:39 +0100


I welcome this attempt to put some control into the errata process. It has 
been the case that some errata have been raised without the consideration of 
the document originators (or inheritors) with the result that poor comments 
are on file or that a false impression is created as to the stability of the 
documented protocol.

It will also be helpful to have a more public and clear repository for 
errata so that RFC revisions do not drop the ball.

Looking at the meat (section 2)...

I think that an archive of rejected errata should be retained. This will 
help prevent the same erratum being raised repeatedly. It will also remove 
the contradiction in:
  This Web interface will support the following three functions:
    1.  Retrieve -- display all posted errata for a specific RFC number.
Unless you change that to say "...all reported or verified errata..."

It would be worth being stronger about each erratum report being kept 
separate. A single report that includes multiple issues will be hard to 
process if part is verified and part rejected, especially if different 
people are required to process the different issues.

I am not sure how you propose to assign permissions for marking an erratum 
as verified or rejected. You say "The SSP, not the author(s) or the RFC 
Editor, would have final responsibility for verifying or rejecting each 
report," but I think this needs to be delegated because it doesn't scale. 
Perhaps a way to handle this is for ADs to delegate to the WG chairs (or 
designated expert for closed WGs) so that:
- a new report causes a notification to the ADs
- the ADs explicitly delegate to the WG chairs
  (the portal can recommend the delegation, so the AD
   only has to click)
- the WG chairs coordinate the response
- the WG chairs enter the target resolution (verify or reject)
- the AD accepts the resolution
This would work best with intermediate states in the portal and explicit 

I think the role of the RFC Editor is still needed in erratum processing. 
For example, a common (petty) erratum report will question the language 
usage in an RFC. Presumably the RFC Editor should have input (maybe even 
control) of the repose in this case otherwise we defeat the purpose of the 
RFC Editor making corrections in the first place. Similarly, if the 
resolution of the erratum report is a new piece of text, shouldn't that text 
be reviewed and edited by the RFC editor?

Please note that author details (such as email addresses) frequently go out 
of date, sometimes very soon after RFC publication. Automatically emailing 
authors may not be a worthwhile procedure (although perhaps it would be 
harmless). In particular, it must not be assumed that the authors have 
received notifications and will act on them. Process control must rest with 
the SSP possibly with delegation through the appropriate WG chairs.

You may want to show this process to Alfred Hoenes <ah at tr-sys.de> since he 
seems to raise a large number of errata.

Many thanks (no response necessary).


----- End forwarded message -----

More information about the rfc-interest mailing list