[rfc-i] Errata process

Martin Rex mrex at sap.com
Mon Apr 22 09:25:52 PDT 2013

Joe Touch wrote:
> 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).

This is not "the Church of Internet Protocols", where consensus
process or leadership decisions create "Proposed Standard Dogmas",
that are sacred and immune to clarifications.

Unless we want to riducule ourselves about the "Engineering" in IETF,
we need a means to make clarifications available to implementors
of Proposed Standards in a timely fashion. 

> > 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.

We do not currently have a requirement for document authors, IETF leadership
and other IETF participants to be well versed in formal correctness proofing.
And in particular, for document as Proposed Standard maturity level,
there is an explicit exemption from being formally correct as a
prerequisite for IESG approval.

But that doesn't mean that the IETF should be ignorant about document
defects that are found by implementors after the RFC has been published
whenever document author or WG do not understand formal logic consequences
for the published specification (or when they want to ignore it for
non-technical reasons).

> > 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.


When the current specification does not, or not reliably provide interop
in a usage scenario that is explicitly covered in a specification,
and a one sentence clarification will provide reliable interop for that
usage scenario, without impairing anything else, then this is perfectly
appropriate for the Errata process, because it is essentially not a
change, just a clarification.

What you're essentially calling for is to abandon technical errata
entirely and limit the errata process to editorial issues.
I believe that would be an extremely bad idea.

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

Every potential confusion can be adequately address by verifier notes!

Complete removal of Errata ought to be limited to real cases of abuse,
not just differing opinions on the severity of an issue.

And we really need to get over the issue of document editors looking
at errata as a personal offense.  Engineering is *NOT* about maintaining
illusions about correctness.  It is about pragmatically resolving
technical issues that impair interop or make implementation difficult.

> >> 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.

I agree that evolution of a protocol (=adding new protocol features or
changing existing protocol features) ought to be done through new
documents.  But for stuff that is already part of a specification,
and where every reader&implementer must assume that the current
specification provides interop, will need to be clarified through
errata, if a problem is determined.


More information about the rfc-interest mailing list