Network Working Group C. Jennings Internet-Draft Cisco Intended status: BCP November 9, 2009 Expires: May 13, 2010 IESG Errata Processing draft-jennings-errata-00 Abstract This brief note discusses plans the IESG is considering on errata processing. It is not intended to become an RFC but is only a draft for the IESG to solicit input from the community on how the IESG to should handle errata. Status of This Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 May 13, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Jennings Expires May 13, 2010 [Page 1] Internet-Draft Errata November 2009 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. 1. Introduction The RFC editor has instigated a new errata process and as part of this the IESG will need to decide how to approve errata. The IESG is considering the following guidelines to be used for approving errata on documents in the IETF stream. 2. Proposed IESG Statement These are strong guidelines and not immutable rules. Common sense and good judgment should be used by the IESG to decide what is the right thing to do. Errata are meant to fix "bugs" in the specification and should not be used to change what the community meant when it approved the RFC. These guidelines only apply to errata on RFCs in the IETF stream. They apply to new errata and not errata that have already been approved. After an erratum is reported, a report will be sent to the authors, chairs, and Area Directors (ADs) of the WG in which it originated. If the WG has closed or the document was not associated with a WG, then the report will be sent to the ADs for the Area most closely associated to the subject matter. The ADs are responsible for ensuring review; they may delegate the review or perform it personally. The reviewer will classify the erratum as falling under one of the following states: o Approved - The erratum is appropriate under the criteria below and should be available to implementors or people deploying the RFC. o Rejected - The erratum is in error, or proposes a change to the RFC that should be done my publishing a new RFC that replaces the current RFC. In the latter case, if the change is to be considered for future updates of the document, it should be proposed using channels other than the errata process, such as a WG mailing list. o Hold for Document Update - The erratum is not a necessary update to the RFC. However, any future update of the document might consider this erratum, and determine whether it is correct and merits including in the update. Guidelines for review are: Jennings Expires May 13, 2010 [Page 2] Internet-Draft Errata November 2009 1. Only errors that could cause implementation or deployment problems or significant confusion should be Approved. 2. Things that are clearly wrong but could not cause an implementation or deployment problem should be Hold for Document Update. 3. Errata on obsolete RFCs should be treated the same as errata on RFCs that are not obsolete where there is strong evidence that some people are still making use of the related technology. 4. Trivial grammar corrections should be Hold for Document Update. 5. Typographical errors which would not cause any confusions to implementation or deployments should be Hold for Document Update. 6. Changes which are simply stylistic issues or simply make things read better should be Hold for Document Update. 7. Changes that modify the working of a protocol to something that might be different from the intended consensus when the document was approved should be either Hold for Document Update or Rejected. Deciding between these two depends on judgment. Changes that are clearly modifications to the intended consensus, or involve large textual changes, should be Rejected. In unclear situations, small changes can be Hold for Document Update. 8. Changes that modify the working of a process, such as changing an IANA registration procedure, to something that might be different from the intended consensus when the document was approved should be Rejected. 3. Suggested Tool Changes Future RFC's from IETF track should include a line that tell people reading the RFC were they might find errata. When the RFC was first published it would include text along the lines of: There may be errata and other information for this RFC which can be found at http://www.rfc-editor.org/errata/rfcXXXX This errata list should show just Approved errata on the first page - perhaps with links to pages with other types such as Rejected or Hold for Document Update. When searching for all errata it would be nice to be able to filter by area and by working group name. It would also be nice to be able to filter on Type and Status. Ideally the results of a search could Jennings Expires May 13, 2010 [Page 3] Internet-Draft Errata November 2009 be sorted by Date-Reported, RFC number, or by errata submitter name. 4. IANA Considerations This draft has no IANA considerations. 5. Acknowledgements and Thanks Several members of IESG sent comments but special thanks to Sandy Ginoza who found and fixed many mistakes in this text. 6. Security Considerations Too many to discuss. Author's Address Cullen Jennings Cisco 170 West Tasman Drive MS: SJC-21/2 San Jose, CA 95134 USA Phone: +1 408 421-9990 EMail: fluffy@cisco.com Jennings Expires May 13, 2010 [Page 4]