--On Saturday, May 8, 2021 15:53 -0700 Bob Hinden <bob.hinden@xxxxxxxxx> wrote: > 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. Bob, While I agree with your statement of the problem, I'm not sure about the fix :-). And I'm afraid you just opened a can of worms. Let's take the two cases I think are difficult and putting aside documents that are not on the standards track or that did not come from a WG for the moment: Example 1: Text says "...Mickey is a duck". Errata report says '"not" is missing; Mickey is not a duck' and claims it is an editorial matter. Now, I would hope the RFC Editor would say "the suggestion changes the meaning of the sentence and is consequently not editorial" but I would hope there would be an additional set of eyes on that decision, or any decision that something more serious than, e.g., an obvious misspelling, is editorial. To reduce AD workload, I think those eyes can safely be those of the author(s). Example 2: There is a real technical issue. The assertion about Mickey's species might turn out to be an example but I'm more concerned about proposed errata that involve more complex issues. If the consensus among ADs, Authors, and present or former WG Chairs is "whoops, the WG didn't think about that and thinking about that now gives us a headache", then the erratum clearly gets "save for document revision" and we move on. But suppose it is "Verified". What does that mean and, coming back to your point in particular, can an implementer rely on it? It does not represent IETF Consensus: there is been no IETF Last Call and it is really the position of a handful of people. My guess is that, at least for technical issues, "hold for document update" means "we are not going to think about that now" and that "verified" means "we agree that there is probably a problem, the proposed fix may or may not be correct, and you will need to wait for a new RFC with IETF Consensus to get a conclusion implementers can rely on". The IESG should be able to make statements about the level of their confidence in the fix as long as it was clear that their comments must not be confused with IETF consensus either. That would, of course, solve the problem you identify but has much broader implications. If there is agreement about "verified" not representing IETF consensus -- even for the problem statement, much less the fix-- I'd hope the relevant RFC Editor pages could be updated to clearly show definitions like those and that IESG statements could point to them. These distinctions are particularly important if the IETF is going to publish versions of RFCs with errata incorporated. The only other option I can see involves putting every single erratum with potentially substantive technical implications through IETF Last Call before it is marked "verified". Even if that was not required for "rejected" or "save for document update", to say that would not reduce AD (or community) workload significantly would be an understatement. best, john
