[rfc-i] RFC Errata - Slippery Slope
danny at tcb.net
Mon Jan 21 14:30:01 PST 2008
Upon rereading this draft and discussing this some offline with
Bob, Olaf and others, I figured I'd kick a message here for
Section 1.1 of draft-rfc-editor-errata-process-00 shares this
Another issue with errata is that some of the reported errors are
simply editorial, but rather correct technical contents of RFCs. A
savvy implementer of the specification can often, but not always,
figure out what was intended by the RFC as published, but technical
errors should be announced somehow. Furthermore, posting technical
errata for Standards Track documents should always involve the IESG,
as a matter of correct process. Technical errata may require much
review and discussion among the author(s), Area Directors, and other
We note that allowing technical errata is a slippery slope: there
be a temptation to use errata to "fix" protocol design errors,
than publishing new RFCs that update the erroneous documents. In
general, an erratum is intended to report an error in a document,
rather than an error in the design of the protocol or other entity
defined in the document, but this distinction may be too
avoid hard choices. For the IETF stream, these choices should be
made by the IESG, not the RFC Editor.
The current draft process doesn't distinguish between technical and
editorial errata. Are more specific guidelines needed here? Guidelines
that are generic to all streams with respect to distinguishing
in documents and errors in protocol, e.g. what happens with errata
rejected because they would change the protocol although they clearly
and unambiguously demonstrate an error? Is there a need to keep such
information around and tag it?
I know Bob Braden has some information of the RFC Editor bits (he's
clued me in here already), I'm sure he'll share those with the folks
as well. I'm wondering more about what folks here believe needs to
happen on the process front.
The second question is if there is a need to describe in more detail the
stream dependent management of such normative changes. For the IETF
stream it would probably mean 'back to the WG/sponsoring AD and work
on a new RFC'. How about the independent, IAB, and IRTF stream?
Also, are the current guidelines regarding notification to ietf-announce
sufficient, or should each status change trigger some note every time
an erratum is verified, rejected to altered?
I'm quite interested in seeing more discussion on this.
More information about the rfc-interest