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

Abdussalam Baryun <> Thu, 02 August 2012 08:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C44CC21F881D for <>; Thu, 2 Aug 2012 01:50:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.483
X-Spam-Status: No, score=-3.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id i9LX82o4Icc1 for <>; Thu, 2 Aug 2012 01:50:21 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id F01E721F885D for <>; Thu, 2 Aug 2012 01:50:10 -0700 (PDT)
Received: by vbbez10 with SMTP id ez10so131730vbb.31 for <>; Thu, 02 Aug 2012 01:50:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mXSC/HujAWODbGcPU14BQEmOWDGo5HSfVEL3rWA9Swg=; b=fVQBQSpGlHPptaLaR0bfOv5JSQeMxmhL20AH/f/ktmFzVWQ/lxKez9SPPbOBXXuNas ej6GNy12CC2HLoO16g2HGLFerSJV8vH7kUcfqjgDWs7zq8xMAQbnuG2Z7W98sVc1YH+G pm+4pGQ57FVDybJpYCoTGgSnx4aC1mMpeRZ1pT1DD4gqJ5BTS64i4PJB/aLIh66vzxah QiRg2lZRgd6ME7bJXpuFjduWU36J925xQCO4i000JuUZqpdL4WNzdpduY1oR1wRohg9V ZNCqTNxC967dcWtFlZYjw/UuWDXVDP90eoYPbGWOIOWJe3Y1DmFSQI8XO20ZFOUPxdoS 92EQ==
MIME-Version: 1.0
Received: by with SMTP id bw16mr16799131vdb.129.1343897410444; Thu, 02 Aug 2012 01:50:10 -0700 (PDT)
Received: by with HTTP; Thu, 2 Aug 2012 01:50:10 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Thu, 2 Aug 2012 10:50:10 +0200
Message-ID: <>
Subject: Re: RFC Errata: when to file, and when not to
From: Abdussalam Baryun <>
Content-Type: text/plain; charset=ISO-8859-1
Cc: ietf <>
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 08:50:21 -0000

Hi Barry,

Could you refer to a RFC that states your below information or
procedure, if there is not, I recommend some one doing procedure
drafts to take it over. Please note that ALL reports from any
participant should be useful for IETF community and system. Even if
he/she misunderstood, this does not mean that he/she is not useful,
that means the IETF system/community needs to adjust to help
participants to understand and follow.

For me I will note your procedure so that I will not report wrongly,
but I will continue reporting my comments/views, and hope if some
thing is wrong I get a reply like your, thanking you,

IETF Particpant
The mission of the Internet Engineering Task Force is to make the
Internet work better by producing high-quality and relevant technical
documents that influence the way people design, use, and manage the

> 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.
> So I wanted to clarify what's meant to be reported, and what's not.
> A valid erratum, one that the IESG will mark as "Verified", mets two
> criteria:
> 1. It is truly an *error* in the original document.  That is, it would
> have been considered an error *at the time the document was
> published*, had it been noticed at the time.
> 2. It is important, an error that would cause someone to misread the
> document in a significant way, causing implementation or deployment
> problems, or other serious issues.
> Criterion 1 means that anything that is "wrong" because of situations
> or discussions that have come up since publication are not appropriate
> errata.  Consider the differences among these:
> - (a) Someone realizes that the document forgot to specify the valid
> range of a value.
> - (b) Someone realizes that the range specified did not correctly
> reflect the result of the discussion at the time (the change got
> missed and no one noticed).
> - (c) Someone realizes that the range specified causes problems in
> practice, but we didn't know that would happen when we published the
> document.
> (a) and (b) are valid errata, and should get marked as "Verified".
> (c) is NOT valid for the errata system, and really ought to be marked
> as "Rejected".
> Criterion 2 means that minor typos are NOT appropriate errata.  The
> IESG will mark these as "Held for Document Update", but, really, there
> is no need to say that "an" should be "and", that a comma is missing
> (unless it seriously affects the meaning and is likely to be
> mis-read), or that "concensus" is misspelled (as here).  Again,
> consider the differences:
> - (a) "The server will now respond with an error code," where "now"
> should have been "not".
> - (b) "The server will not repond with an error code," where "repond"
> should have been "respond".
> - (c) "The server will not respond with and error code," where "and"
> should have been "an".
> (a) is the only valid one here.  There's no real value in recording
> the others as errata.
> 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.
> Barry, Applications AD