Re: RFC Errata proposals -- a missing piece

"Frank Ellermann" <nobody@xyzzy.claranet.de> Mon, 02 June 2008 21:36 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 0CA2B3A695C; Mon, 2 Jun 2008 14:36:58 -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 785C83A67A6 for <ietf@core3.amsl.com>; Mon, 2 Jun 2008 14:36:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.578
X-Spam-Level:
X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, 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 n2FHxese4CJi for <ietf@core3.amsl.com>; Mon, 2 Jun 2008 14:36:55 -0700 (PDT)
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by core3.amsl.com (Postfix) with ESMTP id 7EEEB3A6A42 for <ietf@ietf.org>; Mon, 2 Jun 2008 14:36:10 -0700 (PDT)
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1K3HhK-0001t2-Hu for ietf@ietf.org; Mon, 02 Jun 2008 21:36:10 +0000
Received: from hmbg-d9b88e29.pool.mediaways.net ([217.184.142.41]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf@ietf.org>; Mon, 02 Jun 2008 21:36:10 +0000
Received: from nobody by hmbg-d9b88e29.pool.mediaways.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf@ietf.org>; Mon, 02 Jun 2008 21:36:10 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: ietf@ietf.org
From: Frank Ellermann <nobody@xyzzy.claranet.de>
Subject: Re: RFC Errata proposals -- a missing piece
Date: Mon, 02 Jun 2008 23:37:40 +0200
Organization: <http://purl.net/xyzzy>
Lines: 49
Message-ID: <g21p40$hc9$1@ger.gmane.org>
References: <57024274DF0B1306D64011FC@p3.JCK.COM> <p06240804c46a09156f43@[10.20.30.162]>
Mime-Version: 1.0
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: hmbg-d9b88e29.pool.mediaways.net
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1914
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1914
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Frank Ellermann <hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com>
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

Paul Hoffman wrote:

>> 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.
 
> The idea that updates appear in the Errata database is a
> good one.  As to your proposal: why make it temporary?

I don't see the point.  Folks often find an RFC on the IETF
tools server, the HTML version has any obsoleted / updated
by info.  Additionally it has a link to any errata, but for
this discovery method errata are not necessary to find the
obsoleted by / updated by info.

They might also find the RFC meta data with the RFC editor 
search engine, e.g., <http://purl.net/net/rfc/3700> or in
some Wikis [[purlnet:rfc/3700|RFC 3700]].  Same situation
as above, the RFC meta data directly offers any available
obsoleted by / updated by / errata info.

If what you propose boils down to "the errata should have a
backlink to the HTML version and/or to the RFC meta data"
it is of course fine, that is one simple global fix to the
errata user interface.

Apparently John's proposal was about the at least 60 days
between the approval of an obsoleting / updating RFC, and
the time when it gets its number.  For RFCs blocked by a
MISSREF that could be years or forever.  For RFCs killed
by an appeal it is forever, intentionally.

In both cases abusing the errata procedure to circumvent
RFC 2026 would be just that, net abuse.  And it is already
easy enough for folks risking it anyway, for an example see
the 1123 RFC errata - hopefully IDNAbis will sanction this
stunt in a real standards track RFC.

 Frank

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