Re: Proposed IESG Statement Regarding RFC Errata for IETF Sream RFCs
Marshall Eubanks <tme@multicasttech.com> Wed, 16 April 2008 17:06 UTC
Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A95F3A6FAE; Wed, 16 Apr 2008 10:06:48 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B13528C1FF for <ietf@core3.amsl.com>; Wed, 16 Apr 2008 10:06:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.74
X-Spam-Level:
X-Spam-Status: No, score=-2.74 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOjF2RPtCrfA for <ietf@core3.amsl.com>; Wed, 16 Apr 2008 10:06:41 -0700 (PDT)
Received: from multicasttech.com (lennon.multicasttech.com [63.105.122.7]) by core3.amsl.com (Postfix) with ESMTP id DC0B63A6C4F for <ietf@ietf.org>; Wed, 16 Apr 2008 10:06:10 -0700 (PDT)
Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 11037080; Wed, 16 Apr 2008 13:06:46 -0400
Message-Id: <77E5761D-99ED-4F7E-ADED-78B21215E91A@multicasttech.com>
From: Marshall Eubanks <tme@multicasttech.com>
To: IETF Discussion <ietf@ietf.org>
In-Reply-To: <20080416151659.F075C3A6C0B@core3.amsl.com>
Mime-Version: 1.0 (Apple Message framework v919.2)
Subject: Re: Proposed IESG Statement Regarding RFC Errata for IETF Sream RFCs
Date: Wed, 16 Apr 2008 13:06:33 -0400
References: <20080416151659.F075C3A6C0B@core3.amsl.com>
X-Mailer: Apple Mail (2.919.2)
Cc: RFC Editor <rfc-editor@rfc-editor.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
Stripping out a raft of cc:s, a nit and a comment in line. On Apr 16, 2008, at 11:16 AM, The IESG wrote: > The IESG is considering the following statement to guide the > handling of > RFC Errata for IETF Stream RFCs. Your review and comment on this > policy > is encouraged. > > Russ Housley > on Behalf of the IESG > > > - - - - - - - - - - - - > > > Proposed IESG Statement Regarding RFC Errata for IETF Sream RFCs > > 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 had already been approved. > > After an erratum is reported, a report will be sent to the authors > 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 for the area will review it, either > themselves or by delegating, and classify it as falling under > one of the following states: > > o Approved - The errata is appropriate under the criteria below and > should be available to implementors or people deploying the RFC. > > o Rejected - The errata is in error, or proposes a change to the > RFC > that is clearly inappropriate to do with an errata. In the > latter > case, if the change is to be considered for future updates of the > document, it should be proposed using other channels than errata, > such as a WG mailing list. > > o Archived - The errata is not a necessary update to the RFC. > However, any future update of the document should consider this > errata, 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 Archived. > > 3. Errata on obsolete RFCs should treated the same as errata on > non-obsolete RFC where there is strong evidence that some > people are still making use of the related technology. > > 4. Trivial grammar corrections should be Archived. > > 5. Ugly typos that are clearly bogus typos but would not cause any > confusions to implementation or deployments should be Archived. > > 6. Changes which are simply stylistic issues or simply make things > read better should be Archived. > > 7. Changes that modified the working of a protocol to something > that I would suggest s/modified/modify/ > > might be different from the intended consensus when the document > was approved should be either Archived or Rejected. Deciding > between these two depends on judgment. Changes that are clearly > modifications to the intended consensus, or are of major > importance, should be Rejected. In unclear situations, small > changes can be Archived. I don't know about this - strip out the "or" clause and you get Changes that ... are of major importance, should be Rejected. Are you intending to say that only unimportant errata will be accepted ? Regards Marshall > > > 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 Archived. > > _______________________________________________ > IETF mailing list > IETF@ietf.org > https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
- Proposed IESG Statement Regarding RFC Errata for … The IESG
- Re: Proposed IESG Statement Regarding RFC Errata … Marshall Eubanks
- Re: Proposed IESG Statement Regarding RFC Errata … Jeffrey Hutzelman
- Re: Proposed IESG Statement Regarding RFC Errata … Brian E Carpenter
- Re: Proposed IESG Statement Regarding RFC Errata … Frank Ellermann
- Re: Proposed IESG Statement Regarding RFC Errata … Pekka Savola
- Re: Proposed IESG Statement Regarding RFC Errata … Jari Arkko
- Re: Proposed IESG Statement Regarding RFC Errata … Alexey Melnikov
- Re: Proposed IESG Statement Regarding RFC Errata … Paul Hoffman
- Re: Proposed IESG Statement Regarding RFC Errata … Lisa Dusseault
- Re: Proposed IESG Statement Regarding RFC Errata … Paul Hoffman
- RE: Proposed IESG Statement Regarding RFC Errata … David Harrington
- Re: Proposed IESG Statement Regarding RFC Errata … John C Klensin
- Re: Proposed IESG Statement Regarding RFC Errata … Bob Hinden
- Re: Proposed IESG Statement Regarding RFC Errata … Bill McQuillan
- Re: Proposed IESG Statement Regarding RFC Errata … Russ Housley
- Re: Proposed IESG Statement Regarding RFC Errata … Brian E Carpenter
- Re: Proposed IESG Statement Regarding RFC Errata … Paul Hoffman
- Re: Proposed IESG Statement Regarding RFC Errata … Sabahattin Gucukoglu
- Re: Proposed IESG Statement Regarding RFC Errata … Frank Ellermann
- RE: Proposed IESG Statement Regarding RFC Errata … Yaakov Stein
- Re: Proposed IESG Statement Regarding RFC Errata … Marshall Eubanks