RFC Errata: when to file, and when not to

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]