ietf
[Top] [All Lists]

Reasons for delay

2005-06-14 14:47:35
The problem with capturing why WGs and drafts are delayed is that delayed drafts are like unhappy families: they are all unique in their misery. Here are some causes that I have seen:

(1) Waiting for others, particularly normative references. There are proposals to fix this problem; at least in my experience, this only becomes a problem if another draft is very late for other reasons, so fixing the other reasons will make this problem less likely.

(2) Sequential processing: There is very little parallel processing going on. Given that close to 100% of late-stage WG drafts eventually get published as an RFC, it would seem to be quite possible to do some post-IESG steps early. For example, the IANA review could be done during IETF LC. On occasion, changes in the draft will mean that IANA will have to redo work, but like branch prediction in a CPU, the average reduction in delay seems very likely to outweigh this incremental effort. It seems like this could easily be explored experimentally.

(3) Exhaustion: Far too many drafts linger years in 90%-completed state, while the authors or the WG has moved on to other things. It would be interesting to take a look at long-delayed drafts and see how much they have really changed as a function of time. My guess is that the change rate goes towards one-sentence-per-month or less.

(4) No comments: Many drafts receive no comments during WGLC or IETF LC. There are many reasons for that, but one reason is that there is very little motivation for reviewers, besides the feeling of doing something for the benefit of mankind. In most cases, there is no tracking of issues raised and the authors simply respond that "the new version addresses the issues raised during last call". The reviewer would have to go back and re-read the draft to make sure that has happened. Some WGs designate reviewers, but this seems to be done haphazardly and inconsistently. Most authors acknowledge LC reviewers, but this is again not always done.

(5) 6 work weeks: One sometimes has the impression that all work gets compressed into the two weeks before the IETF I-D deadline, with very little activity in-between. This applies to WG chairs and authors, unfortunately.

(6) General attitude: If it becomes custom that drafts takes three or five years to complete, nobody is in any particular hurry, after all it "always takes that long".

(7) We put a lot of freedom on document authors, essentially granting them a monopoly of the pen, but there is very little project management. In other words, we treat drafts as if they were science papers, but we're expecting results as if we were doing product development. Good project management would increase the responsibility of authors, and make it easier to set expectations.

(8) WGLC limbo: After WGLC, there is often a long period of no action. There should be an expectation that within a very short time (say, one week unless major technical issues need to be revisited) the authors complete a revision and the chairs pass the draft to the AD. Drafts that have gone through WGLC and are not in AD hands after that period should be flagged so that they can receive particular attention.

(9) No WGLC schedule: The WGLC schedule is not published, so one has to dig through the mailing list archives to find such calls. Scheduling is often haphazard. Instead, WGLC should be used as a deadline to make things happen: Schedule the WGLC when it seems likely that the draft can be completed in, say, 3 or 6 months. Give the author and WG a deadline: either get it ready for the scheduled date or go back to the end of the queue. If a draft misses its WGLC target twice, escalate as appropriate, e.g., by swapping out editors, forcing author teleconferences, etc. Mark those drafts so that everybody can see those problem drafts.

Henning



_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf



<Prev in Thread] Current Thread [Next in Thread>