[rfc-i] Errata process
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
> Re-read the IETF Process rfc2026 on the to-be-expected defects of
> Proposed Standard documents:
> Implementors should treat Proposed Standards as immature
I had already noted that the above refers to PS; not all RFCs are in
Cutting the following down to the relevant points:
> And the IESG statement on processing of RFC Errata for the IETF Stream:
> * 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.
More information about the rfc-interest