Hi Mark,
At 00:16 02-06-2008, Mark Andrews wrote:
Errata is a lot faster that getting out a new RFC and will provide
a place that can be referred to in the meantime.
There is a Proposed IESG Statement Regarding RFC Errata for IETF
Sream RFCs (see
http://www.ietf.org/mail-archive/web/ietf-announce/current/msg04742.html
). There is also a RFC Editor Proposal for Handling RFC Errata (see
draft-rfc-editor-errata-process-02 ).
This rule is clearly wrong.
Quoting Section 1.1 of the above-mentioned draft:
"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 interested parties."
"We note that allowing technical errata is a slippery slope: there may
be a temptation to use errata to "fix" protocol design errors, rather
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 imprecise to
avoid hard choices."
I don't think there is any real dispute that the rule is bogus.
There is clear evidence that it does actual harm.
Although an Errata is the path of least resistance, it may not be
appropriate as this is a technical errata and RFC 3484 is on the
Standards Track. If there isn't any real dispute about the rule
being bogus, it may be possible to publish an I-D and have it on a fast track.
Regards,
-sm
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf