Re: RFC Errata: when to file, and when not to
Abdussalam Baryun <abdussalambaryun@gmail.com> Thu, 02 August 2012 08:50 UTC
Return-Path: <abdussalambaryun@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C44CC21F881D for <ietf@ietfa.amsl.com>; Thu, 2 Aug 2012 01:50:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.483
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9LX82o4Icc1 for <ietf@ietfa.amsl.com>; Thu, 2 Aug 2012 01:50:21 -0700 (PDT)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id F01E721F885D for <ietf@ietf.org>; Thu, 2 Aug 2012 01:50:10 -0700 (PDT)
Received: by vbbez10 with SMTP id ez10so131730vbb.31 for <ietf@ietf.org>; Thu, 02 Aug 2012 01:50:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.52.90.144 with SMTP id bw16mr16799131vdb.129.1343897410444; Thu, 02 Aug 2012 01:50:10 -0700 (PDT)
Received: by 10.220.141.200 with HTTP; Thu, 2 Aug 2012 01:50:10 -0700 (PDT)
In-Reply-To: <CADnDZ88fJXk6RprXNSs1HhrLJ-MHVf-R_S2GnbeGFcsCVB36LA@mail.gmail.com>
References: <CADnDZ88fJXk6RprXNSs1HhrLJ-MHVf-R_S2GnbeGFcsCVB36LA@mail.gmail.com>
Date: Thu, 02 Aug 2012 10:50:10 +0200
Message-ID: <CADnDZ8_ZqbvA2CRL0F9+gfGuPWdT9E4Grp-bRaz=aFgkBtDdyA@mail.gmail.com>
Subject: Re: RFC Errata: when to file, and when not to
From: Abdussalam Baryun <abdussalambaryun@gmail.com>
To: barryleiba@computer.org
Content-Type: text/plain; charset="ISO-8859-1"
Cc: ietf <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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>
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, AB 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 Internet. ================================================== > 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 >
- RFC Errata: when to file, and when not to Barry Leiba
- Re: RFC Errata: when to file, and when not to Abdussalam Baryun
- Re: RFC Errata: when to file, and when not to Martin J. Dürst
- Re: RFC Errata: when to file, and when not to Barry Leiba
- Re: RFC Errata: when to file, and when not to Alessandro Vesely
- Re: RFC Errata: when to file, and when not to Barry Leiba
- Re: RFC Errata: when to file, and when not to Alessandro Vesely
- Re: RFC Errata: when to file, and when not to t.p.
- Re: RFC Errata: when to file, and when not to Yoav Nir
- Re: RFC Errata: when to file, and when not to t.p.
- Re: RFC Errata: when to file, and when not to Alessandro Vesely
- Re: RFC Errata: when to file, and when not to t.p.
- Re: RFC Errata: when to file, and when not to Dave Cridland
- Re: RFC Errata: when to file, and when not to John C Klensin
- Re: RFC Errata: when to file, and when not to Dave Cridland
- Re: RFC Errata: when to file, and when not to Yoav Nir
- Re: RFC Errata: when to file, and when not to John C Klensin
- Re: RFC Errata: when to file, and when not to Yoav Nir
- Re: RFC Errata: when to file, and when not to John C Klensin
- RE: RFC Errata: when to file, and when not to Worley, Dale R (Dale)
- Re: RFC Errata: when to file, and when not to Stephan Wenger