MIME-Version: 1.0
In-Reply-To: <5256BF9BC9AE13013F066C4E@JcK-HP8200.jck.com>
References: <CALaySJKV96tdXhzfPD1e1Mro_+gp5aDarF7Z06QrA+iQtnHkLw@mail.gmail.com>
 <501A5656.2050407@it.aoyama.ac.jp> <501BEC0D.1060404@tana.it>
 <009101cd7476$bb522c20$4001a8c0@gateway.2wire.net>
 <599B1629-543A-49BC-A0E7-FA2096C538AD@checkpoint.com>
 <03e701cd749f$73891c40$4001a8c0@gateway.2wire.net> <50229D32.8000605@tana.it>
 <006701cd7606$17ff48a0$4001a8c0@gateway.2wire.net>
 <CAKHUCzzsf6veDR+uwxnMw4Koh0Kj7FqoQpsUbENMb_r3v0G89A@mail.gmail.com>
 <5256BF9BC9AE13013F066C4E@JcK-HP8200.jck.com>
Date: Thu, 9 Aug 2012 12:35:41 +0100
Message-ID: <CAKHUCzza0ba9eDsEHF+y_icmeWTB8Y=3vb3zw83dGi+4-uh77Q@mail.gmail.com>
Subject: Re: RFC Errata: when to file, and when not to
From: Dave Cridland <dave@cridland.net>
To: John C Klensin <john-ietf@jck.com>
Content-Type: multipart/alternative; boundary=0016e6de002296006004c6d3a0f9
Cc: ietf@ietf.org, Alessandro Vesely <vesely@tana.it>
Precedence: list

--0016e6de002296006004c6d3a0f9
Content-Type: text/plain; charset=ISO-8859-1

It seems entirely reasonable that there needs to be a version available
that's precisely as-published, for legal (and quasi-legal) reasons, as you
say - however, that's the version produced by the RFC Editor, and not the
tools version (which is already non-normative, technically, due to the
markup).

What I'm driving at is whether the right way to handle errata is by
changing the document on tools (perhaps by diff submission). This should
reduce the mechanical workload of errata handling to near-zero, and leave
the judgement calls of whether to accept them as the cost.

--0016e6de002296006004c6d3a0f9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<p>It seems entirely reasonable that there needs to be a version available =
that&#39;s precisely as-published, for legal (and quasi-legal) reasons, as =
you say - however, that&#39;s the version produced by the RFC Editor, and n=
ot the tools version (which is already non-normative, technically, due to t=
he markup).</p>

<p>What I&#39;m driving at is whether the right way to handle errata is by =
changing the document on tools (perhaps by diff submission). This should re=
duce the mechanical workload of errata handling to near-zero, and leave the=
 judgement calls of whether to accept them as the cost.</p>


--0016e6de002296006004c6d3a0f9--