ietf
[Top] [All Lists]

Re: call for ideas: tail-heavy IETF process

2013-05-02 17:26:23
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