Re: RFC Errata: when to file, and when not to

"Martin J. Dürst" <> Thu, 02 August 2012 10:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0CE8F21F8E31 for <>; Thu, 2 Aug 2012 03:28:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -100.41
X-Spam-Status: No, score=-100.41 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id b7ChP86yZvgJ for <>; Thu, 2 Aug 2012 03:28:54 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A40B921F8E2F for <>; Thu, 2 Aug 2012 03:28:52 -0700 (PDT)
Received: from ([]) by (secret/secret) with SMTP id q72AShDS029049 for <>; Thu, 2 Aug 2012 19:28:43 +0900
Received: from (unknown []) by with smtp id 3de1_096e_d5827d6a_dc8c_11e1_8faa_001d096c5782; Thu, 02 Aug 2012 19:28:42 +0900
Received: from [IPv6:::1] ([]:41530) by with [XMail 1.22 ESMTP Server] id <S15EB14F> for <> from <>; Thu, 2 Aug 2012 19:28:46 +0900
Message-ID: <>
Date: Thu, 02 Aug 2012 19:28:38 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Barry Leiba <>
Subject: Re: RFC Errata: when to file, and when not to
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: IETF discussion list <>
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 02 Aug 2012 10:28:55 -0000

Hello Barry,

Thanks for explanation about errata, which must have been caused at 
least in part by an erratum that I submitted recently.

Just for the record, I want to mention that the errata report form at has a "type" field with two 
categories, "Technical" and "Editorial", where "Editorial" is defined in 
the help popup as: "spelling, grammar, punctuation, or syntax error that 
does not affect the technical meaning". This would directly contradict 
your "Criterion 2 means that minor typos are NOT appropriate errata."

However, my main point is a different one. At the end of your mail, you 

 > In particular, the errata system is NOT meant to be used as an issue
 > tracker; please do not submit errata reports with the *intent* that 
they be
 > marked as "Held for Document Update", to be used as an issue list later.
 >   We have mailing lists, issue trackers, and wikis for this purpose.

Of course we have mailing lists, issue trackers, and wikis, but the 
problem is that none of them are for RFCs. And if there's a tracker for 
a bis version, it's not necessarily easy to find from the RFC.

Actually, even if somebody finds the -bis draft, in many (if not most) 
cases, these drafts don't contain pointers to issue trackers, wikis, or 
the like (a pointer to a mailing list, at least indirectly via the 
mention of a WG, should be there in most cases, I guess).

The question then comes up on whether we can do better. And my guess is 
that in this day and age of linked information, we should be able to do 
better. With the tools version of an RFC, which is quickly becoming the 
preferred version of many, it's already easy to find errata.

There are certainly many open questions when moving to better linking of 
the relevant information, such as "who approves it", "what's 'official' 
(wiki, issue tracker,...) and what not", and so on.

On 2012/08/01 8:27, Barry Leiba wrote:
> We've been seeing a lot of inappropriate errata reports, made by
> well-meaning people who, surely, think their reports are useful, even
> important.  These aren't free: they take time to process, and they form
> clutter in the errata system, obscuring the ones that do fit into what
> errata are meant to be.

These are certainly problems, and we have to work on improving the 
situation. Sending all the errata to the IESG without triage (which 
seems to be done for the "Technical" ones; not sure it's also true for 
the "Editorial" ones) definitely may not be the best for the busy people 
on the IESG to spend their time.

Regards,   Martin.