--On Thursday, August 09, 2012 17:11 +0300 Yoav Nir
<ynir(_at_)checkpoint(_dot_)com> wrote:
And, if I correctly understood it at the time, that is exactly
why the RFC Editor opposed the idea of formal errata for
years. If there were real, substantive, errors, a replacement
RFC should be published as soon as practical. For anything
else, the most that was desirable would be a collected list of
comments and suggestions that could be considered if/when the
document was revised.
There are still the spelling mistakes and obvious errors. Take
for example this one from RFC 5296:
The EMSKname is in the username part of the NAI and is
encoded in hexadecimal values. The EMSKname is 64 bits in
length and so the username portion takes up 128 octets.
Encoding 64 bits in hex requires 16 octets, not 128. I think
anyone implementing this would figure this out, but it is
substantive. The RFC was being revised anyway, but do you
think a replacement RFC would need to be published if that
were not the case?
Personal opinion: I don't know about "need to be", but
replacing an RFC with an error of that type would be desirable
to avoid any possible misunderstanding, however unlikely. IMO,
it would also be desirable to have some self-examination in the
community about why that error slipped past IETF Last Call, AD
reviews, and AUTH48).
john