[rfc-i] Errata process

Martin Rex mrex at sap.com
Fri Apr 19 03:52:27 PDT 2013

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.


More information about the rfc-interest mailing list