[From nobody Thu Jul 31 07:53:03 2008 Return-Path: <ietf-bounces@ietf.org> Received: from murder ([unix socket]) by eikenes (Cyrus v2.2.13-Debian-2.2.13-13ubuntu3) with LMTPA; Thu, 31 Jul 2008 09:38:33 +0200 X-Sieve: CMU Sieve 2.2 Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9F15939E6E1 for <harald@alvestrand.no>; Thu, 31 Jul 2008 09:38:33 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JW4EHT58EiNI for <harald@alvestrand.no>; Thu, 31 Jul 2008 09:38:32 +0200 (CEST) X-Greylist: domain auto-whitelisted by SQLgrey-1.6.8 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2049339E6A3 for <harald@alvestrand.no>; Thu, 31 Jul 2008 09:38:32 +0200 (CEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81F1C28C1E9; Thu, 31 Jul 2008 00:37:55 -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 ADF8928C1C5; Thu, 31 Jul 2008 00:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 GMkFf+gU4lpY; Thu, 31 Jul 2008 00:37:53 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by core3.amsl.com (Postfix) with ESMTP id 6C02128C1A0; Thu, 31 Jul 2008 00:37:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8A23039E6D7; Thu, 31 Jul 2008 09:37:31 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCZCLqxkLmlG; Thu, 31 Jul 2008 09:37:30 +0200 (CEST) Received: from [192.168.16.102] (unknown [130.129.65.252]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 1CBC739E6A3; Thu, 31 Jul 2008 09:37:30 +0200 (CEST) Message-ID: <48916BC5.90608@alvestrand.no> Date: Thu, 31 Jul 2008 08:37:41 +0100 From: Harald Alvestrand <harald@alvestrand.no> User-Agent: Thunderbird 1.5.0.14ubu (X11/20080724) MIME-Version: 1.0 To: "The IESG (by way of Russ Housley <housley@vigilsec.com>)" <iesg@ietf.org> Subject: Re: IESG Processing of RFC Errata for the IETF Stream References: <20080730182746.69CB13A695B@core3.amsl.com> In-Reply-To: <20080730182746.69CB13A695B@core3.amsl.com> Cc: ietf@ietf.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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ietf-bounces@ietf.org Errors-To: ietf-bounces@ietf.org The IESG (by way of Russ Housley <housley@vigilsec.com>) wrote: > The attached describes the manner in which the IESG will be > processing RFC Errata for the IETF Stream. The current tools on the > RFC Editor site support "approved" and "rejected", but they need to > be updated to also permit "hold for document update" as errata states. > > Thanks, > IESG Secretariat > > ------------------------------ > > 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. I assume that these will be made prominently visible in the RFC Editor's errata list. > > 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. I assume that these errata will not be visible in the RFC Editor's errata 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. Are these intended to be visible in the errata list, or not? (I would prefer them to be visible.) > > 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. What's the "Else" here - if there is no such strong evidence, is the errata Accepted under a different set of conditions, Rejected or Hold for Document Update? (I would prefer the latter, unlikely as such an event may be, if my interpretation of intended visibility is right). Harald _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ]