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.
|
