Keith, Just to clarify in case that is needed, in a more perfect world, I would agree with each of your comments/principles. It is easy to find analogies for all three steps in other publication processes and I have no doubt that they would result in everything we produced being of much higher quality as well as representing clearer consensus. However, in the real world, I believe that moving in those directions would result in loud outcries about how things already take too long, that following that "clean" a process would make them take longer, and that one net effect would be to drive down participation and the range of perspectives available, thereby lowering both quantity and quality of IETF outputs in a different way. So I am trying to find, and tried to propose, much more modest changes that would work in our less-than-perfect world. I see changes of those types as representing tradeoffs between where we are now and that more perfect world, building on the strengths and constraints of each. If the community wanted to adopt your model and adhere to it, I'd be delighted. I just don't believe that, in practice, there is a chance (for good reasons as well as bad ones). best, john --On Saturday, June 25, 2022 15:35 -0400 Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx> wrote: > Without responding to John's message point-by-point, I have > long believed the following: > > 1. Documents should be frozen at Last Call time, with no > updates permitted until IESG has voted on the document. > 2. Any changes subsequently agreed to between IESG and the > document editors should be published as a post-Last-Call I-D + > diffs, along with explanations for the changes. > 3. Those changes should be subject to community review, with > the potential for subsequent revision before sending to the > RFC Editor. > 4. Similarly, any changes made by the RFC Editor should be > posted as I-D + diffs and subject to community review BEFORE > the final RFC is published. > > There's too little transparency in these late stages, and a > lot of potential for those changes to vary significantly from > community consensus.
