Hi all,
Please find below the RPC report for May. This report is also available
at https://notes.ietf.org/rpc-report-202605?view
Best regards,
Jean
# RFC Production Center Report - May 2026
Previous notes: https://notes.ietf.org/rpc-report-202604#)
RPC project roadmap: https://github.com/orgs/rfc-editor/projects/2
## Big Picture
The RPC has been working with IETF Tools Team to overhaul its tools and
website in order to handle RFCs with five-digit numbers and to improve
editor productivity. We are also working to improve the transparency of
RPC processes and to improve our support of author processes. **The new
website and queue management system is expected to be deployed the week
of 18 May.** We had been planning for the week of 11 May but found a gap
in the datatracker that had to be addressed before launch.
In addition to the tools overhaul, a full list of the RPC's strategic
transformations can be found at the end of this report, and each project
is tied to one or more transformations (given in parentheses).
## Project Updates
### RPC Retreat
The RPC held a two-day strategic planning session in mid April to review
its strategic transforms, go over plans for launching the new website
and tools, discuss the benefits and challenges of defining a new service
level agreement, and explore how AI might be used in the editorial
process. A blog post about the retreat will be available soon.
### GitHub Roadmap (Reflecting Changing Author Processes AP-2, AP-3)
The RPC is offering an optional AUTH48 process whereby the RPC shares
its proposed edits with authors using a pull request made against the
approved source file in an RPC-created GitHub repo. This GitHub-based
process is currently being offered on limited basis, and the RPC is
accepting 5 documents per month. For details, see the GitHub roadmap
(https://rpc-wiki.rfc-editor.org/rpc/wiki/doku.php?id=rpc_github_roadmap).
The RPC asks authors if they would like to participate when their
documents enter the publication queue via an intake form.
There are currently 30 docs in the queue whose authors have agreed to
participate in this optional process. We are limiting the number of
documents to 5 per month until we have exercised this AUTH48 process
some more. We can accept 2 documents this month.
### Supporting kramdown-rfc as a submission format (Reflecting Changing
Author Processes AP-1)
The RPC is accepting kramdown-rfc files as a submission format on a
limited bases (5 documents per month). Authors can opt in by responding
to the intake form when their document enters the queue.
The RPC will edit these kramdown-rfc files and make them available at
the start of AUTH48. More information about the pilot program can be
found on the RPC wiki
(https://rpc-wiki.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_kramdown_rfc).
There are 24 kramdown-rfc documents in the queue; one of which is
currently in AUTH48. We can accept 3 kramdown-rfc documents this month.
### Updates to SVG guidance (Community Requirements CR-3)
RFC 9896 (https://www.rfc-editor.org/info/rfc9896) obsoletes RFC 7997
and sets policy for SVG artwork. Current guidance can be found on
https://authors.ietf.org/diagrams. The RPC is working with the IETF
Tools Team to identify tools updates (i.e., xml2rfc, svgcheck, idnits)
and drafting new guidance that better supports accessibility. This
accessibility guidance will be added to authors.ietf.org.
The RPC is researching open-source tools that can create accessible SVG
easily so we can provide recommendations to the community.
### RFCXML vocabulary updates (Community Requirements CR-4)
The RPC has been assessing RFCXML vocabulary issues across multiple
issue trackers and has been moving them to a new issue tracker
(https://github.com/ietf-tools/RFCXML):
* https://github.com/ietf-tools/xml2rfc - the main repo for tools issues
and had been the main repo for vocabulary issues.
* Most of the open issues have been evaluated. We have been working
with the Tools Team to move issues over.
* https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/issues - 51
open issues.
* We have copied issues from this repo to the RFCXML repo with
pointers to the original discussions.
* https://github.com/rfcseries-wg/new-topics - 28 open issues.
* To be assessed
* https://github.com/jrlevine/draft-rswg-xml2rfcv3-implemented/issues -
4 open issues.
* To be assessed
This project saw no significant changes since the last report.
### Improved queue information (Transparency TR-3, TR-5)
As part of the preparation for discussing a new SLA, the RPC has been
working on requirements for improved queue visualization. We have been
analyzing queue data going back to 2018 and experimenting with different
presentation formats. Goals for new visualization include being able to
assess at a glance queue health and also individual document status.
Work on the new queue management system (Purple) includes adding the
ability to automatically track how long a document waits for editor
assignment, which is something the current system can't track. We are
manually collecting these statistics to create a baseline that can be
used to help assess the impact of new tools. Purple will also track
other things that block RPC work on documents, such as when a document
is missing a normative references, any stream holds, or when the RPC
needs input from authors.
Queue information will be displayed to the community on a new subsite,
queue.rfc-editor.org. Details will include:
* Clearer labels, such as "In Progress (First Edit)" rather than "EDIT"
and "In Final Review" rather than "AUTH48"
* More details including whether a document is part of the kramdown-rfc
or GitHub pilot program
* Visualizations of cluster dependencies
This month, updates were made to cluster visualizations and final review
pages.
### Tooling (T)
#### New Queue Management System: Purple (Process Efficiency PE-3,
Tooling T-2, T-3)
The Tools Team has been working on the replacement of the queue
management system, known as Purple (https://github.com/ietf-tools/purple).
Focus this month has been on improving the following features:
- cluster visualizations and document assignments to new or existing
clusters
- editing assignments (initial assignment, re-assignment, and finishing)
- error messages and error handling
- search for authors, shepherds, and stream contacts information
#### New rfc-editor.org Website: Red (T-2)
The Tools Team has been working on the new website, known as Red
(https://github.com/ietf-tools/red). Feedback received when Red was
made available during IETF 124 as a beta site is being incorporated, and
work has also been focusing on APIs. Changes that will be made to
existing APIs are documented at
https://github.com/ietf-tools/red/blob/main/CHANGELOG.md and include
using RFC numbers that can be 1-5 digits long without leading zeroes.
The use of trailing slashes in URIs will be made consistent. Redirects
may be put into place, so please ensure that your HTTP client is
configured to follow redirects.
Work this month focused on updates to reader content, dependency
upgrades, accessibility fixes, and fixes to redirects.
#### New Editing Software: DraftForge (T-1)
The Tools Team is building DraftForge (https://draftforge.ietf.org/), an
editing platform that will provide RFCXML validation, output file
creation, GitHub integration, datatracker submission for I-D authors,
and replacements for the 20+ checker scripts the RPC now runs at the
command line.
The RPC team is now exercising DraftForge features. The latest version
of DraftForge has improved abbreviation checking, now supports aasvg,
and supports better diff file creation.
#### xml2rfc and Self-hosted Fonts
Before IETF 126, the RPC will work with the Tools Team to update the
URLs in existing HTML files of RFCs to point to fonts at
static.ietf.org. This will be a surgical edit to the HTML files rather
than a rerendering. This is to fix an HTML formatting issue where bold
text no longer is displayed as bold in Chrome browsers (The issue at
Chrome was closed as wontfix
(https://issues.chromium.org/issues/447361040)).
This project saw no changes since the last report.
## Document Work Updates and Hot Topics
**Note:** As docs move through the queue, they go through the following
states: AUTH (for the intake form) -> EDIT (which includes formatting,
reference checking, and content editing) -> RFC-EDITOR (2nd editing
pass, focused on open questions from EDIT, IANA Considerations updates,
and source code validation) -> AUTH48 (author approval) -> AUTH48-DONE
(final checks before publication) -> PUB (final checks, index updates,
public placement of RFCs, and RFC announcement). Different editors
handle these different states, which is why documents are listed
multiple times below. See the RFC Publication Process
(https://authors.ietf.org/rfc-publication-process) for more information.
The updates below are since the 7 April RPC report
(https://notes.ietf.org/rpc-report-202603?view).
Alice
* Completed
* RFC-EDITOR
* 9956 (draft-ietf-tsvwg-nqb-33)
* 9957 (draft-briscoe-docsis-q-protection-07)
* 9959 (draft-ietf-tsvwg-careful-resume-24)
* 9962 (draft-farinacci-lisp-decent-22)
* 9967 (draft-ietf-scim-events-16)
* Published 2 RFCs
Alanna
* In progress
* EDIT
* draft-ietf-calext-jscontact-uid-07
* draft-ietf-netmod-system-config-20
* AUTH48
* 9955 - draft-ietf-pquip-hybrid-signature-spectrums-07 (C553)
* 9969 - draft-iab-ai-control-report-02
* Completed
* EDIT
* draft-ietf-bmwg-mlrsearch-15 (Markdown, AUTH48 will be in GitHub)
* draft-ietf-dmarc-dmarcbis-41 (C539, AUTH48 will be in GitHub)
* draft-ietf-dmarc-aggregate-reporting-32 (C539)
* draft-ietf-dmarc-failure-reporting-25 (C539, AUTH48 will be
in GitHub)
* draft-ietf-rift-kv-tie-structure-and-processing-09
* AUTH48
* 9973 - draft-ietf-tls-8773bis-13 (C430)
* 9954 - draft-ietf-tls-hybrid-design-16 (C553)
Madison
* In progress
* EDIT
* draft-ietf-bess-mvpn-evpn-sr-p2mp
* AUTH48
* RFC 9964 - draft-ietf-cose-dilithium-11
* RFC 9958 - draft-ietf-pquip-pqc-engineers-14 (edited in MD)
* Completed
* EDIT → RFC-EDITOR
* draft-ietf-bfd-optimizing-authentication-36 (C562)
* draft-ietf-bfd-secure-sequence-numbers-27 (C562)
* draft-ietf-core-href-30 (C561; edited in MD, AUTH48 will be
in GitHub)
* draft-ietf-lamps-keyusage-crl-validation-04 (edited in MD,
AUTH48 will be in GitHub)
* AUTH48-DONE → PUB Checks
* RFC 9962 - draft-farinacci-lisp-decent-22
* April Errata Stats
* Submitted: 36
* Deleted as spam: 11
* Verified: 8
* Rejected: 1
* HFDU: 1
* Note: These numbers include EIDs marked as Rejected/Verified/HFDU
by both the RPC and ADs in the month of April.
Sarah
* In progress
* Pre-edit / Format:
* XML: 6
* Markdown: 2
* Completed
* EDIT state: 1
* Sent intake forms: 12
* Added to the queue: 10
* Pre-edit / Format:
* XML: 8
* Markdown: 3
Rebecca
* In progress
* RFC-EDITOR
* 9971 (draft-ietf-bmwg-mlrsearch-15)
* markdown; AUTH48 in GitHub
* moving to AUTH48 very soon
* draft-ietf-core-href-30
* markdown; AUTH48 in GitHub
* AUTH48
* 9970 (draft-ietf-stir-rfc4916-update-07)
* Completed
* EDIT
* draft-ietf-stir-rfc4916-update-07
* RFC-EDITOR
* 9954 (draft-ietf-tls-hybrid-design-16)
* 9955 (draft-ietf-pquip-hybrid-signature-spectrums-07)
* 9958 (draft-ietf-pquip-pqc-engineers-14)
* 9970 (draft-ietf-stir-rfc4916-update-07)
* EDIT, RFC-EDITOR, and AUTH48:
* 9948 (draft-alvestrand-protocol-police-00) - April 1 RFC
Megan
* In progress
* EDIT
* draft-ietf-netconf-udp-client-server-10 (C463)
* draft-ietf-netconf-netconf-client-server-41 (C463)
* AUTH/REF
* draft-ietf-i2nsf-capability-data-model-32 (C405)
* draft-ietf-i2nsf-registration-interface-dm-26 (C405)
* draft-ietf-i2nsf-nsf-facing-interface-dm-29 (C405)
* draft-ietf-i2nsf-nsf-monitoring-data-model-20 (C405)
* draft-ietf-i2nsf-consumer-facing-interface-dm-31 (C405)
* draft-ietf-i2nsf-applicability-18 (C405)
* AUTH48
* draft-ietf-stir-servprovider-oob-08 / RFC-to-be 9888
* AD override requested due to lack of response.
* draft-ietf-cose-merkle-tree-proofs-18 / RFC-to-be 9942 (C557)
* draft-ietf-scitt-architecture-22 / RFC-to-be 9943 (C557)
* draft-ietf-emu-eap-arpa-10 / RFC-to-be 9965 (C558)
* draft-ietf-emu-bootstrapped-tls-11 / RFC-to-be 9966 (C558)
* draft-ietf-grow-bmp-bgp-rib-stats-17 / RFC-to-be 9972
* draft-ietf-dnsop-cds-consistency-11 / RFC-to-be 9975
* draft-ietf-opsawg-prefix-lengths / RFC-to-be 9977
* draft-ietf-mailmaint-mressageflag-mailboxattribute-14 /
RFC-to-be 9979
* draft-ietf-openpgp-pqc-17/ RFC-to-be 9980
* draft-ietf-sidrops-manifest-numbers-09 / RFC-to-be 9981
* Completed
* EDIT
* draft-ietf-cose-hash-envelope-10
* EDIT & RFC-EDITOR
* draft-ietf-grow-bmp-bgp-rib-stats-17 / RFC-to-be 9972
* draft-ietf-dnsop-cds-consistency-11 / RFC-to-be 9975
* draft-ietf-opsawg-prefix-lengths / RFC-to-be 9977
* draft-ietf-mailmaint-mressageflag-mailboxattribute-14 /
RFC-to-be 9979
* draft-ietf-openpgp-pqc-17/ RFC-to-be 9980
* draft-ietf-sidrops-manifest-numbers-09 / RFC-to-be 9981
* AUTH48-DONE
* draft-ietf-tsvwg-nqb-33 / RFC-to-be 9956
* draft-ietf-briscoe-docsis-q-protection-07 / RFC-to-be 9957
Kaelin
* In progress
* EDIT:
* draft-ietf-tls-deprecate-obsolete-kex-08 (C430)
* AUTH48:
* RFC 9978 (draft-ietf-bfd-stability-21) (AUTH48 in GitHub)
* Completed
* EDIT:
* draft-ietf-asap-sip-auto-peer-41
* draft-ietf-httpbis-safe-method-w-body-14
* AUTH48 (passed along for publication)
* RFC 9944 (draft-ietf-scim-device-model-18)
* RFC 9959 (draft-ietf-tsvwg-careful-resume-24)
Ted
* In progress:
* draft-ietf-sshm-mlkem-hybrid-kex-10
* draft-ietf-lisp-geo-20
* draft-ietf-httpbis-incremental-04
* draft-ietf-calext-ical-tasks-17
* draft-ietf-ace-key-groupcomm-oscore-21
* draft-ietf-lsr-ospf-ls-link-infinity-25
* draft-ietf-ace-oscore-gm-admin-17
* draft-irtf-cfrg-aegis-aead-18
* draft-ietf-oauth-cross-device-security-15
* draft-ietf-pquip-hbs-state-04
* Completed 20 reference reviews since last community report
Sandy
* In progress
* EDIT
* draft-ietf-oauth-browser-based-apps
* draft-ietf-core-yang-sid-pen
* RFC-EDITOR
* draft-ietf-ntp-over-ptp (GitHub)
* draft-ietf-avtcore-rtp-haptics
* draft-ietf-httpbis-safe-method-w-body (GitHub)
* AUTH48
* 9846 - draft-ietf-tls-rfc8446bis (AUTH48 initiated Dec 2025)
* 9974 - draft-ietf-bier-oam-requirements
* Completed
* EDIT
* draft-ietf-tls-tls13-pkcs1
* draft-ietf-bier-oam-requirements
* RFC-EDITOR
* draft-ietf-tls-tls13-pkcs1
* draft-iab-nemops-workshop-report
* draft-ietf-cose-dilithium
* draft-ietf-bfd-stability
* AUTH48
* 9973 - draft-ietf-tls-8773bis-13 (C430)
* 9954 - draft-ietf-tls-hybrid-design-16 (C553)
* Published 12 RFCs
Karen
* In progress
* RFC-EDITOR
* draft-ietf-dmarc-aggregate-reporting-32 (C539)
* draft-ietf-dmarc-failure-reporting-25 (C539)
* AUTH48:
* draft-ietf-scim-events-16 (RFC-to-be 9967)
* Completed
* EDIT:
* draft-ietf-scim-events-16
* draft-iab-nemops-workshop-report-04 (MD exp)
* draft-ietf-ntp-over-ptp-08 (GitHub exp)
* draft-ietf-rats-msg-wrap-23
* draft-ietf-avtcore-rtp-haptics-14 (MD exp)
* RFC-EDITOR:
* draft-ietf-pim-sr-p2mp-policy-22 (C556) (RFC-to-be 9960)
* draft-ietf-pim-p2mp-policy-ping-25 (C556) (RFC-to-be 9961)
* draft-iab-ai-control-report-02 (RFC-to-be 9969) (MD exp)
* draft-ietf-dmarc-dmarcbis-41 (C539) (RFC-to-be 9989) (GitHub exp)
* EDIT, RFC-EDITOR, and AUTH48:
* RFC 9949 (draft-not-an-rfc-busa-tls-00) (April 1st RFC)
* AUTH48 (all were published):
* RFC 9914 (draft-ietf-roll-dao-projection-40)
* RFC 9946 (draft-ietf-ippm-capacity-protocol-25
* RFC 9968 (draft-iab-nemops-workshop-report-04)
## FYIs
### Stats
* Queue stats:
https://rpc-wiki.rfc-editor.org/doku.php?id=2026stats#may_2026 as of 13
May 2026
* Average times in EDIT and RFC-EDITOR:
(https://www.rfc-editor.org/rpc/wiki/doku.php?id=2026stats#figure_1average_time_for_a_document_to_reach_auth48):
10.1 (down from 12.8 in the last report)
## Strategic Transformations
The full list of strategic transformations is provided here for reference.
### Productivity
#### Process Efficiency (PE)
1. One editor does many tasks **→** Specialists provide expertise in
document intake, formatting, reference checking. (PE-1)
2. The RPC has no information regarding the authors' intentions that
shaped the creation of the document (e.g., is the document supposed to
be similar to another RFC?), requiring considerable work to figure out
intentions **→** The document comes with as much information as
possible from the authors, thus reducing RPC workload. (PE-2)
3. Editing notes about a document are split across multiple places
(mailing list, ARO style sheet, internal wiki) **→** All editing notes
about a document are in a single, easily accessible place. (PE-3)
4. (Closed) There is lack of a documented process for the rare case when
a document is of such poor editorial quality that it should be returned
to the stream for improvements **→** A documented process that includes
guidance on how the RPC team identifies such a document early in the
process. (PE-4)
5. The RPC's internal procedure documentation conflates copyediting
guidance and tools details, making maintenance difficult **→** modular,
easier-to-maintain procedures for copyediting and tools. (PE-5)
#### Tooling (T)
1. Editing requires lots of time-consuming manual work **→** As much as
possible is automated. (T-1)
2. The production platform is very old and is time-consuming to maintain
**→** Professionally designed and written production platform. (T-2)
3. ADs struggle with finding RPC requests **→** RPC requests are found
on the AD dashboard. (T-3)
#### Community Requirements (CR)
1. RPC does lots of work, some of which may not be required to be done
by the RPC **→** RPC only does the work it needs to do, with clearly
defined limits of the RPC's responsibility for document quality, beyond
which it is the responsibility of the authors. (CR-1)
2. Lots of time-consuming manual work due to sizable RFCXML feature set
**→** Less work due to streamlined RFCXML feature set. (CR-2)
3. Out-of-date and rigid SVG guidance **→** more flexible guidance that
supports accessibility. (CR-3)
4. RFCXML v3 issues spread out in multiple places **→** consolidated
place for all vocab-related issues. (CR-4)
5. The RFC Style Guide (7322bis) is stuck in a perpetual I-D state
because we don't know when we are done **→** Split into an RFC
containing guiding principles and use authors.ietf.org to capture
details. (CR-5)
6. No guidance on accessibility **→** Guidance and training for authors
that helps them make their documents accessible. (CR-6)
### Transparency (TR)
1. The inner workings of the RPC are opaque to the IETF community, which
means that the nature and value of the work is not understood **→**
Inner workings of the RPC are sufficiently transparent for the IETF
community to understand the value of the work. (TR-1)
2. Private communications channels with the community create issues such
as hidden decisions, poor attitude, and repeated questions **→** All
communications with the community are through open channels. (TR-2)
3. Authors lack details about their documents' progress through the
queue **→** A document's progress through the queue is clearer and more
detailed. (TR-3)
4. RPC doesn't have a personal aspect, and is just seen as a black-box
service. The tenure and skills of the team are not known **→** The
community knows the team and their tenure and skills. (TR-4)
5. Current SLA is not fit for purpose **→** An SLA that is fit for
purpose, adapted to the RPC's specific circumstances, and covering
qualitative and quantitative measures. (TR-5)
### Reflecting Changing Author Processes (AP)
1. The RPC does not accept markdown as a submission format **→** The RPC
accepts and edits markdown documents. (AP-1)
2. The RPC uses a shared file system and manual version control **→**
The RPC uses a modern version control system. (AP-2)
3. Authors are frustrated backporting RPC edits to their repos **→**
There are processes and tools that support an author's use of GitHub. (AP-3)
--
rswg mailing list -- [email protected]
To unsubscribe send an email to [email protected]
