I can assure you, I at least was anticipating that the IESG (and other
people handling errata) would be doing *more* work in classifying
errata if we have the three categories. The goal as I see it is to
avoid presenting 50 errata on an RFC to a user, without any sorting or
focus, when only three of them are crucial to interoperability. If we
overwhelm implementors with more than a page worth of errata, most of
which are junk, implementors will be well justified in ignoring errata.
An important part of the errata handling, therefore, is to make the
difference clear to the implementor. When an implementor clicks
"Errata" for an RFC, they should see the short-list of crucial errata
and at the end, a link to "Other possible errata" (or other wording).
With that kind of interface, I don't think readers of errata need to
care about the exact difference between categories: the essential
difference, to them, is which ones have been brought to their
On Apr 17, 2008, at 7:13 AM, Paul Hoffman wrote:
At 8:16 AM -0700 4/16/08, The IESG wrote:
o Approved - The errata is appropriate under the criteria below
should be available to implementors or people deploying the RFC.
o Archived - The errata is not a necessary update to the RFC.
However, any future update of the document should consider this
errata, and determine whether it is correct and merits including
in the update.
Assuming that both categories will be in the errata repository, the
difference between these two may be clear to the IESG, but it will
not be clear to readers of the errata. I suspect that the two
categories were created so that the IESG only needs to consider
"errors that could cause implementation or deployment problems or
significant confusion", not the minor stuff, but this
differentiation will simply cause more arguments about what errors
would cause problems of what magnitude.
In the end, it is probably better for readers of the errata to have
just one category, and for the IESG to not waste its time
differentiating between the two categories.
--Paul Hoffman, Director
IETF mailing list