Hi, Does the IESG plan to catch up on old reported errata that have never been processed? There are three here for example: https://www.rfc-editor.org/errata/rfc6275, as much as 4 years old. There may be a lot more lurking. Regards Brian Carpenter On 08-May-21 04:38, IESG Secretary wrote: > IESG Processing of RFC Errata for the IETF Stream > > Online: <https://www.ietf.org/about/groups/iesg/statements/processing-errata-ietf-stream/> > > This document describes how the IESG processes RFC Errata for the IETF Stream. > > These are strong guidelines, not immutable rules. The Area Directors (ADs) should use > common sense and good judgment to decide what the right thing to do is. They apply to new > errata and not to errata that have already been processed. > > Errata are meant to fix "bugs" in the specification and should not be used to change what the > community meant when it approved the RFC. Here are some things to consider when > submitting an errata report: > > * Errata are items that were errors at the time the document was published -- things that > were missed during the last call, approval, and publication process. If new information, > new capabilities, or new thinking has come up since publication, or if you disagree with > the content of the RFC, that is not material for an errata report. Such items are better > brought to relevant working groups, technical area discussions, or the IESG. > * Errata reports are usually for errors in the text version of a document. It is possible to > report errors in other outputs (e.g., HTML or PDF) for RFCs published in the v3 format > (i.e., RFC 8650+). > * Errata are classified as "technical" or "editorial". Please mark the report appropriately. > Technical errata are expected to be things that would likely cause significant > misunderstandings of the technical specification and might result in faulty > implementations if they are not corrected. Editorial errata are, as the name implies, > editorial - for example, typos, missing commas, etc. Errors in examples will generally be > editorial, though marking them as technical could sometimes be justified. > * Please clearly explain the issue in the Comments section. This is especially important for > editorial issues, where the Original Text and Corrected Text may look almost identical. > > When a technical erratum is reported, a report is sent to the authors, chairs, and Area Directors > (ADs) of the WG in which the document originated. If the WG has closed or the document was > not associated with a WG, then the report will be sent to the ADs for the Area most closely > associated with the subject matter. > > When an editorial erratum is reported, the RFC Editor will do an initial review and handle errata > that are clearly editorial in nature. If the erratum cannot be handled by the RFC Editor, the AD > will be asked to review. > > While ADs are ultimately responsible for processing the reports, they may delegate the review > or perform it personally. The reviewer will classify the erratum as falling under one of the > following states: > > * Verified - The erratum is appropriate under the criteria below and should be available to > implementers or people deploying the RFC. > * Rejected - The erratum is invalid or proposes a significant change to the RFC that > should be done by publishing a new RFC that replaces or updates the current one. In > the latter case, if the change is to be considered for future updates of the document, it > should be proposed using channels other than the errata process, such as a WG mailing > list. > * Hold for Document Update - The erratum is not a necessary update to the RFC. > However, any future update of the document might consider it and determine whether it > merits including in an update. > > Guidelines for review are: > > 1. Grammar corrections and typographical errors should be classified as Verified. > 2. Broken URIs that were likely valid at the time of publication are, strictly speaking, not > subject to errata reports. That said, the AD must judge the importance of correcting > such a reference and may classify the report as Verified. > 3. Changes that are stylistic issues or simply make things read better should be classified > as Hold for Document Update. > 4. Technical items that have a clear resolution in line with the original intent should be > classified as Verified. If the resolution is not clear or requires further discussion, the > report should be classified as Hold for Document Update. In both cases, only items that > are clearly wrong should be considered. > 5. Changes that modify the working of a protocol to something that might be different from > the intended consensus when the document was approved should generally be > Rejected. Significant clarifications should not be handled as errata reports and need to > be discussed by the relevant technical community. > 6. Changes that modify the working of a process, such as changing an IANA registration > procedure, to something that might be different from the intended consensus when the > document was approved should be Rejected. > 7. Errata on obsolete RFCs should be considered according to whether the error persists in > the obsoleting RFC. If it does, the report should Rejected with a pointer to new errata > against the obsoleting RFC. If it does not, it should be Rejected with an explanation that > the error is corrected in the obsoleting RFC (cited by number). > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf-announce >
