Re: Updated IESG Statement "IESG Processing of RFC Errata for the IETF Stream"

[Bob Hinden <[e-mail]>]

IESG,

I think this is good and appreciate the IESG publishing it.

There is an issue that this does not cover, that something needs to be done about.  It is when an Errata if filed, it identify the problem the Errata is addressing, and new includes text to fix the problem.

However, we have run into errata where the problem identified is correct, but the the fix to the problem is wrong.   It may be completely wrong, or there may be a better way to fix the problem.  In the worst case, it could make the problem worse.

The three states for processing an errata are:

* Verified
* Rejected
* Hold for Document Update

These don’t address this issue.   For example, marking the errata as “Verified” is fine for the problem, but not good for the fix in the errata.    We wouldn’t want implementors to assume the fix is correct.

I think something is needed where the reported problem can be accepted, but the fix can be rejected.    Perhaps some new states, or a change to how the Errata system works.

Bob


> On May 7, 2021, at 7:30 PM, Brian E Carpenter <[e-mail]> wrote:
> 
> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ietf-announce
>> 
>