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

Paul Hoffman <paul.hoffman@vpnc.org> Thu, 17 April 2008 16:24 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 4E5DD3A6F07; Thu, 17 Apr 2008 09:24: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 4B06C3A6DC3; Thu, 17 Apr 2008 09:24:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.743
X-Spam-Level:
X-Spam-Status: No, score=-1.743 tagged_above=-999 required=5 tests=[AWL=0.856, 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 ib3Cg+S4zzLX; Thu, 17 Apr 2008 09:24:56 -0700 (PDT)
Received: from balder-227.proper.com (unknown [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id DB72F3A6877; Thu, 17 Apr 2008 09:24:55 -0700 (PDT)
Received: from [10.20.30.162] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3HGPSnf078083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Apr 2008 09:25:32 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: <p06240806c42d289ad212@[10.20.30.162]>
In-Reply-To: <A5B39114-0706-4BE1-9E53-68333E077B26@osafoundation.org>
References: <20080416151659.F075C3A6C0B@core3.amsl.com> <p06240803c42d09f3a323@[10.20.30.249]> <A5B39114-0706-4BE1-9E53-68333E077B26@osafoundation.org>
Date: Thu, 17 Apr 2008 09:25:26 -0700
To: Lisa Dusseault <lisa@osafoundation.org>
From: Paul Hoffman <paul.hoffman@vpnc.org>
Subject: Re: Proposed IESG Statement Regarding RFC Errata for IETF Sream RFCs
Cc: ietf@ietf.org, iaoc@ietf.org, iab@iab.org, iesg@ietf.org, IETF Announcement list <ietf-announce@ietf.org>, 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

At 8:45 AM -0700 4/17/08, Lisa Dusseault wrote:
>I can assure you, I at least was anticipating that the IESG (and 
>other people handling errata) would be doing *more* work in 
>classifying errata if we have the three categories.

OK, good. (Well, not good that you were asking for more work...)

>The goal as I see it is to avoid presenting 50 errata on an RFC to a 
>user, without any sorting or focus, when only three of them are 
>crucial to interoperability.  If we overwhelm implementors with more 
>than a page worth of errata, most of which are junk, implementors 
>will be well justified in ignoring errata.

That's a judgement call, one that I would disagree with. It is easy 
to skim a long errata list to weed out the typos; many of us do this 
all the time with the errata for important books we rely on. Even a 
list of 50 (which would be an outlier, I suspect) could be reviewed 
in less than half an hour.

>An important part of the errata handling, therefore, is to make the 
>difference clear to the implementor.  When an implementor clicks 
>"Errata" for an RFC, they should see the short-list of crucial 
>errata and at the end, a link to "Other possible errata" (or other 
>wording). With that kind of interface, I don't think readers of 
>errata need to care about the exact difference between categories: 
>the essential difference, to them, is which ones have been brought 
>to their immediate attention.

That seems OK. However, it is far from clear that the amount of 
effort it will take for the IESG, document authors, WG chairs, and so 
on to make that differentiation is worth it: any serious implementer 
is going to look at both lists anyway to be sure that we didn't 
mis-categorize something important into the second list. I guess I'm 
arguing for less work for all of us at the expense of a bit more 
categorizing of importance for the implementers.

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf