Hi John, At 02:09 PM 21-12-2024, John C Klensin wrote:
Yes. But, as I think I've said before, I wish that some of the energy that is going into this discussion was, instead, going into figuring out how to one or both of two things:* fast-track the revision (-bis) * provide an alternate way to signal "this document is just wrong, replacement in progress". Those things could be especially important alternatives to inline errata in cases in which there was consensus that a document was wrong but no consensus (or clear evidence of consensus) about the correct fix. I haven't thought about it sufficiently to think it is a good idea, but I can imagine giving the IESG the authority to officially designate a post-approval but pre-editing I-D as a temporary substitute/ replacement for an RFC that is "wrong" and to include discussion of the problems, issues, alternatives, etc., in that document. Something along those lines, associated with appropriate tooling, would be a far better alternative to issuing a version of the RFC with inline errata and without that discussion of the problems.
The two things are internal to the Stream. There is a part of the second thing would fit in the RSWG in my opinion.
It may be that our primary concern is about two different types of errata. I consider one type fairly obvious -- no subtle issues and the error is rather clear once identified. I would not advocate significant effort or process for any one isolated case but anything resembling a pattern of them should, IMO, touch of an internal review in the RPC and/or the IESG about how the problem got through the system in the first place. My main concern is about the second: cases in which the error is sufficiently subtle that reasonable people with at least superficial expertise in the subject matter might disagree, or at least need to pause for a while, before determining that the error report is correct about both the problem and the solution/fix.
Yes.
In addition to my long-standing concern about turning ADs into mini-Kings rather than interpreters of community consensus after the community has been asked, I see two issues with AD (only) evaluation and determination of resolution. First, we've adopted standards in several topic areas that are enough outside the IETF mainstream that there is no guarantee that there will be anyone on the IESG who understands subtle parts of those topic areas in depth. My favorite example is Internationalization: the number of people who have come into the applicable AD positions with in-depth expertise in that topic area in the last decade has been rather few although several, to the their credit, have been willing to dig in, learn, understand many of the issues, and gain a clear understanding of what they don't know. I think there are similar topics in other Areas -- cryptographic algorithms and transport and operational issues that affect disadvantages parts of the network come immediately to mind as possibilities. Wise ADs, confronted with error reports on topics about which they have little expertise, will consult others and designate experts to look at those reports, but, at that point, we are not dealing with "AD evaluates" any more and, if the ADs don't know they have a problem or don't pick the right evaluation team, there is considerable possibility for naive decisions and/or ending up in the sort of community discussion "opportunity" that some of us have advocated. Second, we've avoided the issue of conflicts of interest for ADs, counting on general good judgment and the rest of the IESG to keep things under control. But, when an AD can unilaterally determine whether substantive changes can be made to a standard (and whether or not a change is substantive) without community review short of the appeals process, I think we'd need to go there. And, no, I don't think the appeals procedure is well-suited for situations like that, especially when there is a culture in the IESG of ADs deferring to the decisions made by others in their own areas.
Some of the discussion in one of the threads was about the "verifier". I don't feel strongly about this; I'd say that it would be up to the Stream to choose its verifier(s).
Regards, S. Moonesamy -- rswg mailing list -- rswg@rfc-editor.org To unsubscribe send an email to rswg-le...@rfc-editor.org
