Re: RFC Errata: when to file, and when not to

[Yoav Nir <[e-mail]>]

On Aug 9, 2012, at 2:35 PM, Dave Cridland wrote:


It seems entirely reasonable that there needs to be a version available that's precisely as-published, for legal (and quasi-legal) reasons, as you say - however, that's the version produced by the RFC Editor, and not the tools version (which is already non-normative, technically, due to the markup).

What I'm driving at is whether the right way to handle errata is by changing the document on tools (perhaps by diff submission). This should reduce the mechanical workload of errata handling to near-zero, and leave the judgement calls of whether to accept them as the cost.

This means that there would be two documents with the same RFC number. The quasi-leagal "as published" one, and the one of the tools site. Which should I follow when I go to implement?

If the errors amount to something that would really make a difference in implementation, you really need a new RFC, and can't handle this in an erratum.

See for example RFC 4753. The erratum changed bits on the wire, so a replacement RFC (5903) had to be published.

RFC 5903 also has two errata, which were rejected. But they are editorial, so even had they been accepted, they would not require a new RFC.