Statistics (RE: The "late surprise" problem)

[Jari Arkko]

Scott W Brim wrote:
> On Sat, Mar 22, 2003 07:32:11PM +0100, Bert allegedly wrote:
> 
>>When I see this (in terms of IDs submitted in the weeks before
>>teh IETF:
>>
>>>>	Week 1	90	12%
>>>>	Week 2	82	11%	 (Initial cutoff)
>>>>	Week 3	194	26%	 (ID Cutoff)
>>>>	Week 4	385	51%
>>>
>>Then it seems clear to me that that is a BIG scaling/size problem.
>>There is no way people can do due dilligence in reading 51% of
>>the documents (relevant to him/her) in the last week before the 
>>IETF.
> 
> 
> The approach I took recently was to put out a version a month before the
> meeting, and then put out a corrected version just before the meeting.
> I don't like it because of the increased load on the secretariat, but I
> haven't come up with a better way of working.  Perhaps the idea of
> limiting "presentations" would work.  Perhaps moving the deadline even
> further back.

IMHO, the statistics show the IETF clock frequency problem: we run
three times a year, or at about 10^-7 Hz ;-)

More seriously, there's a very natural human tendency to postpone
things until the deadline. We all have more things to take care of
than time; thus we postpone tasks until we really have to do them.
Note that "a deadline" isn't necessarily a management-emposed date.
Rather, it is some activity such as a meeting or review that requires
the document as input. So, it wouldn't necessarily help if Harald
moved the deadline further back or increased the number of expected
document deadlines: its the meeting behind the deadlines that count,
and a management directive alone would just make folks not post
new versions on an "empty" deadline or increase the use of private
URLs for the latest draft versions.

Personally, I think we should try to increase the clock frequency.
If the stuff we are working on is useful, it probably receives
enough input to justify more frequent revisions, hopefully resulting
in an RFC sooner. Also, if the "attention span" for a particular
technology is at max about 2-3 years before vendors have already
deployed their proprietary solutions and the WG members changed
jobs, we should try to get our standards out much sooner than the
attention span runs out.

So, what can we do about this? Possible ideas include having
additional, more officially sanctioned reviews (like last
call, but earlier) or more frequent meetings. Or killing I-Ds
that don't get updated frequently enough.

Jari