Reports
This page contains useful information regarding the performance of the RFC Production Center (RPC). It includes news items (updated as needed) and stats about production that are updated on a quarterly basis.
The RFC Editor strives to provide excellent and timely editorial service. To ensure the RFC Editor is providing the best possible service, the RPC regularly reviews its processes and liaises with the communities served. In addition, the rfc-interest mailing list is dedicated to discussing topics related to the RFC Editor.
Table of Contents
Service Level Agreement
The Service Level Agreement indicates the following:
- Tier 1: When there is a normal amount of input, the SLA is 67% of documents published within the period have an RFC Editor-controlled time that adds up to six weeks or fewer. Where ‘normal’ is defined as less than 1950 Pages gone to EDIT (PGTE).
- Tier 2: When there is a moderate burst in the amount of input, then the SLA shifts to 50% of documents published within the period have an RFC Editor-controlled time that adds up to 12 weeks or fewer within the given quarter or the subsequent quarter. Where a ‘moderate’ burst is defined as 1950 – 3072 (inclusive) Pages gone to EDIT (PGTE).
- Tier 3: When there is a large burst in the amount of input, then the SLA must be discussed and renegotiated. Where ‘large’ burst is defined as greater than 3072 Pages gone to EDIT (PGTE).
The figures below indicate whether we are meeting this goal.
“Tier 2*” indicates when Tier 2 is being applied in the “subsequent quarter” as mentioned above.
Figure 1. SLA Summary
Figure 2. PGTE and Pages Submitted & Published (by Quarter)
Figure 3. Number of Pages in Primary Processing States (i.e., no third-party holds)
Note that PGTE provides a more accurate picture of the RPC’s incoming workload for a given time period (than the number of documents entering the queue).
Also note that there is a ripple effect, as spikes in document counts in any one state 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. You will often see bursts in EDIT, then RFC-EDITOR, and finally PUB, as the set of documents move through the states together to publication.
Generally speaking, the more documents there are in the queue, the longer it takes for documents to move through the queue.
Notes
Other Reports
| Report | Description |
|---|---|
| Current Queue (sortable) | A list of all of the documents in the RFC Editor queue, ordered by state. (Updated dynamically) |
| Queue Summary | RFC Editor queue summary (Updated weekly) |
| Comprehensive Sub/Pub Stats | Detailed submission and publication data |
| Reports Archive | Pre-2014 reports (Was updated monthly) |
| Annual Publication Rate | Bar graph showing the number of RFCs published per year since 1969. (Updated annually). |
| RFC Editor Reports at IETF | Summary of the RFC publication process, including the state of the queue and a breakdown of the reasons for any long delays in the publication process. The report also may include recent changes in policy and improvements in tools or procedures. (Updated quarterly) |
| RFC Errata Reports | Summary of errata reports and their status, stream, and type. |
| RFC Status Changes (post-publication) | List of the RFCs whose statuses have changed since publication. (Updated as needed) |
This page is archived annually; see 2014 • 2015 • 2016 • 2017 • 2018 • 2019 • 2020 • 2021 • 2022 • 2023