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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf