[rfc-i] Errata process

Joe Touch touch at isi.edu
Mon Apr 22 09:59:22 PDT 2013



On 4/22/2013 9:25 AM, Martin Rex wrote:
> 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.

Agreed, but by our processes change occurs by new RFCs, not by some 
alternative process that is not vetted.

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

Errata are not implementation notes; anyone who wants to do that can 
endure the full RFC publication process. Anything that doesn't survive 
that - or has insufficient interest or effort to do so - should not 
affect something that has.

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

Nor for errata writers. But the closest thing we have is the RFC 
publication process, and errata need to be held to exactly the same 
scrutiny when they change a published RFC.

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

Nor should we create an end-run around the IETF process by which 
protocols and protocol changes are reviewed and published.

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

If there are ambiguities, then it's not "just a clarification" - there 
are (by definition) multiple interpretations. The decision of which 
interpretation is appropriate is not the errata authors; it remains with 
the original authors and (where applicable) the WG and IETF, UNTIL such 
time as a new RFC is written that updates the allegedly erroneous one.

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

No; I am allowing for technical errors to be corrected ONLY where they 
were confirmed to be otherwise in the original document. E.g., a typo 
that introduces an error can be fixed IF the author confirms that this 
is the case.

But changes to the protocol need to go through IETF process.

Again, this position is consistent with RFC 2026.

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

Errata are not WG nor IETF mailing lists; discussion should happen there.

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

The problem is that you're creating an end-run around IETF process to 
even associate a comment with a doc; now you're expecting the onus to be 
on the authors and ADs to provide comments against every posted errata.

There are a thousand monkeys out there typing errata*; some good, some 
well-intended but inappropriate or wrong, and some an attempt to 
end-run. There is no obligation when an RFC is posted to have incorrect 
information have a continued association with that RFC.

*see http://en.wikipedia.org/wiki/Infinite_monkey_theorem

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

Absolutely not as per RFC 2026. Errata are to correct documents. What 
you seek is called "implementation guidelines" or "updates", and both 
are RFCs.

See RFC 2525 and the pending RFC1323-bis. The latter is a very good 
example of a new doc that clarifies and corrects significant issues in 
an old doc.

Joe


More information about the rfc-interest mailing list