One document matched: draft-rfc-editor-errata-process-00.txt
Network Working Group RFC Editor
Internet-Draft USC/ISI
Intended status: Informational August 24, 2007
Expires: February 25, 2008
RFC Editor Proposal for Handling RFC Errata
draft-rfc-editor-errata-process-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 25, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document describes the current RFC Editor procedures for
handling the submission, verification, and posting of errata for the
RFC Series, and then proposes a more efficient and transparent
process. The main concepts are (1) distributing the responsibility
for verification to the appropriate organization or person for each
RFC stream, and (2) using a Web portal to automate the book-keeping
for handling errata.
RFC Editor Expires February 25, 2008 [Page 1]
Internet-Draft RFC Errata Process August 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background on RFC Errata . . . . . . . . . . . . . . . . . 3
1.2. Current Errata Process . . . . . . . . . . . . . . . . . . 4
2. Proposed Errata Process . . . . . . . . . . . . . . . . . . . 6
2.1. Reporting Errata . . . . . . . . . . . . . . . . . . . . . 6
2.2. Verifying Errata . . . . . . . . . . . . . . . . . . . . . 8
2.3. Posting Errata . . . . . . . . . . . . . . . . . . . . . . 9
2.4. Errata Announcements . . . . . . . . . . . . . . . . . . . 9
2.5. Role of the RFC Editor . . . . . . . . . . . . . . . . . . 9
3. Transition . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Informative References . . . . . . . . . . . . . . . . . . . . 10
Appendix A. Possibilities for Posting Errata . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 12
RFC Editor Expires February 25, 2008 [Page 2]
Internet-Draft RFC Errata Process August 2007
1. Introduction
This document proposes significant changes in the current procedures
and mechanisms for handling RFC errata, to improve efficiency and
accountability of errata processing. The main concepts are (1)
distributing responsibility for errata verification to the
appropriate body or person for each RFC stream, and (2) using a Web
portal to automate the book-keeping task for verifying and posting
errata. The RFC Editor is seeking comments from the IETF community
on the proposed procedure.
The proposed errata process assumes the organization of RFC
publication into four document streams [RFC4844]: (1) the IETF
stream, which includes both working group and individual submissions,
(2) the IAB stream, (3) the IRTF stream, and (4) the Independent
Submission stream. We propose that personnel representing each
stream be responsible for verifying the errata reported for that
stream's RFCs. In particular, we propose that one or more stream-
specific parties (SSPs) be designated with responsibility for
verifying and posting errata for each stream. At the organizational
level, the SSPs might be:
o IESG for IETF documents
o IAB for IAB documents
o IRSG for IRTF documents
o RFC Editor/Editorial Board for Independent Submissions
1.1. Background on RFC Errata
The RFC Editor began to collect and post RFC errata in 2000. The
idea was to discourage readers from repeatedly pointing out the same
typos in published RFCs. This evolved into the current errata
verification and posting process, which is a manually operated,
email-based task.
Unfortunately, our understanding of the errata problem was wrong in
several ways. The number of errors reported turned out to be
significantly greater than anticipated, and the process of vetting
and posting required more human resources.
Another issue with errata is that some of the reported errors are not
simply editorial, but rather correct technical contents of RFCs. A
savvy implementer of the specification can often, but not always,
figure out what was intended by the RFC as published, but technical
errors should be announced somehow. Furthermore, posting technical
RFC Editor Expires February 25, 2008 [Page 3]
Internet-Draft RFC Errata Process August 2007
errata for Standards Track documents should always involve the IESG,
as a matter of correct process. Technical errata may require much
review and discussion among the author(s), Area Directors, and other
interested parties.
We note that allowing technical errata is a slippery slope: there may
be a temptation to use errata to "fix" protocol design errors, rather
than publishing new RFCs that update the erroneous documents. In
general, an erratum is intended to report an error in a document,
rather than an error in the design of the protocol or other entity
defined in the document, but this distinction may be too imprecise to
avoid hard choices. For the IETF stream, these choices should be
made by the IESG, not the RFC Editor.
In summary, errata have become a much larger, more complex, and more
important issue than they were originally. This proposal attempts to
address these problems.
1.2. Current Errata Process
The following is a summary of the current RFC Editor errata
verification and posting process. The RFC Editor must:
o Review email and relevant RFCs to ensure that the reported errata
are real.
o Disentangle multiple errors reported in one message.
o Check that each error has not already been posted.
o Attempt to determine whether the errata are editorial or
technical.
o Move the errata report message(s) to the pending folder.
o Forward each erratum report to the author(s) of the published RFC.
o Track bounce messages (contact information for authors is often
out of date) and try to find current contact information.
o Forward the message to the relevant ADs if we are unable to find
current author contact information.
o Track follow-up email.
o Figure out how to post when reporters/authors do not submit errata
in the original/new format. This is often a problem when
reporters submit email claiming an error, but do not offer
RFC Editor Expires February 25, 2008 [Page 4]
Internet-Draft RFC Errata Process August 2007
corrective text.
o Post verified errata and discard rejected errata.
Currently, posting an erratum means that it is:
1. Available from the RFC errata page:
http://www.rfc-editor.org/errata.html.
2. Linked to from the results of the RFC search engine:
http://www.rfc-editor.org/rfcsearch.html.
3. Linked to from some HTML versions of the RFC. For example, see
http://tools.ietf.org/html/rfc2119.
There are currently four possible states for processing an erratum:
1. Reported - the erratum has been reported but is unverified.
2. Verified - the erratum has been edited as necessary and verified.
3. Posted - the erratum has been made public through the channels
listed above. (See also Appendix A).
4. Rejected - The reported erratum was redundant or incorrect and
has been discarded.
During 2006, the RFC Editor was understaffed for the growing load of
RFCs to be published (see
http://www.rfc-editor.org/num_rfc_year.html). To catch up, the RFC
Editor suspended all activities not directly related to RFC
publication. As a result, more than a year's worth of errata reports
have not been verified or posted. As resources allowed, the RFC
Editor provided the following interim measures:
1. Posting on the RFC Editor Web site an unlinked mailbox text file
(mbox format) of all errata-related email that we received (ftp:/
/ftp.rfc-editor.org/in-notes/pending-errata/pending-errata.msgs).
2. For those few errata that we did add to the errata database, mark
them UNVERIFIED. We believe that the proposed Web portal will
significantly speed catching up on these past reports as well as
handle future reports more efficiently.
RFC Editor Expires February 25, 2008 [Page 5]
Internet-Draft RFC Errata Process August 2007
2. Proposed Errata Process
We propose that a Web application ("portal") be used to manage and
automate the reporting, verifying, and posting of errata. Such a Web
portal will lead to a more uniform reporting process, ease
communication among the parties responsible for verification, and
automate the posting of verified errata.
The Web portal will automatically post an erratum when it is marked
verified, so there will be just three possible states for an erratum
under this proposal:
1. Reported - the erratum has been reported but is unverified.
2. Verified - the erratum has been edited as necessary, verified,
and posted.
3. Rejected - The erratum was redundant or incorrect and has been
discarded. These will not be retained.
This Web interface will support the following three functions:
1. Retrieve -- display all posted errata for a specific RFC number.
2. Report -- report a new erratum, as described below.
3. Verify/Edit -- used by an SSP to edit, verify, and post an
erratum.
The following sections describe the steps in the proposed process.
2.1. Reporting Errata
A member of the Internet community (the "reporter") would navigate to
the errata Report Web page and enter the RFC number of the document
containing the error. All earlier (i.e., reported and verified)
errata for that RFC would be displayed, and the reporter would be
asked to check that the new erratum was not already posted. This
should help prevent multiple reports of the same error.
RFC Editor Expires February 25, 2008 [Page 6]
Internet-Draft RFC Errata Process August 2007
The user would then report the erratum using a Web form to create a
report record in the RFC Erratum database. This report record may be
augmented by information drawn from the primary RFC Editor database
or supplied by the SSP. We envision that an erratum report record
might include the following fields:
*RFC #
*Reporter name
*Reporter email address
Report date
*Type [editorial, technical]
Section #
*Original text
*Corrected text
Notes/Rationale
Document stream for RFC
Internet Draft file name (when available)
Area (for IETF stream)
Working Group name (if group is still active)
Category ("status") of RFC
SSP Identity
* indicates information required of reporter
The report would trigger an email notification message to the
appropriate SSP, to the RFC author(s), and to the RFC Editor. The
SSP could forward the notification email further; for example, an
Area Director might forward it to the chair of the responsible
working group, if it still exists.
Generally, we would want the reporter to enter a new erratum using
the Original and Corrected Text fields. However, there should also
be a free-text Notes/Rationale field, for those errata that cannot
easily be put into the old/new format. For example, the Notes field
could be used to report a global error without having to specify each
occurrence:
"Throughout the text, references to the Unicode character g-clef
should be represented as 'g-clef U+1D11E F0 9D 84 9E'."
The Report page might allow a small number of errors (e.g., 4) in the
same RFC to be submitted at the same time, using the Original/
Corrected form. By having the user separate the errata entries, the
SSP should have an easier time verifying each entry. We also hope
that this will encourage users to submit only the most valuable
errata.
RFC Editor Expires February 25, 2008 [Page 7]
Internet-Draft RFC Errata Process August 2007
In the case of early RFCs for which the RFC Editor does not have
associated stream or area information, the portal will send the
initial email to the RFC Editor and the authors (whose contact
information is likely out of date; see below). The RFC Editor will
track down verifiers (perhaps by determining an appropriate SSP and
seeking guidance) or verify the report, if possible.
When author email addresses are out of date, the RFC Editor could
forward the bounce messages to the SSP, who would then have the
option of seeking current author contact information or relying on
other individuals with knowledge of the subject matter.
The reporter would be asked to make a judgment on the errata type --
technical vs. editorial. If the reporter has both editorial and
technical errors in the same RFC, the two classes of errata must be
entered as separate reports. This initial classification should be
very useful to the SSP; for example, it might allow technical errata
to be processed with higher priority than editorial errata. It would
also allow the RFC Editor to monitor editorial errata to note
frequent editorial errors, possibly leading to improvements in the
editorial process.
We expect that the reporter will usually make the right technical/
editorial classification, with the aid of published guidelines.
However, in case of mis-classification, the SSP or the RFC Editor
would be able to change the initial classification.
2.2. Verifying Errata
When the reporter clicked SUBMIT on the Report page, a notification
message would be sent to the relevant SSP and the authors. Including
them all as addressees in one message would facilitate cooperation in
verifying the error.
The SSP and the authors would determine the validity of the reported
erratum, by whatever procedure the SSP or the stream owner
determines. The RFC Editor would not normally track the verification
process. The SSP, not the author(s) or the RFC Editor, would have
final responsibility for verifying or rejecting each report. This
should avoid a great deal of complexity and confusion.
The SSP identity would be added to the record, and the SSP would have
a login account on the errata portal to edit her/his errata records
as necessary. The SSP would be provided with a check screen that
showed the entry as it will be displayed when it is posted.
The Notes/Rationale field would allow users to submit information in
any fashion they like, so there is a possibility of multiple errors
RFC Editor Expires February 25, 2008 [Page 8]
Internet-Draft RFC Errata Process August 2007
being reported in this field. The SSP would be able to edit the
report record to split it into multiple records to maintain one
record per erratum (for example, to handle the case where some
reported errors are accepted and some are rejected).
Based on experience, we know that some errata reports will require
significant email discussion between the reporter and the author(s)
and/or SSPs (in particular, the IESG) before the final decision on a
record can be made. The final outcome will be captured in the errata
entry, but any controversy or explanatory material could be recorded
in the Notes/Rationale section.
2.3. Posting Errata
A logged-in SSP can use the Web portal to mark the errata as verified
or rejected. If verified, the errata would be posted; if rejected,
the errata would be discarded. In either case, the portal would send
a notification message to the reporter, the SSP, the authors, and the
RFC Editor.
It sometimes happens that there are errata for errata, i.e., earlier
postings must be altered. In this case, the RFC Editor must be able
to do the update as requested by an SSP or to grant an SSP temporary
write access to the record to be updated.
We propose to continue posting errata as described in Section 1.2.
However, there are other possibilities for errata posting that should
be considered by the community; see Appendix A.
2.4. Errata Announcements
The RFC Editor would propose to announce verified errata postings to
the rfc-distribution list. If the SSP felt the errata was important
enough, s/he might want to submit a note to the ietf-announce list.
However, we do not believe it is necessary to inundate the ietf-
announce list with mail each time an errata is verified, rejected, or
altered.
2.5. Role of the RFC Editor
The role of the RFC Editor in errata processing would be to:
1. Operate the Web portal.
2. Maintain the Errata Database.
3. Make changes in previously posted errata at the request of the
corresponding SSP, or give the SSP temporary write access to the
RFC Editor Expires February 25, 2008 [Page 9]
Internet-Draft RFC Errata Process August 2007
record.
4. Act as SSP for Independent Submissions.
5. Send nudge messages (hopefully, automatically) to SSPs for errata
that have been in the Reported stage for a very long time.
3. Transition
There are currently approximately 200 unverified, unposted errata
entries captured in email messages. If and when there is consensus
on the general procedure defined here, the RFC Editor can sort the
pending reports by stream and pass them to the SSPs for further
processing.
4. Security Considerations
It will be necessary to have access control for editing and posting
errata reports. A logged-in SSP would be able to edit and/or post
any pending record in the stream that s/he "owned". However, we
propose that once the SSP has clicked on "Verify and Post" and the
record entry has been committed to the errata database, the SSP would
lose write access to it. This is a safety feature to prevent
inadvertent or malicious changes to the database, even if the
passwords for some SSP logins may become fairly widely known.
However, the RFC Editor would always have write access to posted
entries and could make later changes when necessary.
5. IANA Considerations
There are no IANA considerations for this document.
6. Informative References
[RFC4844] Daigle, L. and Internet Architecture Board, "The RFC
Series and RFC Editor", RFC 4844, July 2007.
RFC Editor Expires February 25, 2008 [Page 10]
Internet-Draft RFC Errata Process August 2007
Appendix A. Possibilities for Posting Errata
Choosing any of these possibilities for posting errata should be
decided by the IETF community and its governing bodies.
1. Brian Carpenter has suggested an approach similar to that used by
W3C: Add a URL to every published RFC that points to its errata
(if any).
For W3C examples, see:
http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/ and
http://www.w3.org/TR/2006/REC-xml-names-20060816
They include the text:
"Please refer to the <errata> for this document, which may
include some normative corrections."
where <errata> is a hyperlink to the list of all errata or a
page that says:
"There are no errata to this document yet."
Similarly, a URL could be added to all (future) RFCs pointing to
where the relevant errata are posted.
2. Another possibility would be to add new errata files to the RFC
repository, e.g., with names of the form: rfcnnnn.err.txt. Such
a file would contain all the errata for the corresponding RFC.
3. As mentioned in Section 1.2, there are HTML versions of RFCs with
errata links; these are currently hosted by tools.ietf.org, but
they could be made available on the RFC Editor Web site as well.
Author's Address
RFC Editor
USC/ISI
4676 Admiralty Way
Marina del Rey, CA 90292
USA
Email: rfc-editor@rfc-editor.org
RFC Editor Expires February 25, 2008 [Page 11]
Internet-Draft RFC Errata Process August 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
RFC Editor Expires February 25, 2008 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-23 21:42:18 |