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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf