> Maybe it would be useful to talk about *necessary* slowness, also. Indeed. When I step back and ask what leads to the best specifications (and indeed, documents in general), it is all rather simple: 1) produce a document. 2) get a small number of quality reviews. 3) revise in response to those reviews 4) ensure that reviewers in step 2 are satisfied by the revision. 5) Repeat steps 1-3 with a _different_ set of reviewers. 6) Repeat step 5 until it becomes clear that the reviewers are finding only minor editorial issues. Observations: 1) You can't hurry the above, e.g., by imposing artificial deadlines, or by saying "no objections during LC, therefor ready to go". You have to have the reviews, and you have to iterate. 2) Where the IETF is failing (at times) today is that it isn't actually reaching step 6) prior to sending a document to the IESG. Result: IESG finds issues that should have been found earlier. 3) You can "hurry" the process somewhat, but not too much. You can hurry it in the sense of having steps 1-3 take on the order of 3-5 weeks. I.e., if you get fast (but good reviewers) and responsive editors, that is a huge win. The obvious corollary is that if steps 3-5 take too long, you lose momentum big time. Indeed, one real problem we have today is too many WGs/documents are in a one revision per IETF meeting cycle. I would assert that any document/WG in this mode has veered off the road and into a ditch. You can also hurry the process by having good editors and good reviewers, as they help ensure that one doesn't get stuck in a rut at step 5). 4) In the above, there is nothing that requires the IESG do things differently. It really requires that _WGs_ do things differently. And, indeed there are some WGs that are doing the above, and doing it fairly well. They have chairs/editors/participants that move the discussions/the process along, they employ issue trackers to ensure that things don't get lost and so they can actually see whether the sorts of issues that are being raised are still serious, etc. And when those WGs do a good job, the IESG "delays" are generally short. In summary, the most important improvement that the IETF needs to make (IMO) is to get its WGs operating better and make them responsible for demonstrating that the above steps have been followed (and specifically, step 6 has been reached) before a document is allowed to go to the IESG, and having those steps be done in a _timely_ manner. Thomas _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf