RFC Editor Reporting
May 2010
1. Monthly Summary
The following numbers represent the May 2010 statistics for documents moving
through the RFC Editor queue.
Submitted 25
Published 33
Number of Documents in Queue per State at EOM
EDIT 34
RFC-EDITOR 25
AUTH48 34
REF 3
IANA 0
AUTH 1
TO 5
IESG 1
MISSREF 33
2. Submission and Publication Rates
There were a significant number of documents submitted in March 2010. We
believe this coincides with the high turnover in the IESG (5), as the area
directors (ADs) did their best to clear their queue before handing their duties
off to the incoming ADs.
During 2009, there was an average of 27 documents submitted and 24 documents
published per month. This is similar to the throughput of 2008, in which 27
documents were submitted and 26 documents were published per month. The graphs
show that RFC publication is typically lower during the months of November-
January, which we attribute to the holidays and vacation season. There are a
number of factors that affected the processing times for 2009; a few of
significant importance are noted here:
a. November 2008 – RFC 5378 was published, defining a new copyright notice
for RFCs.
• This created the “pre-5378 problem.”
• It also caused non-IETF stream documents to be put on hold, as it
did not account for the Independent Submission and IRTF streams.
b. February 2009 – An RFC 5378-fix was approved and announced, introducing
new text to serve as a work-around for people experiencing the "pre-5378
problem."
c. September 2009 – An updated TLP was announced to resolve issues
surrounding the inclusion of the BSD license in RFCs.
d. December 2009 – TLP 4.0 was announced, freeing the non-IETF stream
documents for publication.
e. December 2009 – RFC 5741 was published, defining new header and
boilerplate material for all streams.
f. November 2009-January 2010 – RFC Editor focused on transition from
USC/ISI to AMS.
Processing times have been impacted since November 2008 because of the issues
regarding the transition to the RFC 5378 copyright notice and legends. We
expect increased publication rates in the first quarter of 2010, as the issues
defined above have been resolved, and the documents that were stuck in AUTH48
can move forward in the publication process.
The following graphs show the annual submission and publication rates for RFCs
over the past 3 years. The effects of the above can be viewed in publication
rates in the 2008-2009 graphs (and in the processing times of editorial states
shown in Section 3).
Annual Submission and Publication Rates
3. Queue Processing Times
The subsequent figures show the processing times of documents as they move
through the RFC Editor queue. The diagrams show document counts, page counts,
and average times in queue per state (EDIT, RFC-EDITOR, and AUTH48).
The graphs will show an increased number of documents in EDIT and AUTH48.
There was an increase in the size of the EDIT queue in the last 2 months of
2009, as the RFC Editor focused their energy on transitioning the RFC Editor
project from USC/ISI to AMS. The AUTH48 state grew throughout the year to be
3x the size it was a year ago, because documents continued to be processed
through the queue, but got stuck in AUTH48 because of the issues mentioned in
Section 2.
Note that there is a ripple effect, as spikes in document and page counts may
be due to clusters of documents moving through the queue together. A cluster
does not move to the next state until the entire set is ready to be moved. For
example, in September/October 2008, there were 2 large sets of documents
released for publication (ISIS – 9 docs, SIP/SIPPING – 11 docs), which shows up
as a spike in the EDIT state around week 33–37. There is then a subsequent
spike in the RFC-EDITOR state around week 40, which results in a spike in the
AUTH48 state around week 40. These sets were published in October, creating a
burst of October publications.
Generally speaking, the more documents there are in the queue, the longer it
takes for documents to move through the queue.
Note 1: The data for the page counts used to create the graphs on the following
pages was recalculated, as the automated reports sent to the IESG/IAB and as
shown at http://www.rfc-editor.org/CurrQstats.txt were incorrect for January
and February of 2008.
Note 2: In January 2008, the queue stats were adjusted to remove 2nd and 3rd
generation MISSREFS (i.e., documents that reference other documents that are in
MISSREF) from being included in RFC-Editor time. There were some anomalies
that needed to be worked out. Data post-Feb 2008 is more accurate.
EDIT State 2010
RFC-EDITOR State 2010
AUTH48 State 2010
4. SLA Compliance Levels
The charts below show our compliance with the performance goals set in our SLA.
Note that compliance as defined in our SLA requires that 90% of the documents
published have an RFC Editor time (EDIT and RFC-EDITOR states) of less than 20
days.
This graph shows the total number of documents published per month,
highlighting those that were published with an RFC Editor time of fewer than 20
days.
The following graph shows our percent compliance with the SLA (i.e., 90% of
published RFCs will have an RFC Editor time of less than 20 days).
