Report Summary 2018
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 monthly and 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.
2018 notes: 208 RFCs were published; 35% of these were associated with a cluster. 98% of the documents were published within Tier 2 goals. 2018 has been a very busy year, even though the submission and publication rates were low. For example, the team has made ISE transitional updates, taken on additional tasks regarding YANG (format checks), experimented with AUTH48 using GitHub, started using id2xml as part of our production process, and tested XMLv3-related tools and held various discussions throughout.
Q4 2018 notes: In Q4, the documents entering the queue are releasing others from MISSREF, which is why PGTE is higher than Submitted (see Figure 2). The editors are working through the queue and test v3-related tooling. As previously noted, Figure 3 shows a steady decline in the number of pages in RPC actionable states since July. However, as PGTE increased, the number of docs in those states grew as well.
The RFC Editor responded to two legal requests, one of which was a request for 14 individual declarations.
Q3 2018 notes: The editors continue to diligently work through the documents in the queue. Figure 3 shows a steady decline in the number of pages in RPC actionable states since July. In addition to continuing testing of svgcheck, rfclint, and rfc-xmldiff, the RPC has also started testing the tool that converts .xml to .txt. As discussed with the stream managers previously, we are starting to see the impact of the format work on queue processing times.
As an experimental process, GitHub was used during AUTH48 for draft-ietf-tls-tls13-28, which was published as RFC 8446. Information about the process is available at https://www.rfc-editor.org/rpc/wiki/doku.php?id=github_auth48_experiment. The relevant parties have agreed that draft-ietf-rtcweb-jsep-24 is not an appropriate test case for this GitHub experiment. The IESG will select an alternate document to continue the experiment.
Q2 2018 notes: While the number of documents and pages moved to EDIT have slowed so far in Q2, the editors continue to work their way through the Q1 influx. In addition to the heavy queue load, the editors are also working on testing v3-related tools, namely svgcheck, rfclint, and rfc-xmldiff. The RFC Editor has also agreed to partake in an experiment whereby GitHub will be used for AUTH48 processing for draft-ietf-tls-tls13-28 (currently being edited) and draft-ietf-rtcweb-jsep-24 (currently in MISSREF). The usual editorial process will be altered in that all questions will be held until AUTH48, which may elongate AUTH48.
As noted for Q1, the RPC has developed a process to check that YANG modules are well formatted and ready to be posted on the IANA website. The RPC continues to work with Martin Bjorklund and the YANG authors to improve the process of preparing and passing module files to IANA for posting on their site.
The RFC Editor responded to one legal request.
Q1 2018 notes: As previously mentioned, the IESG indicated that there would be an increase in submissions this quarter. The increase in submissions we saw in Q4 2017 continued this quarter. The number of pages submitted in Q1 is the highest in the last two years; PGTE is the second highest (see figures 1 and 2). PGTE increased significantly (40%) during March, so we expect the processing times in Q2 to be impacted while we work through the queue.
44% of the RFCs were part of a cluster. 15% of the RFCs (25% of the published pages) were part of Cluster 336. As part of the publication process for C336, new processes were developed to 1) check that the YANG modules are well formatted and 2) ensure the YANG modules are ready to be passed to IANA for posting on their site.
In addition, the RPC continued to 1) prepare their systems to publish multiple file formats and 2) create and revise internal documentation to accommodate updated procedures necessary as v3 tools are released and updated.
2017 notes: Throughout the year, 267 I-Ds were approved for publication, and 263 RFCs were published. 70% of the published RFCs had an RET of 6 weeks or less, which means the RPC met the SLA at Tier 1.
The RPC is expecting a busy and tough Q1 2018, as the IESG has indicated that there will be an increase in submissions over the next few months, as there will be some AD turnover in March 2018; there has been a more significant increase in submissions in Q4. In addition, a number of documents from Cluster 238 are expected to be released from MISSREF in the near future. The increase in submissions, along with the expected release of additional v3 tools for testing, will challenge the editors in 2018.
Q3 & Q4 2017: The RPC continues to work on their systems and tools in preparation for the transition to host multiple file formats. The editors continued id2xml testing and have started to use id2xml to generate XML files when an author-submitted source file is not available. In addition, the RPC tested how the existing system and tools handle UTF-8 and made updates where possible. The editors completed testing and worked with authors of selected documents through the AUTH48 process. The first RFCs that contain UTF-8 characters were published as follows:
RFC 8187: Indicating Character Encoding and Language for HTTP Header Field Parameters
RFC 8264: PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols
RFC 8265: Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords
RFC 8266: Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames
The number of pages submitted and moved to EDIT has declined since Q1 2017 (see Figure 2). The decrease in submissions allowed the editors more time to focus on testing and to prepare for the transition to new format-related tools.
The RFC Editor responded to two legal requests.
Q2 2017: In response to requests on the rfc-interest list, stable and “pretty” URLs are now available for RFC errata entries. They appear as <https://www.rfc-editor.org/errata/eidXXX>. This means that errata references can contain a URL for a specific erratum. The RFC Style Guide will be updated to incorporate the new URLs.
Tool testing related to the xml2rfc v3 format has begun. The RPC is actively testing and providing feedback regarding id2xml. In addition, the RPC is evaluating how the existing tools handle UTF-8 characters.
Q1 2017: We experienced the typical Q1 surge in document submissions associated with the March changeover in the IESG. The RPC published the largest number of pages in a given quarter within the last two years.
Authors have been highly responsive, allowing a number of documents to progress out of AUTH48 and AUTH48-DONE. This allowed a number of documents to clear the last AUTH48 hurdles and be announced as RFCs.
The editors dealt with a complicated AUTH48 for portions of Cluster 238, as reference chains were not strictly dependent on normative references, but informative also (per author request). So far this year, 36% of the published RFCs have been part of a cluster.
|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)|