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 for this document, which may include some normative corrections." where 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]