> 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, therefore 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. 'Spot on'. Also suggested in http://www1.ietf.org/mail-archive/web/ietf/current/msg35135.html "WG procedures would be developed to ensure RFC quality. The procedures would be created, maintained, and enforced by the IESG. WGs I participate in are mostly competent and thorough in RFC production, necessary cross-WG review is done, etc. Many comments on this thread that this quality isn't uniform across WGs, and needs to be. I see no reason this couldn't be made to work, proof is that it works like this, successfully, in other SDOs." Brian Carpenter agreed http://www1.ietf.org/mail-archive/web/ietf/current/msg35167.html: "you're fundamentally correct that the solution lies in the WGs. If WGs produce output that is truly ready to ship, it will get shipped quicker, whatever the formal path." So let's get on with it. Jerry Ash _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf