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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf