"Eric A. Hall" <ehall@xxxxxxxxx> writes: > On 5/10/2005 12:45 PM, Thomas Narten wrote: > > One example (and I'm just using it because it was it comes to mind, > > and one that I think is symptomatic of the broader problem): > > October 15, 2004: IESG approves 4-document set. > > Within one week: authors send xml source to RFC editor > > March 10, 2005: IESG requests expedited processing (target date: March 31) > > March 29, 2005: RFCs published > > > > Total time between IESG approval and publication, 5 1/2 months. For the record, I cited this one because as AD shepherd for this one, I am certain there were no normative dependencies, the IANA work was relatively minor (no new allocations where made), the authors didn't ask for massive changes during 48 hours, and I know there was frustration/puzzlement from the editors directed at me while we waited for the document to pop out. More generally, there are a number of reasons why documents get hung up after IESG approval. They include: 1) normative references to IDs that are not also in the queue. Unfortunately, there are too many cases of this, and IMO, the IESG (and WGs) should really not be approving such documents. Too often, once they are in the RFC queue, people forget about the normative depedencies which may themselves be stalled. As AD, I saw this _many_ times. :-( 2) IANA considerations. IANA needs to do its part before an RFC can be published. IANA delays have also stretched into multiple months at times. 3) Additional "changes" requested by the WG and or authors. I know of several cases where WGs/authors submitted extremely large sets of "editorial changes" during 48 hours. Because all those changes need to be vetted appropriately, this can set back documents a long time. E.g, the l2tpv3 base spec ended up going back to the WG for review of all 250+ changes... 4) And of course the RFC editor processing itself. > That was expedited. Better example is iSCSI. Draft-20 was approved Feb > 2003 [http://www.ietf.org/IESG/Announcements/draft-ietf-ips-iscsi.ann] but > published as RFC3720 in April 2004, for a lag time of 14 months. In the case of this document, one or more normative references accounts for part of the problem. Here is the history, as indicated by the RFC Editor's queue: draft-ietf-ips-iscsi 20030212 category WORKING GROUP STANDARDS TRACK (by date received) draft-ietf-ips-iscsi 20030212 current status EDIT draft-ietf-ips-iscsi 20030212 entered queue at 2003/02/11 (1 days in unknown state) draft-ietf-ips-iscsi 20030212 is version 20 draft-ietf-ips-iscsi 20030503 entered status IANA draft-ietf-ips-iscsi 20030503 was in EDIT since 20030212 (80 days) draft-ietf-ips-iscsi 20030506 entered status RFC-EDITOR draft-ietf-ips-iscsi 20030506 was in IANA since 20030503 (3 days) draft-ietf-ips-iscsi 20030619 entered status REF draft-ietf-ips-iscsi 20030619 was in RFC-EDITOR since 20030506 (44 days) draft-ietf-ips-iscsi 20040120 entered status RFC-EDITOR draft-ietf-ips-iscsi 20040120 was in REF since 20030619 (215 days) draft-ietf-ips-iscsi 20040323 entered status AUTH48 draft-ietf-ips-iscsi 20040323 was in RFC-EDITOR since 20040120 (63 days) draft-ietf-ips-iscsi 20040421 entered status AUTH draft-ietf-ips-iscsi 20040421 was in AUTH48 since 20040323 (29 days) draft-ietf-ips-iscsi 20040429 no longer in queue draft-ietf-ips-iscsi 20040429 was in AUTH since 20040421 (8 days) draft-ietf-ips-iscsi 20040429 was in queue since 20030212 (442 days) >From the above, one can see that the REF issue added 215 days. But that accounts for only about 1/2 of the total time. Plenty of other delays there. Thomas _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf