idnits 2.17.1 draft-rfc-editor-errata-process-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 555. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 566. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 573. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 579. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 20, 2008) is 5813 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4844 (Obsoleted by RFC 8729) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Hagens 3 Internet-Draft S. Ginoza 4 Intended status: Informational R. Braden 5 Expires: November 21, 2008 RFC Editor 6 May 20, 2008 8 RFC Editor Proposal for Handling RFC Errata 9 draft-rfc-editor-errata-process-02 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on November 21, 2008. 36 Abstract 38 This document describes a web-based process for handling the 39 submission, verification, and posting of errata for the RFC Series. 40 The main concepts behind this process are (1) distributing the 41 responsibility for verification to the appropriate organization or 42 person for each RFC stream, and (2) using a Web portal to automate 43 the book-keeping for handling errata. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 1.1. Background on RFC Errata . . . . . . . . . . . . . . . . . 3 49 2. Proposed Errata Process Using the Web Portal . . . . . . . . . 4 50 2.1. Reporting Errata . . . . . . . . . . . . . . . . . . . . . 5 51 2.2. Initial Notification Message . . . . . . . . . . . . . . . 6 52 2.3. Verifying Errata . . . . . . . . . . . . . . . . . . . . . 7 53 2.4. Posting Errata . . . . . . . . . . . . . . . . . . . . . . 7 54 2.5. Errata Announcements . . . . . . . . . . . . . . . . . . . 8 55 3. Role of the RFC Editor . . . . . . . . . . . . . . . . . . . . 8 56 4. Transition . . . . . . . . . . . . . . . . . . . . . . . . . . 9 57 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 58 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 59 7. Informative References . . . . . . . . . . . . . . . . . . . . 10 60 Appendix A. Possibilities for Posting Errata . . . . . . . . . . 11 61 Appendix B. Errata Processing before the Web Portal . . . . . . . 12 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 63 Intellectual Property and Copyright Statements . . . . . . . . . . 14 65 1. Introduction 67 This document describes a new set of the procedures and mechanisms 68 for handling RFC errata, to improve efficiency and accountability of 69 errata processing. The main concepts are (1) distributing 70 responsibility for errata verification to the appropriate body or 71 person for each RFC stream, and (2) using a Web portal to automate 72 the book-keeping task for verifying and posting errata. 74 The errata process assumes the organization of RFC publication into 75 four document streams [RFC4844]: (1) the IETF stream, which includes 76 both working group and individual submissions, (2) the IAB stream, 77 (3) the IRTF stream, and (4) the Independent Submission stream. We 78 propose that personnel representing each stream be responsible for 79 verifying the errata reported for that stream's RFCs. In particular, 80 we propose that one or more stream-specific parties (SSPs) be 81 designated with responsibility for verifying errata for each stream. 83 At the organizational level, the SSPs might be: 85 o IESG for IETF documents 87 o IAB for IAB documents 89 o IRSG for IRTF documents 91 o RFC Editor/Editorial Board for Independent Submissions 93 The IETF stream could be considered to be subdivided by area, so that 94 each Area Director could be an SSP for RFCs originating in that area. 95 The RFC publication process maintains the AD contact information for 96 each RFC, so errata reports for RFCs in the IETF document stream 97 could be sent to the appropriate ADs. 99 1.1. Background on RFC Errata 101 The RFC Editor began to collect and post RFC errata in 2000. The 102 idea was to discourage readers from repeatedly pointing out the same 103 typos in published RFCs. This evolved into the errata verification 104 and posting process described in Appendix B, which was a manually 105 operated, email-based task. 107 Unfortunately, our understanding of the errata problem was wrong in 108 several ways. The number of errors reported turned out to be 109 significantly greater than anticipated, and the process of vetting 110 and posting required more human resources. 112 Another issue with errata is that some of the reported errors are not 113 simply editorial, but rather correct technical contents of RFCs. A 114 savvy implementer of the specification can often, but not always, 115 figure out what was intended by the RFC as published, but technical 116 errors should be announced somehow. Furthermore, posting technical 117 errata for Standards Track documents should always involve the IESG, 118 as a matter of correct process. Technical errata may require much 119 review and discussion among the author(s), Area Directors, and other 120 interested parties. (See [HOW_TO_REPORT] for guidelines regarding 121 editorial vs. technical classification.) 123 We note that allowing technical errata is a slippery slope: there may 124 be a temptation to use errata to "fix" protocol design errors, rather 125 than publishing new RFCs that update the erroneous documents. In 126 general, an erratum is intended to report an error in a document, 127 rather than an error in the design of the protocol or other entity 128 defined in the document, but this distinction may be too imprecise to 129 avoid hard choices. For the IETF stream, these choices should be 130 made by the IESG, and are discussed in their proposed guidelines on 131 errata processing [IESG-Err-Proc]. 133 In summary, errata have become a much larger, more complex, and more 134 important issue than they were originally. This proposal attempts to 135 address these problems. 137 2. Proposed Errata Process Using the Web Portal 139 To manage and automate the reporting, verifying, and posting of 140 errata, the RFC Editor has transitioned to a Web application 141 ("portal"). This Web portal allows for a more uniform reporting 142 process, eases communication among the parties responsible for 143 verification, and automates the posting of errata as soon as they are 144 reported. 146 There are four possible states for an erratum under this proposal: 148 1. Reported - The erratum has been reported but is unverified. 150 2. Verified - The erratum has been edited as necessary and verified. 152 3. Rejected - The erratum was redundant or incorrect and has been 153 discarded. 155 4. Archived - The erratum is not a necessary update to the RFC. 156 However, it should be considered in future revisions of the RFC. 157 (Note that this state is not yet available; it is pending the 158 IESG's statement regarding errata processing [IESG-Err-Proc].) 160 Currently, Reported and Verified errata are posted (see Section 2.4 161 for more details). 163 For more information on the states and their definitions, and the 164 guidelines by which the IESG intends to classify errata into the the 165 above states, see [IESG-Err-Proc]. 167 The Web interface supports the following functions: 169 1. Retrieve -- display all posted errata for a specific RFC number 170 or display a particular erratum by its errata ID number. 172 2. Report -- report a new erratum, as described below. (See 173 [HOW_TO_REPORT] for up-to-date instructions on reporting a new 174 erratum.) 176 3. Edit/Verify/Reject -- used by an SSP to edit the contents of an 177 erratum and change its state. 179 The following sections describe the proposed process in more detail. 181 2.1. Reporting Errata 183 A member of the Internet community (the "reporter") navigates to the 184 RFC errata page [ERRATA_PAGE] and enters the RFC number of the 185 document containing the error. All earlier errata for that RFC are 186 displayed, and the reporter is asked to check that the erratum does 187 not already appear in the full list of errata for any given RFC. 188 This should help prevent multiple reports of the same error. 190 The user then reports the erratum using a Web form to create a report 191 record in the RFC errata database. The report is composed of 192 information provided by the reporter, and is supplemented by data 193 drawn from the primary RFC Editor database. The erratum report 194 record includes the following fields: 196 This information is requested from the reporter: 198 RFC # 199 Type [editorial, technical] 200 Reporter name 201 Reporter email address 202 (Note that the address is provided for communication 203 purposes with the relevant SSPs and authors, but it is 204 not displayed in the online errata report.) 205 Section # 206 Original text 207 Corrected text 208 Notes 210 The above information is supplemented by information pulled from the 211 database: 213 Errata ID number 214 RFC title and associated draft string (if available) 215 Publication Date 216 Author(s) 217 Category ("status") of RFC 218 Source (Working Group Name, IAB, IRTF, or INDEPENDENT) 219 Area (for IETF stream) 220 Stream (IETF, IAB, IRTF, or INDEPENDENT) 221 Verifying Party (SSP Identity) 222 URL to the distinct erratum report 224 Generally, we want the reporter to enter a new erratum using the 225 Original and Corrected Text fields, as this allows for easier 226 verification. The free-text Notes field can be used for providing 227 rationale or for describing those errata that cannot easily be put 228 into the Original/Corrected format. 230 The Report page allows a set number of reports (i.e., 4) for the same 231 RFC to be submitted at the same time, using the Original/Corrected 232 form. By having the user separate the errata entries, the SSP should 233 have an easier time verifying each entry. We also hope that this 234 encourages users to submit only the most valuable errata. 236 The reporter is asked to make a judgment on the errata type -- 237 technical vs. editorial. If the reporter has both editorial and 238 technical errors in the same RFC, the two classes of errata must be 239 entered as separate reports. This initial classification is useful 240 to the SSP; for example, it might allow technical errata to be 241 processed with higher priority than editorial errata, and it allows 242 the RFC Editor to monitor editorial errata to note frequent editorial 243 errors that could possibly lead to improvements in the editorial 244 process. 246 We expect that the reporter will usually make the right technical/ 247 editorial classification, with the aid of published guidelines (see 248 [HOW_TO_REPORT]). However, in case of misclassification by the 249 reporter, the SSP can fix it when logged in as a verifier. 251 2.2. Initial Notification Message 253 Submitting the report triggers an email notification message to the 254 appropriate SSP, the RFC author(s), and the RFC Editor. Including 255 them all as addressees in one message facilitates cooperation in 256 verifying the error. 258 The message includes the information listed in Section 2.1. The SSP 259 could forward the notification email further; for example, an Area 260 Director might forward it to the chair of the responsible working 261 group, if it still exists. 263 In the case of early RFCs for which the RFC Editor does not have 264 associated stream or area information, the reports will be sent to 265 the IESG (as a whole) and the authors. 267 Author email addresses are often out of date. In these cases, the 268 relevant SSPs have the option of seeking current author contact 269 information or relying on other individuals with knowledge of the 270 subject matter to help determine the validity of the errata. 272 2.3. Verifying Errata 274 The initial notification message starts the verification process. 275 The SSP and the authors are expected to determine the validity of the 276 reported erratum, by whatever procedure the SSP or the stream owner 277 determines. The RFC Editor does not intend to (normally) track the 278 verification process. The SSP, not the author(s) or the RFC Editor, 279 has final responsibility for verifying or rejecting each report. 280 This helps to avoid a great deal of complexity and confusion. 282 Each SSP has a login account on the errata portal to edit errata 283 records as necessary. The SSP identity is added to the record and 284 the individual is able to edit, verify, or reject each erratum. 286 The Notes field allows users to submit information in any fashion 287 they like, so there is a possibility of multiple errors being 288 reported in this field. The SSP is able to edit the record and split 289 it into multiple records to maintain one record per erratum, as 290 necessary. 292 Based on experience, we know that some errata reports will require 293 significant email discussion between the reporter and the author(s) 294 and/or SSPs (in particular, the IESG) before the final decision on a 295 record can be made. The final outcome will be captured in the errata 296 entry, and any controversy or explanatory material can be recorded in 297 the Notes field. 299 2.4. Posting Errata 301 As soon as an erratum is submitted, it is available online, i.e., it 302 is posted as described below. The erratum entry is marked Reported 303 until its state is updated by verifiers as described above. 305 In this document, posting an erratum means that it is: 307 1. Available from the RFC errata page: 308 http://www.rfc-editor.org/errata.php. 310 2. Linked to from the results of the RFC search engine: 311 http://www.rfc-editor.org/rfcsearch.html. 313 3. Linked to from some HTML versions of the RFC. For example, see 314 http://tools.ietf.org/html/rfc2119. 316 The state of errata determines whether they are posted. Currently, 317 Reported and Verified errata are posted, and Rejected errata are not 318 posted. However, this can be altered to improve the errata display 319 for readers and implementers. For example, Rejected and Archived 320 errata could be hidden behind a link (as has been suggested). 322 The order in which errata are displayed for a single RFC (e.g., 323 Verified Technical, Reported Technical, Verified Editorial, Reported 324 Editorial) also can be altered to improve the usability. 326 It sometimes happens that there are errata for errata, i.e., earlier 327 postings must be altered. In this case, the RFC Editor can do the 328 update as requested by an SSP or can grant an SSP temporary write 329 access to the record to be updated. 331 There are other possibilities for errata posting that should be 332 considered by the community; see Appendix A. 334 2.5. Errata Announcements 336 The RFC Editor proposes to announce verified technical errata 337 postings to the rfc-distribution list. If the SSP felt the errata 338 was important enough, they might want to submit a note to the ietf- 339 announce list. However, we do not believe it is necessary to 340 inundate the ietf-announce list with mail each time an errata is 341 verified, rejected, or edited. 343 3. Role of the RFC Editor 345 The role of the RFC Editor in errata processing is to: 347 1. Operate the Web portal. 349 2. Maintain the errata database. 351 3. Make changes in previously posted errata at the request of the 352 corresponding SSP, or give the SSP temporary write access to the 353 record. 355 4. Act as SSP for Independent Submissions. 357 5. Send periodic nudge messages to SSPs for errata that are in the 358 Reported state. 360 6. Track SSP and community requests for various features that will 361 make the job of reporting and verifying errata more efficient. 363 4. Transition 365 Errata from the original errata page have been made available from 366 the new Web portal. Generally, they are marked Verified without 367 listing the name of the verifier, as this information was not 368 associated with the errata records until November 2007. 370 Errata that were posted in the pending file (as described in 371 Appendix B) have been made available from the Web portal and are 372 marked as Reported or Verified, as appropriate. Lists of unverified 373 reports have been sent to the appropriate SSPs for review and 374 verification. 376 5. Security Considerations 378 It is necessary to have access control for errata reports. A 379 logged-in SSP is able to edit, verify, or reject any errata report on 380 an RFC that is the product of their stream. However, we propose that 381 once the SSP has submitted an erratum's final state (Verified or 382 Rejected) and the record entry has been committed to the errata 383 database, the SSP will lose write access to it. This is a safety 384 feature to prevent inadvertent or malicious changes to the database, 385 even if the passwords for some SSP logins may become fairly widely 386 known. However, the RFC Editor will always have write access to 387 posted entries and can make later changes if necessary. 389 The RFC Editor has chosen to use HTTPS as a reasonably secure login 390 mechanism. Also, the RFC Editor has obtained a signed certificate 391 from a CA for the errata verification pages, so that SSPs have 392 confidence that they are logging into the RFC Editor site. 394 6. IANA Considerations 396 There are no IANA considerations for this document. 398 7. Informative References 400 [ERRATA_PAGE] RFC Editor, "RFC Errata", February 2008, 401 . 403 [HOW_TO_REPORT] RFC Editor, "How to Report Errata", February 2008, 404 . 406 [IESG-Err-Proc] "Proposed IESG Statement Regarding RFC Errata for 407 IETF Stream RFCs", Work in Progress, April 2008. 409 [RFC4844] Daigle, L. and Internet Architecture Board, "The RFC 410 Series and RFC Editor", RFC 4844, July 2007. 412 Appendix A. Possibilities for Posting Errata 414 Choosing any of these possibilities for posting errata should be 415 decided by the IETF community and its governing bodies. 417 1. Brian Carpenter has suggested an approach similar to that used by 418 W3C: Add a URL to every published RFC that points to its errata 419 (if any). 421 For W3C examples, see: 423 http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/ and 425 http://www.w3.org/TR/2006/REC-xml-names-20060816 427 They include the text: 429 "Please refer to the for this document, which may 430 include some normative corrections." 432 where is a hyperlink to the list of all errata or a 433 page that says: 435 "There are no errata to this document yet." 437 Similarly, a URL could be added to all (future) RFCs pointing to 438 where the relevant errata are posted. 440 2. Another possibility would be to add new errata files to the RFC 441 repository, e.g., with names of the form: rfcnnnn.err.txt. Such 442 a file would contain all the errata for the corresponding RFC. 444 3. As mentioned in Section 2.4, there are HTML versions of RFCs with 445 errata links; these are currently hosted by tools.ietf.org, but 446 they could be made available on the RFC Editor Web site as well. 448 Appendix B. Errata Processing before the Web Portal 450 The following is a summary of the RFC Editor errata verification and 451 posting process prior to the deployment of the Web portal in November 452 2007. The RFC Editor used to: 454 o Review email and relevant RFCs to ensure that the reported errata 455 actually appeared in the RFCs as available from 456 http://www.rfc-editor.org/. This does not mean that the errata 457 were reviewed and deemed correct, only that the reported erronous 458 text appears in the RFC (i.e., without judgment about the reports 459 correctness). 461 o Disentangle multiple errors reported in one message. 463 o Check that each error has not already been posted. 465 o Attempt to determine whether the errata are editorial or 466 technical. 468 o Forward each erratum report to the author(s) of the published RFC. 470 o Track bounce messages (contact information for authors is often 471 out of date) and try to find current contact information. 473 o Forward the message to the relevant ADs if we were unable to find 474 current author contact information. 476 o Track follow-up email. 478 o Figure out how to post when reporters/authors do not submit errata 479 in the original/new format. This is often a problem when 480 reporters submit email claiming an error, but do not offer 481 corrective text. 483 o Post verified errata and discard rejected errata. 485 There were three possible states for processing an erratum: 487 1. Reported - the erratum has been reported but is unverified. 489 2. Verified - the erratum has been edited as necessary and verified. 491 3. Rejected - the erratum was redundant or incorrect and has been 492 discarded. 494 Generally speaking, an erratum was posted when it was verified. 495 (Note that "posted" here means available online from the original RFC 496 errata page; the list of posting locations in Section 2.4 includes 497 those developed after 2000.) The exceptions were the "pending 498 errata", whose processing was delayed as described below. 500 During 2006, the RFC Editor was understaffed for the growing load of 501 RFCs to be published (see 502 http://www.rfc-editor.org/num_rfc_year.html). To catch up, the RFC 503 Editor suspended all activities not directly related to RFC 504 publication. As a result, more than a year's worth of errata reports 505 had not been verified or posted. As resources allowed, the RFC 506 Editor provided the following interim measures: 508 1. Made available, from the RFC Editor Web site, a mailbox text file 509 (mbox format) of all errata-related email (ftp:// 510 ftp.rfc-editor.org/in-notes/pending-errata/pending-errata.msgs). 512 2. For those few errata that did get added to the errata database, 513 marked them UNVERIFIED. 515 Authors' Addresses 517 Alice Hagens 518 RFC Editor 519 4676 Admiralty Way 520 Marina del Rey, CA 90292 521 USA 523 Email: rfc-editor@rfc-editor.org 525 Sandy Ginoza 526 RFC Editor 527 4676 Admiralty Way 528 Marina del Rey, CA 90292 529 USA 531 Email: rfc-editor@rfc-editor.org 533 Robert Braden 534 RFC Editor 535 4676 Admiralty Way 536 Marina del Rey, CA 90292 537 USA 539 Email: rfc-editor@rfc-editor.org 541 Full Copyright Statement 543 Copyright (C) The IETF Trust (2008). 545 This document is subject to the rights, licenses and restrictions 546 contained in BCP 78, and except as set forth therein, the authors 547 retain all their rights. 549 This document and the information contained herein are provided on an 550 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 551 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 552 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 553 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 554 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 555 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 557 Intellectual Property 559 The IETF takes no position regarding the validity or scope of any 560 Intellectual Property Rights or other rights that might be claimed to 561 pertain to the implementation or use of the technology described in 562 this document or the extent to which any license under such rights 563 might or might not be available; nor does it represent that it has 564 made any independent effort to identify any such rights. Information 565 on the procedures with respect to rights in RFC documents can be 566 found in BCP 78 and BCP 79. 568 Copies of IPR disclosures made to the IETF Secretariat and any 569 assurances of licenses to be made available, or the result of an 570 attempt made to obtain a general license or permission for the use of 571 such proprietary rights by implementers or users of this 572 specification can be obtained from the IETF on-line IPR repository at 573 http://www.ietf.org/ipr. 575 The IETF invites any interested party to bring to its attention any 576 copyrights, patents or patent applications, or other proprietary 577 rights that may cover technology that may be required to implement 578 this standard. Please address the information to the IETF at 579 ietf-ipr@ietf.org.