One document matched: draft-jennings-errata-00.txt

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]