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
- Re: RFC Errata proposals -- a missing piece SM
- RFC Errata proposals -- a missing piece John C Klensin
- Re: RFC Errata proposals -- a missing piece John C Klensin
- Re: RFC Errata proposals -- a missing piece Bob Braden
- Re: RFC Errata proposals -- a missing piece Paul Hoffman
- Re: RFC Errata proposals -- a missing piece Frank Ellermann
- Re: RFC Errata proposals -- a missing piece Paul Hoffman