[rfc-i] Errata process

Joe Touch touch at isi.edu
Mon Apr 22 11:11:26 PDT 2013



On 4/22/2013 11:00 AM, Martin Rex wrote:
> Joe Touch wrote:
>>
>>> 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.
>
> Huh?
>
> I believe we can safely assume that defects in an IETF stream, standards
> track document, which impairs interop on an explicitly defined protocol
> feature, is _unintentional_.

Not all. Some were intended as written but not understood or known as 
issues at that time. Those are not errata - they're errors in the spec. 
Others created ambiguity where we simply don't know what was intended.

Errata should be "corrections to what was intended in this DOCUMENT", 
not "corrections to what is intended in a spec". There's a process for 
the latter, which involves starting with an I-D.

> If the IESG starts approving proposed standards with intentional ignorance
> about problems (rather that explicitly and carefully waiving certain problems
> in PS documents), then the IETF will be in serious trouble.

There are plenty of proposed errata that are "we NOW know that X is 
wrong, so do Y", or "the original doc was ambiguous on X vs. Y, and we 
now know we want Y". The MTU calculation was one of those cases.

Errata should never be a place to resolve such issues. They should be 
"oops, we really intended this *when we wrote the doc*", and only the 
author (and, again, in some cases the WGs and IESG) know that.

EVERYTHING else needs to go through process.

Joe


More information about the rfc-interest mailing list