Re: [Errata-design] An example of an erratum that takes time for little value

[Ted Lemon <[e-mail]>]

On Jan 13, 2015, at 2:24 PM, Heather Flanagan (RFC Series Editor) <[e-mail]> wrote:
> I suggest that a measure of a successful errata system will be one
> visually and through metadata differentiate between levels of usefulness
> for an implementer/reader.   The vote system could be of use here
> (though the irony of even thinking "vote" and "IETF" in the same context
> tweaks my brain).
> 
> Any alternative opinions to whether that measure is reasonable?

I think you meant "one that would visually and through metadata differentiate between levels of usefulness..."   I think you are sort of right.

To illustrate why I say "sort of," I think Sun Congyou's errata are good examples.

I am skeptical that errata of this type would be useful with the current system, because it's hard for me to believe that any end-user of our documents could find them.   Sun Congyou made the case that it's worth documenting them anyway because non-native speakers will have a much harder time spotting errors of this type than native speakers, and I think that's true.

IOW, in principle, these errata _are_ useful, and _should_ be shown.   In practice, at present, IMHO they are nearly useless.   So part of the way forward ought to be figuring out what would have to change in order for such errata to be useful.

There are other criteria to consider WRT errata being "useful."   Talmudic commentary on existing drafts is probably useful, if it can be arranged in a way that makes it available and usable without implying that it is authoritative.   Reports of actual errors are also useful, if they do not change the consensus of the document, and it's not so bad if the reader can't easily tell that they are not authoritative, because they don't change what is judged to be the meaning of the document; rather, they fix the document so that it correctly expresses the intended meaning that got consensus.   Although Sun Congyou's changes are not particularly significant corrections, I think they fall into this category.

So I think there are actually two categories: talmudic commentary, and corrections.   Corrections that are for obvious typographical errors can be vetted by any competent editor who we trust.   Corrections that are for mis-expressions have to be vetted by someone who is empowered to evaluate consensus (e.g., an AD).   The corrections could be presented on an RFC Editor web site as part of the document, but highlighted in red or something.

And talmudic commentary would just be attached in a way that makes it available for readers, but that is clearly denoted as "this comment does not have IETF consensus and is not normative."   And that requires some reader intervention to get.   It would be nice if there were a way to evaluate how much consensus there is behind such commentary, but that would have to always fall short of it being an IETF consensus, unless the document is updated to include whatever the commentary says.