"Eric A. Hall" <ehall(_at_)ehsco(_dot_)com> 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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf