Hi Dave,
My impressions are, of course, based upon my own experiences...
I checked the time spent in the "In RFC Editor Queue" state for the last 10 RFCs that have been published from my I-D Tracker queue, and the details are included below.
According to my numbers, these ten documents spent a combined total of 201 months in the IETF process after -00 publication, which typically approximates when the WG accepted the work item (about 20 months per document). These documents spent a combined total of 50 months in the "In RFC Editor Queue" state (an average of 5 months per document) or just about 25% of the total time from WG acceptance to document publication. Therefore, given my own experience, I will stand by my impression that about 25% of the IETF's processing time for a given document is being spent in the RFC Editor Queue.
This number may not capture the full extent of the issue, as my longest-standing documents in the "In RFC editor Queue" state haven't had a chance to emerge yet. I've only been an AD for about 22 months, and I am responsible for 11 documents that have been in the RFC Editor Queue for over 6 months, including 2 that have been in the RFC Editor Queue for over a year.
Please note that I do understand that not all of the time spent in the "In RFC Editor Queue" state can be attributed to the RFC Editor, any more than all of the time spent "in the IESG" can be attributed to the IESG. Some of this time is spent waiting to resolve references, waiting for author feedback on IANA issues, waiting for author response to AUTH48, etc.
However, I do believe that far too much time is being spent during the "In RFC Editor Queue" phase of the process. This phase of the process is too opaque for me to identify the specific reasons why this is taking so long, but I strongly believe that we need more visibilityy into this part of the process and that we need to apply our efforts to making this period shorter.
Margaret
draft-carpenter-obsolete-1888: (TOTAL TIME: 8 months) In RFC Editor Q: 2004-11-02 to 2005-04-26 (5-1/2 months) -00 Published: August 2004
draft-ietf-dhc-agentopt-radius: (TOTAL TIME: 36-1/2 months) In RFC Editor Q: 2004-09-27 to 2005-02-24 (5 months) -00 Published: 2002-02-14
draft-ietf-dhc-auth-suboption: (TOTAL TIME: 33-1/2 months) In RFC Editor Q: 2004-09-21 to 2005-04-06 (6-1/2 months) -00 Published: 2002-06-23
draft-ietf-dhc-dhcpv6-opt-nisconfig: (TOTAL TIME: 32 months) In RFC Editor Q: 2004-06-02 to 2004-10-12 (4-1/2 months) -00 Published: 2002-02-17
draft-ietf-dhc-rapid-commit-opt: (TOTAL TIME: 16 months) In RFC Editor Q: 2004-11-02 to 2005-04-06 (5 months) -00 Published: 2003-11-28
draft-ietf-dhc-reclassify-options: (TOTAL TIME: 11 months) In RFC Editor Q: 2004-07-12 to 2004-12-03 (4-1/2 months) -00 Published: 2004-01-05
draft-ietf-dhc-subscriber-id: (TOTAL TIME: 20 months) In RFC Editor Q: 2004-09-16 to 2005-03-22 (6 months) -00 Published: July 2003
draft-ietf-dhc-vendor: (TOTAL TIME: 14 months) In RFC Editor Q: 2004-07-12 to 2004-11-04 (4 months) -00 Published: September 2003
draft-ietf-eap-rfc2284bis: (TOTAL TIME: 17 months) In RFC Editor Q: 2004-02-29 to 2004-06-22 (4 months) -00 Published: January 2003
draft-ietf-ipv6-deprecate-site-local: (TOTAL TIME: 13 months) In RFC Editor Q: 2004-04-16 to 2004-09-21 (5 months) -00 Published: 2003-08-16
At 10:01 AM -0700 5/10/05, Dave Crocker wrote:
The time to move from approved
I-D to RFC is often a significant percentage (perhaps averaging 20% of more?) of the time required to develop and publish a specification.
Let's say that it averages 4 months to go from IESG approval to RFC publication. (I'm choosing that number because it is big enough to indicate a problem, but small enough not to insult the RFC Editor.)
Using your estimate of 20% for this step, that means that working groups average 16 months to do their part of the work, from start to finish.
However that does not match either general impression or that statistics that were produced awhile back.
If we averaged 16 months for working groups to go from start to finish, we would not have serious and consistent complaints that the IETF is too slow.
So the actual, incremental delay for the RFC publication process is probably no worse than 10% and I wouldn't be surprised if the real statistic were more like 5%.
As much as it is worth trying to make everything better, it is difficult to see a 5 or 10% overhead to the process as being one of our strategic problems.
d/ --- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf