[rfc-i] Errata process
touch at isi.edu
Fri Apr 19 08:31:03 PDT 2013
The question is whether errata are the Comments intended by "Request for
Comments", or whether they are intended as pending updates to the doc.
AFAICT, they are the latter - they're not listed as comments, but rather
As such, it is inappropriate to include comments not vetted and approved
by the authors and (where appropriate) the WG and/or IESG.
I know of cases where errata were rejected because they were either
clearly incorrect, created ambiguity, tried to clarify something that
has not been resolved by the community, etc. - or even those that were
clearly inappropriate under the categories provided (e.g., new
extensions that exceeded the intent of the original doc).
Errata ought to catalog document *errors*. They're not a mechanism to
log the ongoing evolution of a protocol, nor comments from the community.
On 4/19/2013 3:52 AM, Martin Rex wrote:
> SM wrote:
>> Heather Flanagan (RFC Series Editor) wrote:
>>> The 'status' (Verified, Held for Document Update, or Rejected) that the
>>> stream manager selects for a given erratum is meant to provide guidance
>>> on this topic. For example, Verified errata "should be available to
>>> implementors or people deploying the RFC". I don't believe it is
>>> explicitly stated anywhere that Verified errata are normative text that
>>> MUST be read with an RFC, but my impression is that is the expectation.
> Preferably *ALL* errata should be available to implementors or people
> deploying the RFC -- including errata that is classified as rejected.
> A non-marginal amounto of useful errata is "politically rejected".
>> A RFC is said to be immutable. Some people will read the errata and
>> some people won't. Some people will understand the "Verified" and
>> "Held for Document Update". I don't know the effect of all that
>> outside an IETF context (people who are not familiar with the IETF or
>> with RFCs.
> Recent RFCs come with an explicit Pointer on the title page
> (last paragraph of the "Status of This Memo" section):
> Information about the current status of this document, any errata,
> and how to provide feedback on it may be obtained at
> So the errata for those RFCs is just two mouse-clicks away (if you're
> reading online).
> Keep in mind what rfc2026 says about documents at document maturity level
> "Proposed Standard":
> Implementors should treat Proposed Standards as immature
> specifications. It is desirable to implement them in order to gain
> experience and to validate, test, and clarify the specification.
> However, since the content of Proposed Standards may be changed if
> problems are found or better solutions are identified,
> More and more RFCs are written by document editors who have little
> to none implementation experience and reviewed by folks who have
> little implementation experience, with the result that a lot of
> issues that are important for implementors are omitted from the
> document (and sometimes for "political" reasons). The result is,
> that actual implementors run into an increasing number of unspecified,
> underspecified or ambiguos areas and request clarification.
> Today, the one and only documented approach to add a missing clarification
> into a published RFC is to file an errata.
>> Here's an odd case. Errata #3481 was filed against RFC 2246. That
>> RFC is obsolete (I am ignoring the specifics). In my humble opinion
>> it is worthwhile to apply changes to the up-to-date version of the
>> specification as that RFC is supposed to be better than then obsoleted RFC.
> You're significantly mistaken. RFC 2246 is by no measure obsolete.
> More than 50% of the TLS connections on the internet still use TLSv1.0,
> and the only specification from which you can implement TLSv1.0 is rfc2246.
> First of all, Errata #3481 really should have been submitted in June2003,
> see: http://tools.ietf.org/html/draft-ietf-tls-rfc2246-bis-05#section-8.1.2
> rfc4346 was published in April 2006, so vital information was withheld
> from implementors for 3 years due to negligence.
> If that wasn't bad enough, the "Obsoletes: 2246" meta-data in rfc4346
> is factually incorrect, and to make things even worse, it reproduced
> into more factually incorrect Meta-data in rfc5246.
> I tried to fix the factually incorrect meta-data, starting with rfc5246
> but that errata was rejected on purely political grounds. So I haven't
> bothered yet to file a similar errata for the incorrect meta-data in rfc4346.
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
More information about the rfc-interest