Re: Proposed IESG Statement Regarding RFC Errata for IETF Sream RFCs

Jari Arkko <jari.arkko@piuha.net> Thu, 17 April 2008 07:39 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 36A6A3A6ADD; Thu, 17 Apr 2008 00:39:16 -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 55E9D3A6A23 for <ietf@core3.amsl.com>; Thu, 17 Apr 2008 00:39:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.583
X-Spam-Level:
X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 jYBWIMO2UjPG for <ietf@core3.amsl.com>; Thu, 17 Apr 2008 00:39:13 -0700 (PDT)
Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 451793A6A75 for <ietf@ietf.org>; Thu, 17 Apr 2008 00:39:13 -0700 (PDT)
Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id BF778198788; Thu, 17 Apr 2008 10:39:49 +0300 (EEST)
Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 67D4919871D; Thu, 17 Apr 2008 10:39:49 +0300 (EEST)
Message-ID: <4806FEC6.80702@piuha.net>
Date: Thu, 17 Apr 2008 10:39:50 +0300
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 1.5.0.14ubu (X11/20080306)
MIME-Version: 1.0
To: Marshall Eubanks <tme@multicasttech.com>, Pekka Savola <pekkas@netcore.fi>
Subject: Re: Proposed IESG Statement Regarding RFC Errata for IETF Sream RFCs
References: <20080416151659.F075C3A6C0B@core3.amsl.com> <77E5761D-99ED-4F7E-ADED-78B21215E91A@multicasttech.com>
In-Reply-To: <77E5761D-99ED-4F7E-ADED-78B21215E91A@multicasttech.com>
X-Virus-Scanned: ClamAV using ClamSMTP
Cc: IETF Discussion <ietf@ietf.org>, 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

Marshall, Pekka,

Pekka, you wrote:

> I do not understand an errata that suggests changing the defined
> process should be Archived. Shouldn't this be flat out Rejected?

Right, this seems to be a bug in the text.

> The problem I see with this proposed errata process is that "Archived"
> tries to fill the gap for the need of an issue tracker for substantial
> change suggestions (today these are sent to a subset of authors, WG
> chairs, and/or WG mailing list if active, but are rarely tracked
> systematically).
>
> I don't think the errata process should be used to track substantial
> change proposals. That procedure needs to be separate from the errata
> process, and it the best place for it would probably be at @ietf.org. 

Indeed. But please note that the satement is not to be taken as a
recommendation that substantial change proposals be submitted as errata.
You are quite correct that they should be pursued as WG work, as BOFs,
drafts be written, etc. However, in the event that someone does send an
errata about the redesign of the protocol we need to know how to deal
with it :-)

Marshall you wrote:
> Are you intending to say that only unimportant errata will be accepted ?

No, that was not the intent. What we wanted to convey was that the
magnitude of some changes may be inappropriate for being done as an
errata. A big redesign requires careful thought, review, probably a
number of revisions of proposals, last call review, etc. As an example,
one of my RFCs has a mistake where it uses the wrong protocol number
constant in a checksum calculation. The authors, RFC Editor, and IANA
failed to catch this error when the number allocations were done. This
is clearly an important issue, and getting it wrong would completely
prevent interoperability. But its also something that can be easily
fixed with an errata. But if we wanted to do something bigger, say,
remove a feature or redesign some aspect of the security solution it
would be inappropriate to do so in an errata.

Maybe the text was just wrong. Here's a suggested edit:

OLD:
Changes that are clearly modifications to the intended consensus, or are
of major importance, should be Rejected
NEW:
Changes that are clearly modifications to the intended consensus, or
involve large changes, should be Rejected

Jari

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