Few thoughts. 1) don't get wrapped around the axel of STD, PS, Foo bar label, it has nothing to do with the problem that that IESG believes many drafts need changes to fix significant problems. Lots of people imply that the IESG is setting the bar too high but when you look at the changes that are made to drafts from point they go in, to point they come out of IESG it seems to be a rare example where people don't agree that major changes were an improvement and needed. 2) On the point of what the IESG should be doing, I would like to see the whole IESG say they agree with the Discuss Criteria document and will stay within that (or change it if they disagree). The cross area review teams might want to also provide comments within this context. 3) Require each pub request from a WG to come with names of 3 nom com eligible people that are willing to say "I have carefully reviewed this draft and I believe it is ready to be published as an RFC". If a WG can't find 3 people to do this, it should probably be closed. You might consider something similar for AD sponsored drafts but I am more interested in the WG ones. 4) Get the ADs involved earlier. My experience is that many ADs won't say much because they are worried that they would be over influencing the WG. ADs got the job because we think they are the right people to provide influence and obviously it would be better to get that early rather than late. 5) Given how long a WG takes, I have no problem with time IESG / RFCEd takes. I would suggest mitigating this concern by clearly telling the community that if there were a spec that truly needed to be fast tracked for some real reason, you would make it priority. And on the rare occasion that is needed, do it and track the stats for fast track separately. I would guess that less than 1 in 100 needs this and you could do theses with delays in the small numbers of weeks instead of months. How fast you can move when really needed is more important to me than the average and I know that the IESG/IANA/RFCEd team works well in parallel and can move fast when needed. 6) Over the long term, set up the tools to separately track IESG / RFCEd time where the ball is in the authors court. 7) Remember that in the end, the goal is not a standard. The goal is an feature rich interopeable internet that is a fertile ground for inovation. High quality and relevant standards that think about the future are the way to get there. The goal is not to publish lots of specification that aren't used and don't work. Cullen On May 1, 2013, at 9:33 AM, Jari Arkko <jari.arkko@xxxxxxxxx> wrote: > I wrote a blog article about how we do a fairly significant amount of reviews and changes in the late stages of the IETF process. Next week the IESG will be having a retreat in Dublin, Ireland. As we brought this topic to our agenda, Pete and I wanted to raise the issue here and call for feedback & ideas for improving the situation with all of you. > > http://www.ietf.org/blog/2013/05/balancing-the-process/ > > Jari >