Document Lifecycle Statistics

“End-to-End Delay from draft-smith to an RFC”
Document Stats IANA Stats IESG Stats Lifecycle Stats RFC Editor Stats Misc Stats

Introduction

This collection of statistics relates to the system-level behaviour in the IETF. For instance, how large fraction of time is spent in the IESG vs. WG phases? This information is useful in order to understand how the IETF works, and where we could gain the biggest rewards from improvements.

For the purposes of this analysis, we focus on the creation of RFCs. Work leading to the publication of an RFC consists of the following phases:

  • Unofficial work on an individual draft (draft-smith-something) that is neither a WG draft nor adopted by an Area Director (AD).
  • Official IETF work on a WG draft (draft-ietf-somewg-document).
  • AD and IESG processing of the draft.
  • RFC Editor processing of the draft, leading eventually to the publication of an RFC.

Methodology

The measurements on this page are based on information available in the tracker, in the tools site metafiles, and the documents themselves. The measurements have been produced from this information by the ietfmeasurements, admeasurements, idmeasurements, getauthors, docage, and docrevs, and drafttimeline tools.

The measurement system considers only documents that have made it to an RFC, and, for now, only documents that have been shepherded by one of the current ADs. RFC publication date is taken is from the time the publication is recorded in the tracker. IESG process is considered to have ended on the day that the document approval is recorded on the tracker. WG process begins on the day that the WG draft version 00 is submitted, and ends on the day that the tracker records a publication request. Version 00 submission date is normally available in the tools metafiles, but in some cases it needs to be recovered from the document itself. Finally, work on an individual document begins from its version 00 submission and ends at the beginning of the WG phase. The relationship between individual and WG documents is retrieved from the tracker and an additional database built from Lars Eggert's analysis of missing replace information.

Limitations

For now, the main limitation in these measurements is that the divisions between the phases is fuzzy. For instance, it is common for RFC Editor to wait for a long time for the authors to respond in AUTH48. As a result, a long RFC Editor phase does not necessarily imply that the RFC Editor is at fault. Similarly, documents often spend a significant amount of time waiting for a revision to address IESG review issues.

Another major limitation is that the relationship of WG documents to individual documents is not fully known.

A third major limitation (for now) is that independent submissions via the RFC Editor are not correctly supported yet.

Finally, as the data goes back more than a few years, (timeframe 2002 and prior to that) metadata and the tool's ability to understand tracker events detoriates. There is even some missing document revisions, so analysis via getauthors is incapable of reconstructing all metadata.

Overall Process

WARNING: THIS SECTION IS BEING WORKED ON. THE RESULTS ARE KNOWN TO BE FALSE AT THIS TIME.

First, we have analysis of how the process for WG drafts has developed over the years. The distribution of process times can be found here. Some of the shortest and longest processing times are listed as well. Timing and document size related extreme situations are here. Other exceptional situations have been listed here.

More stats to follow...

Lifecycles of Published RFCs

Information about the lifecycle of each individual RFC published can be found here.

Lifecycles of All Drafts

Information about the lifecycle of each current and past Internet Draft can be found here.

The document statistics software, bandwidth, servers, and source data have been brought to you by:

Jari Arkko   Ericsson   IETF