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