RFC Errata: when to file, and when not to

[Barry Leiba <[e-mail]>]

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