[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
Hi,
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
actions.
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).
Adrian
----- End forwarded message -----
More information about the rfc-interest
mailing list