Re: Old Errata

John C Klensin <> Mon, 12 September 2016 17:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 16C50127077 for <>; Mon, 12 Sep 2016 10:36:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.408
X-Spam-Status: No, score=-3.408 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.508] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8zSsD13kTlaV for <>; Mon, 12 Sep 2016 10:35:57 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 21B2D126FDC for <>; Mon, 12 Sep 2016 10:35:57 -0700 (PDT)
Received: from [] (helo=JcK-HP8200) by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1bjV98-000InM-De; Mon, 12 Sep 2016 13:35:54 -0400
Date: Mon, 12 Sep 2016 13:35:49 -0400
From: John C Klensin <>
To: Loa Andersson <>, Yoav Nir <>, IETF Discussion Mailing List <>
Subject: Re: Old Errata
Message-ID: <9AB5C86B88A8BFFABA4297BA@JcK-HP8200>
In-Reply-To: <>
References: <> <>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
Archived-At: <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 12 Sep 2016 17:36:01 -0000

--On Monday, September 12, 2016 11:56 +0200 Loa Andersson
<> wrote:

> Yoar,
> I looked at this - to see if I missed something - and the
> picture that
> comes over is
> Year    number of errata   working group
> 2005    1                  tewg
> 2010    5                  nsfv4
> 2011    1                  nsfv4
> 2012    1                  nsfv4
> 2013    11                 Legacy (gen), Poisson (gen), krb-wg
> (sec),
>                             mext (int), nsfv4, non-wg (sec) x
> 2,
>                             keyprov(sec) behave (tsv), non-wg
> (gen),
>                             dane (sec)
> 2014     35                many wg's
> 2015     57                many wg's
> 2016    114                many wg's
> I think there are one problem here that need to have some type
> of management action. The tewg, nsfv4 and of the wg's with
> errata from 2013 only dane is still active.

> The ADs might have to point to someone to resolve the (oldest)
> errata. Or errata that belong to closed wg's.

As former co-chair of one of the WGs listed, I don't remember
ever having been told about this
(  If I
had been, or were able to comment on the erratum now (there does
not appear to be any way in the system for me to do that), I
would have said that using an erratum to change (not actually
correct, because it was correct when the RFC was published) an
email address would rank fairly high on the "pointless" scale...
at least until we turn RFCs from archival to living documents or
invent a magical mechanism that warns anyone opening an RFC that
there are relevant errata.... even if the copy of the RFC they
open was copied from the archive years ago onto a machine that
is not connected to the Internet.

Part of the point is that our Status and Type categories are
really not up to the job (something that has been discussed
extensively in the past with, AFAIK, no resolution).   Given the
current categories, just leaving some documents in "Reported"
forever might be the right disposition.  If we are going to use
errata to make minor technical changes, then we probably should
have a Status of "Sure, but there needs to be another way to
notify people about this issue", maybe with an appropriate
Action number in that tracker.  It is also tempting to suggest
that the "Type" for this kind of erratum should be "smells of
dead fish": certainly it is not "Editorial" because the RFC was
absolutely correct --technically, operationally, and
editorially-- when written.

Seems to me that just keeping an alias or link until a few years
after the relevant RFC becomes obsolete would be a lot less

I doubt this is the only case -- the errata filing system
doesn't have a great track record for S/N ratio and I, at least,
would much prefer to have ADs paying attention to WGs and
processing of current documents rather than studying the errata
files looking for loose ends.