Statistics for IETF-related Requests
Reports
Year | Monthly Reports | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
2024 | Jan | Feb | Mar | Apr | May | Jun | Jul | Aug | Sep | Oct | ||
2023 | Jan | Feb | Mar | Apr | May | Jun | Jul | Aug | Sep | Oct | Nov | Dec |
2022 | Jan | Feb | Mar | Apr | May | Jun | Jul | Aug | Sep | Oct | Nov | Dec |
2021 | Jan | Feb | Mar | Apr | May | Jun | Jul | Aug | Sep | Oct | Nov | Dec |
2020 | Jan | Feb | Mar | Apr | May | Jun | Jul | Aug | Sep | Oct | Nov | Dec |
2019 | Jan | Feb | Mar | Apr | May | Jun | Jul | Aug | Sep | Oct | Nov | Dec |
2018 | Jan | Feb | Mar | Apr | May | Jun | Jul | Aug | Sep | Oct | Nov | Dec |
2017 | Jan | Feb | Mar | Apr | May | Jun | Jul | Aug | Sep | Oct | Nov | Dec |
2016 | Jan | Feb | Mar | Apr | May | Jun | Jul | Aug | Sep | Oct | Nov | Dec |
2015 | Jan | Feb | Mar | Apr | May | Jun | Jul | Aug | Sep | Oct | Nov | Dec |
2014 | Jan | Feb | Mar | Apr | May | Jun | Jul | Aug | Sep | Oct | Nov | Dec |
2013 | Jan | Feb | Mar | Apr | May | Jun | Jul | Aug | Sep | Oct | Nov | Dec |
2012 | Jan | Feb | Mar | Apr | May | Jun | Jul | Aug | Sep | Oct | Nov | Dec |
2011 | Jan | Feb | Mar | Apr | May | Jun | Jul | Aug | Sep | Oct | Nov | Dec |
2010 | Jan | Feb | Mar | Apr | May | Jun | Jul | Aug | Sep | Oct | Nov | Dec |
2009 | Jan | Feb | Mar | Apr | May | Jun | Jul | Aug | Sep | Oct | Nov | Dec |
2008 | Jan | Feb | Mar | Apr | May | Jun | Jul | Aug | Sep | Oct | Nov | Dec |
2007 | May | Jun | Jul | Aug | Sep | Oct | Nov | Dec |
Methodology
The statistics presented on this website were gathered by extracting data from our ticketing system queues into daily logs for each queue that are then concatenated into monthly logs for each queue.
The logs were then processed extract the transaction history for each ticket in each queue, from the date the ticket was opened until the date the ticket was closed, or the end of the monthly log for tickets not yet closed.
The number of open tickets, closed tickets, the amount of time spent in each of IANA processing, Other, and Requestor related states (for which transaction data is available), and the total elapsed time from ticket open to close (or the end of the present reporting period), as well as the mean processing time, median processing, and standard deviation from the mean processing time is presented.
Definitions
Below are tables containing the definitions for the queues in which we track IETF-related requests.
Definitions for Internet Draft Processing
This refers to queues for Internet Drafts in Last Call (drafts-lastcall), Evaluation (drafts-eval), Approved by the IESG (drafts-approved), and drafts requiring references to be updated (drafts-update-refs).
State | Description |
---|---|
Created | A request is created when we receive either a notification from the IETF Secretariat that a document has been approved by the IESG for publication as an RFC OR when the RFC-Editor notifies us that they intend to publish a document as an RFC. |
Resolved | A request is resolved when the RFC-Editor confirms that they have received our notification of completed actions for the document OR when we confirm that there are no IANA Considerations. |
Processing Time | The number of calendar days between the date the ticket was Created and Resolved. If a ticket is not yet resolved, Processing Time is the number of workdays between the date the ticket was created and the last date of the reporting period. |
Definitions for Protocol Assignments
This refers to queues for New Port Assignments (iana-ports), Modifications to Port Assignments (port-modifications), Multicast IP Address registrations (iana-multicast), IANA TRIP ITAD Registrations (iana-trip), Media Type Registrations (iana-mime), and all other protocol parameters (iana-prot-param).
State | Description |
---|---|
Created | A request is created when the user has submitted a template, web form or email. |
Resolved | A request is resolved when the ticket is closed either because the requested resource has been assigned, the resource registration has been modified or deleted as requested or the ticket has either been administratively closed or withdrawn by the requester. |
Rejected | The request was inappropriate or could not be met for policy reasons. |
Processing Time | The number of calendar days between the date the ticket was Created and Resolved. If a ticket is not yet resolved, Processing Time is the number of workdays between the date the ticket was created and the last date of the reporting period. |
Attribution of responsibility
In our processing, we attribute time to various responsible parties, divided into these categories.
State | Description |
---|---|
IANA | This includes the time we spent working on the request |
Third party | This includes time spent with the designated expert, IESG, Authors, Working Group Chairs, RFC-Editor or other outside party |
Requestor | This includes the time the request is with the requester. For the case of drafts-lastcall, drafts-eval, drafts-approval and drafts-update-refs queues, the requestor is either the IESG or the RFC-Editor so there is no “requestor time”. |
Zombie | This state appears if the ticket was created prior to January 1, 2007 and no state was known or given at the time these statistics were being tracked. Those with this state do not exist as all tickets created before January 1 have been resolved. |