IESG Errata Processing
draft-jennings-errata-01

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 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:

• Approved - The erratum is appropriate under the criteria below and should be available to implementors or people deploying the RFC.
• 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.
• 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:

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 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