> IESG, > > I think this is good and appreciate the IESG publishing it. > > There is an issue that this does not cover, that something needs to be done about. It is when an Errata if filed, it identify the problem the Errata is addressing, and new includes text to fix the problem. > > However, we have run into errata where the problem identified is correct, but the the fix to the problem is wrong. It may be completely wrong, or there may be a better way to fix the problem. In the worst case, it could make the problem worse. > > The three states for processing an errata are: > > * Verified > * Rejected > * Hold for Document Update > > These don’t address this issue. For example, marking the errata as “Verified” is fine for the problem, but not good for the fix in the errata. We wouldn’t want implementors to assume the fix is correct. > > I think something is needed where the reported problem can be accepted, but the fix can be rejected. Perhaps some new states, or a change to how the Errata system works. I fully agree with that. I have also seen cases where errata is wrong or even has been used as a way to try to change a specifictation. The current errata system allows anyone to attach whatever they like without review to a published document. I don't know how to fix this, but it might include changes to process, tools and presentation. A clearer distinction between a reported document bug and a verified errata could be a start. Best regards, Ole
Attachment:
signature.asc
Description: Message signed with OpenPGP
