Hi all,
Instead of hosting a meeting to go over these contents, the RPC is
reporting this information via email. This report is also available at
https://notes.ietf.org/rpc-report-202601?view
The RPC will continue to host meetings to discuss strategic planning,
and we will announce those meetings on this list.
Best regards,
Jean
# RFC Production Center Report - January 2026
Previous notes:
https://notes.ietf.org/rpc-report-202512?view
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.
A full list of the RPC's strategic transformations
(https://notes.ietf.org/rpc-report-202601?view#Strategic-Transformations)
can be found at the end of this report, and each project is tied to one
or more transformations (given in parentheses).
## Team Update
Long-time editor Lynne Bartholomew is retiring at the end of this month.
Lynne started with the RPC in 2010 and has edited over 700 RFCs
(nearly 24,000 pages). Her meticulous edits have helped make the
Internet better for everyone, and she will be missed. The RPC wishes
her a happy retirement!
## Project Updates
Note that these updates are rather light for this reporting period due
to the winter holidays.
### 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://www.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 14 docs in the queue whose authors have agreed to
participate in this optional process. One of these documents has entered
AUTH48. We are limiting the number of documents to 5 per month until we
have exercised this AUTH48 process some more, and we have hit that limit
for January.
### 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://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_kramdown_rfc).
There are 18 kramdown-rfc documents in the queue; four of which are
currently in AUTH48. We can accept 4 more kramdown-rfc documents this month.
### Updates to SVG guidance (Community Requirements CR-3)
draft-editorial-rswg-svgsinrfcs
(https://datatracker.ietf.org/doc/draft-editorial-rswg-svgsinrfcs/),
which is now in AUTH48, obsoletes RFC 7997 and sets policy for SVG
artwork. Current guidance can be found on authors.ietf.org
(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.
This project saw no significant changes since the last report.
### 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. We
have started collecting statistics on how long documents wait for an
editor assignment to create a baseline that can be used to help assess
the impact of new tools.
### Detailed guidance for constructing references (Community
Requirements CR-5)
The RPC has been working on guidance for constructing references for
journals, online content, and documents produced by other standards
development organizations. We are reviewing this content now, and it
will be added to authors.ietf.org in February.
### Tooling (T)
#### xml2rfc and Self-hosted Fonts
Before IETF 125, 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 was
closed as wontfix](https://issues.chromium.org/issues/447361040)).
This project saw no changes since the last report.
#### 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
handling author affiliations, processing the publications of RFCs and
informing datatracker of published RFCs, managing subseries number
assignment, managing cluster members and displaying them graphically,
providing the ability to send mail to start final reviews and announce
publications, and tracking assignment blocks caused by stream holds,
author actions, and missing references.
#### 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.
This project saw no significant changes since the last report.
#### 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.
To provide more flexibility for users and to reduce future maintenance,
work on DraftForge has shifted from a standalone application to a Visual
Studio Code extension. All existing features have been ported over.
The Tools Team has created a Docker image that will serve as a
ready-to-use environment for the RPC staff. The image contains all
DraftForge dependencies and RPC editing scripts. The installation and
operation of the DraftForge plugin with dev containers is being tested
and documented.
## 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.
Alice
* In progress:
* RFC-EDITOR:
* draft-ietf-pce-pceps-tls13-04 (Cluster 496)
* draft-ietf-lsr-igp-flex-algo-reverse-affinity-12 (Cluster 496)
* draft-ietf-netconf-over-tls13-04 (Cluster 496)
* draft-ietf-lamps-rfc5019bis-12 (Cluster 496)
* Completed (since 16 Dec.)
* RFC-EDITOR:
* draft-ietf-netmod-rfc8407bis-28
* AUTH48:
* draft-ietf-regext-rdap-rir-search-19 (9910)
* Published 1 RFC
Lynne
* In progress:
* EDIT
* draft-ietf-cose-tsa-tst-header-parameter-08
* RFC-EDITOR
* draft-ietf-nmop-terminology-23
* AUTH48
* draft-ietf-manet-dlep-traffic-classification-17 (Cluster 541)
* draft-eastlake-fnv-35
* AUTH48-DONE
* draft-ietf-manet-dlep-credit-flow-control-19 (Cluster 541)
* draft-ietf-manet-dlep-da-credit-extension-21 (Cluster 541)
* draft-ietf-manet-dlep-ether-credit-extension-09 (Cluster 541)
Alanna
* In progress:
* EDIT
* draft-ietf-pce-sid-algo-29 (Cluster 496)
* AUTH48-DONE
* 9848 - draft-ietf-tls-svcb-ech-08 (Cluster 430) - waiting on 9849
* 9850 - draft-ietf-tls-keylogfile-05 (Cluster 430) - waiting
on 9849 and 9846
* Completed:
* EDIT → RFC-EDITOR
* draft-ietf-lamps-rfc5019bis-12 (Cluster 496)
* draft-ietf-pce-pceps-tls13-04 (Cluster 496)
* draft-ietf-lsr-igp-flex-algo-reverse-affinity-12 (Cluster 496)
Madison
* In progress:
* EDIT
* draft-ietf-lamps-kyber-certificates-11 (Cluster 551)
* draft-ietf-lamps-cms-kyber-13 (Cluster 551)
* AUTH48
* RFC 9880
* RFC 9849 (Cluster 430) - Markdown
* Errata
* Managing errata mail as needed.
* Completed:
* EDIT → RFC-EDITOR
* draft-ietf-emu-rfc7170bis-22 (Cluster 545)
* AUTH48 → PUB
* RFC 9908
* December Errata Stats
* Submitted: 28
* Editorial → Technical: 2
* Deleted as spam: 3
* Verified: 2
* Rejected: 0
* HFDU: 1
* Note: These numbers include EIDs marked as Rejected/Verified/HFDU
by both the RPC and ADs and only reflect errata reports that were
submitted after 12/1.
Sarah
* In progress:
* Documents on deck for formatting: 1
* Completed:
* Added to the queue: 10
* Sent intake forms: 12
* Received and/or got approval for new draft version: 8
* Formatted documents: 10
Rebecca
* In progress:
* RFC-EDITOR:
* draft-ietf-raw-architecture-30 - Cluster 538
* draft-ietf-raw-technologies-17 - Cluster 538
* AUTH48:
* draft-editorial-rswg-rfc9280-updates-04 (RFC-to-be 9920)
- GitHub/MD
* Completed:
* EDIT:
* draft-ietf-tls-dtls-rrc-20
* draft-ietf-uta-require-tls13-12 (RFC-to-be 9852)
* RFC-EDITOR:
* draft-editorial-rswg-rfc9280-updates-04 (RFC-to-be 9920)
* Completed AUTH48 and passed on for publication:
* draft-ietf-netmod-rfc6991-bis-18 (RFC 9911)
* draft-ietf-uta-require-tls13-12 (RFC-to-be 9852) - C430)
* Note: This document is part of Cluster 430; it normatively
references RFCs-to-be 9846 and 9851 and will be published at the same
time as those documents.
Megan
* In progress:
* EDIT
* draft-briscoe-docsis-q-protection-07 (C350)
* draft-ietf-tsvwg-nqb-33 (C350)
* AUTH
* 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)
* REF
* draft-ietf-i2nsf-applicability-18 (C405)
* AUTH48
* draft-ietf-stir-servprovider-oob-08 (RFC-to-be 9888)
* draft-ietf-dhc-rfc8415bis-12 (RFC-to-be 9915)
* draft-ietf-netmod-rfc8407bis-28 (RFC-to-be 9907)
Kaelin
* In progress:
* EDIT:
* draft-ietf-dhc-dhcpv4-over-dhcpv6-ra-06
* draft-fz-spring-srv6-alt-mark-17
* AUTH48:
* RFC 9896 (draft-editorial-rswg-svgsinrfcs-04)
* Completed:
* EDIT:
* draft-ietf-raw-architecture-30 (C538)
* draft-ietf-raw-technologies-17 (C538)
* draft-halen-fedae-03
Ted
* 15 reference reviews completed since last community update
* Reference reviews in progress:
* draft-ietf-core-href-30
* draft-ietf-rift-kv-tie-structure-and-processing-09
* draft-ietf-idr-link-bandwidth-24
* draft-ietf-mailmaint-messageflag-mailboxattribute-14
* draft-ietf-httpbis-rfc6265bis-22
* draft-ietf-oauth-browser-based-apps-26
* Other work:
* Refining draft of reference style guidance for authors.ietf.org
Sandy
* In progress
* EDIT:
* draft-ietf-6lo-prefix-registration-18 (Cluster 547)
* draft-ietf-6lo-updating-rfc-8928-05 (Cluster 547)
* RFC-EDITOR:
* draft-halen-fedae-03
* Completed (since 16 Dec.)
* EDIT:
* draft-ietf-tls-tls12-frozen
* RFC-EDITOR:
* draft-ietf-tls-tls12-frozen
* helped initiate AUTH48 using GitHub for
draft-editorial-rswg-rfc9280-updates-04 (9920)
* AUTH48:
* draft-ietf-tcpm-accurate-ecn (9768)
* draft-ietf-tls-rfc8446bis-14 (9846)
* Published 8 RFCs
Karen
* In progress:
* EDIT:
* draft-ietf-roll-dao-projection-40 (C538)
(large document with a lot of inconsistent terminology to sort
through)
* Completed:
* Completed AUTH48 and was published:
* draft-ietf-tsvwg-multipath-dccp-24 (RFC 9897)
## FYIs
Stats:
* Queue stats
(https://www.rfc-editor.org/rpc/wiki/doku.php?id=2026stats#january_2026)
as of January 2026
* Average processing times
(https://www.rfc-editor.org/rpc/wiki/lib/exe/fetch.php?media=wiki:20260113-summary-stats.png)
for EDIT through AUTH48: 13.4 weeks
* View updates as the year progresses at
https://www.rfc-editor.org/report-summary/
Writing Tip:
* If your document contains sourcecode, you can add an attribute
identifying the type of sourcecode in the RFCXML file. Although the
sourcecode type doesn't have to be provided while the document is an
Internet-Draft, the RPC will ask about the sourcecode type if it is
missing. For a list of sourcecode types, please see
https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types
----
## 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]
