[rfc-i] Errata process

Joe Touch touch at isi.edu
Mon Apr 22 08:40:39 PDT 2013



On 4/22/2013 6:17 AM, Martin Rex wrote:
> Joe Touch wrote:
>> The question is whether errata are the Comments intended by "Request for
>> Comments", or whether they are intended as pending updates to the doc.
>>
>> AFAICT, they are the latter - they're not listed as comments, but rather
>> errata.
>
> Re-read the IETF Process rfc2026 on the to-be-expected defects of
> Proposed Standard documents:
>
>     http://tools.ietf.org/html/rfc2026-page-13
>
>     Implementors should treat Proposed Standards as immature

I had already noted that the above refers to PS; not all RFCs are in 
this track.
Cutting the following down to the relevant points:
...
> And the IESG statement on processing of RFC Errata for the IETF Stream:
>
>    http://www.ietf.org/iesg/statement/errata-processing.html
>
...
>      * Rejected - The erratum is in error, or proposes a change to the
>        RFC that should be done by publishing a new RFC that replaces
>        the current RFC. 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.
...
> Guidelines for review are:
>
>     1. Only errors that could cause implementation or deployment problems
>        or significant confusion should be Approved.
>     2. Things that are clearly wrong but could not cause an implementation
>        or deployment problem should be Hold for Document Update.
...
>     7. Changes that modify the working of a protocol to something that
>        might be different from the intended consensus when the document
>        was approved should be either Hold for Document Update or Rejected.
>        Deciding between these two depends on judgment. Changes that are
>        clearly modifications to the intended consensus, or involve large
>        textual changes, should be Rejected. In unclear situations,
>        small changes can be Hold for Document Update.
>     8. 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.

It would be useful to point out how the points for handling rejected 
errata differ from your position; they validate mine.

...
>> As such, it is inappropriate to include comments not vetted and approved
>> by the authors and (where appropriate) the WG and/or IESG.
>
> I strongly disagree.
>
> The author(s) may sometimes be the reason why the problem exists
> in the first place.

Agreed, but the doc was published by the above parties (and the WG and 
IESG only for IETF-track). Overriding that, should only be done *by 
publishing another RFC*, which is vetted by the community (in the case 
of updating standards-track) or at least undergoes the same review as 
the original doc (all docs receive some tech review, even if to ensure 
no damage to the Internet or existing standards).

> There is *NOTHING* sacred about author/editor opinion and consensus
> when it comes to formally provable defects of a specification,
> and the explicit addition of a clarification of a formally provable
> implied consequence of the _existing_ specification.

That's correct, but there is nothing sacred about errata suggestions 
either. They ought to pass the same level of review - and, in the case 
of errata, be raised to being included in updated RFCs where they 
substantively change things.

This position is entirely consistent with that in RFC 2026.

> We know painfully well that a lot of implementors do poorly on formal
> correctness and will miss non-trivial implications, so adding explicit
> clarifications is exactly what the errata process has been designed for.

Please review the errata guidelines; clarifications are NOT part of the 
list of approved items unless they are unintended errors by those 
responsible for the document's original content.

> The question of WG consensus comes up when the specification contains
> not just an ambiguity, but also offers several different plausible
> solutions/choices for disambiguiation.

That's clearly out of scope as per the errata guidelines; that would be 
a substantive change in the doc, and requires a new RFC.

>> I know of cases where errata were rejected because they were either
>> clearly incorrect, created ambiguity, tried to clarify something that
>> has not been resolved by the community, etc. - or even those that were
>> clearly inappropriate under the categories provided (e.g., new
>> extensions that exceeded the intent of the original doc).
>
> Re-read the IESG statement on Processing Errata.  Rejecting an errata
> does *NOT* imply that the errata is factually incorrect.

My note above does not indicate that implication; it indicates the 
converse (that factually incorrect implies rejection).

It is dangerous to keep the list of rejected errata with a document, 
exactly because of the confusion this issue has apparently already caused.

>> Errata ought to catalog document *errors*. They're not a mechanism to
>> log the ongoing evolution of a protocol, nor comments from the community.
>
> That *IS* what is currently __documented__ for new RFCs, i.e. the
> only "feedback" option that is offered on the RFC Editor page that
> is quoted on the title page of new RFCs.

Agreed, but that's not what I hear this discussion headed. Perhaps I 
jumped ahead a few steps in the discussion.

Joe


More information about the rfc-interest mailing list