Hannes, Regarding your point about process changes I agree that we've struggled there. But for some reason I'm quite optimistic that we can do the right changes. Regarding your point on deployment time being even longer, my observation has been that most changes have the "right" time, and that doing things too far before or too far after makes a big impact on the deployment time. In other words, a long IETF development time can and has increased deployment time, or even caused a new function to not be deployed. But I agree that mere time at the IETF is not what we want to look at. Anyway, I wanted to respond more in depth on the your below point: > b) There is no interest to research where delay really happen. Your statistics just tell that there is delay but not why (of course). From my own experience I noticed that there are many reasons for delay and I am not sure I can blame it to the IESG reviews for most of the delay. It is only during the IESG review phase when the problems surface that could have been tackled much earlier. I agree of course that looking at where the issues are is very important, and would support work on that. However, I did want to point out that when I said "tail-heavy", I did *not* necessarily mean delay. I meant that a lot of activity is going on, many document changes, and much review is going on. Obviously in some cases this translates to delay as well. But the delay was really not my main concern. Primarily because I think other issues such as transparency to the working group or late surprises are more fundamental issues than mere timing. But also because I actually *do* have some statistics that seem to indicate that, overall, the last phase still goes through pretty quickly. Look at http://www.arkko.com/tools/lifecycle/wgdocs.html and compare the WG, IESG, and RFC editor times in the first graph. The WG time dominates. (I said "seem to indicate" because the results are pretty dated and I'm not really sure how valid they are, but they match at least my intuitive experience.) Not saying delay reduction wouldn't be useful, the overall times are still very long, and the IETF last call - IESG time is still a significant component. Just that delay would not be my primary concern. Joel wrote: > The big delays on documents in my queue (e.g. one's that I inherited) are almost exclusively of author or wg holds the token again or blocked on some other document variety. the tail is pretty long, whether it's heavy or not for a visibile minority of drafts. That matches also my intuition, as well as some other statistics that I've collected. In other words, most of the time we are waiting for a document change as the tracker state is revised ID needed. But of course, I don't know why we really are waiting for a document change, it could of course be that there are cases where the request for a change was unnecessary. Jari