Re: RFC Errata proposals -- a missing piece

John C Klensin <john@jck.com> Mon, 02 June 2008 16:40 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 [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E137C28C16E; Mon, 2 Jun 2008 09:40:04 -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 98AA13A6A9A for <ietf@core3.amsl.com>; Mon, 2 Jun 2008 09:40:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.766
X-Spam-Level:
X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599]
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 ninPalC-18Rs for <ietf@core3.amsl.com>; Mon, 2 Jun 2008 09:39:59 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 8F0893A6BC9 for <ietf@ietf.org>; Mon, 2 Jun 2008 09:39:59 -0700 (PDT)
Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1K3D4g-00041z-Ce; Mon, 02 Jun 2008 12:39:58 -0400
Date: Mon, 02 Jun 2008 12:39:57 -0400
From: John C Klensin <john@jck.com>
To: SM <sm@resistor.net>, ietf@ietf.org, rfc-editor@rfc-editor.org
Subject: Re: RFC Errata proposals -- a missing piece
Message-ID: <520675C32B6EBDD171E96124@p3.JCK.COM>
In-Reply-To: <6.2.5.6.2.20080602075408.028f5348@resistor.net>
References: <57024274DF0B1306D64011FC@p3.JCK.COM> <6.2.5.6.2.20080602075408.028f5348@resistor.net>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Disposition: inline
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-Archive: <http://www.ietf.org/pipermail/ietf>
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


--On Monday, 02 June, 2008 08:40 -0700 SM <sm@resistor.net>
wrote:

> Hi John,
> At 03:51 02-06-2008, John C Klensin wrote:
>> I suggest that it would be useful to add an additional
>> explicit state category to the the RFC Editor's list, one
>> that would presumably be handed out of band (although I'd
>> have no objection to having it automated).   The description
>> would read something like the following:
>> 
>>         5. Standards change: When a document has been approved
>>         (via Protocol Action Notice or equivalent) that
>>         updates or obsoletes an existing Standards Track or
>>         BCP document, an erratum entry may be added that
>>         points to the action notice and the approved
>>         Internet-Draft.  This is intended to be a short-lived
>>         entry, providing information to the community for
>>         important cases during the period between IESG
>>         approval and publication of the new RFC.  These
>>         notices are intended to exceptional circumstances and
>>         will be added at the discretion of the RFC Editor
>>         (e.g., in circumstances when it appears that RFC
>>         publication of the new document will be delayed) or
>>         at the request of the IESG or a relevant Area
>>         Director.
> 
> I suggest a minor change to the last sentence to emphasize the
> exceptional circumstances.  Instead of "These notices ...":
> 
>    This state is intended for exceptional circumstances.  The
> erratum entry will be
>    added at the discretion of the RFC Editor (e.g., in
> circumstances when it appears
>    that  RFC publication of the new document will be delayed)
> or at the request of the
>    IESG or a relevant Area Director.

I have no strong preference.  The advantage of treating it as
"exceptional circumstances" is that it would not impose any
workload on the more normal cases in which getting word about
the change out was non-critical.    On the other hand, were it
not for whatever marginal resources that might be needed, having
a forward pointer in errata any time a document or major part of
it was about to be superceded  would certainly not be harmful.

   john

_______________________________________________
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf