Hi all,
Please find below the RPC report for July. This report is also available
at https://notes.ietf.org/rpc-report-202607?view
Best regards,
Jean
# RFC Production Center Report - July 2026
Previous notes: https://notes.ietf.org/rpc-report-202606#)
RPC project roadmap: https://github.com/orgs/rfc-editor/projects/2
## Big Picture
It has been six weeks since the deployment of the queue management
system and the new websites www.rfc-editor.org, queue.rfc-editor.org,
errata.rfc-editor.org, and history.rfc-editor.org. The RPC team is
adjusting to the new queue management system, which has been working
well, but has required some of the team's time to become proficient
working with the new system and to refine and document new procedures.
Upcoming features will include queue statistics that will be published
to queue.rfc-editor.org, better integration between the RFC Editor queue
and the datatracker regarding the status of documents in the queue, and
new, professionally designed features for www.rfc-editor.org.
## Project Updates
A full list of the RPC's strategic transformations
(https://notes.ietf.org/rpc-report-202607?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).
### RPC Retreat
At the retreat in April, the team discussed how the intake forms were
going. Intake forms contain questions that the RPC sends to authors when
their documents enter the queue and are part of the strategic
transformation on process efficiency (PE-2). We have found that author
responses to the forms have aided our reference checking, and we have
also found them helpful for editing document clusters by providing
guidance on terminology and the ordering of documents within a cluster.
We noted that our questions about sourcecode
(https://rpc-wiki.rfc-editor.org/doku.php?id=sourcecode-types) sometimes
cause confusion, so we have clarified those questions and have provided
pointers to more information.
### GitHub Roadmap (Reflecting Changing Author Processes AP-2, AP-3)
The RPC is offering an optional Final Review 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 31 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 process some more.
We can accept 5 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 Final Review. 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 27 kramdown-rfc documents in the queue. We can accept 5
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
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.
The RPC is researching open-source tools that can create accessible SVG
easily so we can provide recommendations to the community.
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)
The next steps for improving queue information is to have datatracker
display more of the information so the user does not need to visit
queue.rfc-editor.org to understand a document's queue status and to have
queue.rfc-editor.org provide general queue statistics.
For more details about the labels used at queue.rfc-editor.org, please
see https://queue.rfc-editor.org/about/
### Tooling (T)
#### New Queue Management System: Purple (Process Efficiency PE-3,
Tooling T-2, T-3)
Latest updates to Purple (https://github.com/ietf-tools/purple) include
the ability to withdraw a document from the queue and the refinement of
rules for indicating when a document is blocked.
The next set of features for Purple will include the creation of queue
statistics reports for queue.rfc-editor.org, improved data queries, and
better visibility into assignment history for individual editors.
#### New rfc-editor.org Website: Red (T-2)
The new www.rfc-editor.org website, known as Red
(https://github.com/ietf-tools/red), will continue to see improvements
and new features this year. A recently added feature is the ability to
copy sourcecode while "unfolding" it per rules specified in RFC 8792
(https://www.rfc-editor.org/info/rfc8792/). To exercise this feature,
try the examples found in
https://www.rfc-editor.org/info/rfc8792/#name-examples.
#### New Editing Software: DraftForge (T-1)
DraftForge (https://draftforge.ietf.org/) is an editing platform that
provides RFCXML validation, output file creation for both RFCXML and
kramdown-rfc source files, GitHub integration, datatracker submission
for I-D authors, and replaces the 20+ checker scripts the RPC used to
run at the command line.
DraftForge can now export RFCXML, HTML, PDF, and text files from
kramdown-rfc markdown files and has improved handling of bcp14 tags in
RFCXML.
#### xml2rfc and Self-hosted Fonts
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)).
The target date for project completion is TBD.
## Document Work Updates and Hot Topics
**Note:** As docs move through the queue, they go through the following
states: intake form processing where author input is required ->
formatting -> reference checking -> first edit, which focuses on content
editing -> second edit, which focuses on open questions from the first
editing pass, IANA Considerations updates, and source code validation ->
Final Review, where authors review the edits and provide their approvals
-> Final Review Done, where documents may wait for their companion
documents to complete their final reviews and where editors run final
checks -> publication on the www.rfc-editor.org website and
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 5 June RPC report
(https://notes.ietf.org/rpc-report-202606?view).
Alice
* In progress
* First Edit
* draft-ietf-pim-zeroconf-mcast-addr-alloc-ps
* Completed
* First and Second Edit
* draft-ietf-opsawg-oam-characterization
* Second Edit
* 10007 (draft-ietf-lamps-keyusage-crl-validation) - Markdown,
Final Review in GitHub.
* Final Review
* 10005 (draft-ietf-idr-link-bandwidth)
* 10014 (draft-ietf-opsawg-oam-characterization)
* Published 3 RFCs
Alanna
* In progress
* Second Edit:
* draft-ietf-httpbis-rfc6265bis (C548, Markdown, Final Review
in GitHub, 62 pgs)
* Final Review:
* 9955 - draft-ietf-pquip-hybrid-signature-spectrums-07 (C553)
* 9971 - draft-ietf-bmwg-mlrsearch-15 (Markdown, Final Review
in GitHub)
* Completed
* First Edit:
* draft-ietf-netmod-system-config-20
* draft-ietf-core-groupcomm-bis (C564, Markdown, Final Review
in GitHub)
* draft-ietf-dnsop-ds-automation (expedited doc)
* draft-ietf-mailmaint-imap-uidbatches
Madison
* In progress
* Final Review:
* RFC-to-be 9988 - draft-ietf-core-href (Markdown/GitHub)
* Completed
* First Edit
* draft-ietf-pquip-hbs-state (Markdown/GitHub)
* draft-ietf-core-oscore-groupcomm-28 (Markdown/GitHub)
* draft-ietf-tls-ecdhe-mlkem-05
* draft-ietf-lamps-keyusage-crl-validation-04
* Final Review:
* RFC-to-be 9985 - draft-ietf-bfd-optimizing-authentication
* RFC-to-be 9986 - draft-ietf-bfd-secure-sequence-numbers
* RFC-to-be 10007 - draft-ietf-lamps-keyusage-crl-validation-04
Sarah
* In progress
* Intake Forms Pending:
* draft-ietf-oauth-identity-chaining
* draft-ietf-httpapi-digest-fields-problem-types
* draft-ietf-scitt-scrapi
* Format:
* draft-ietf-6man-rfc6724-update
* draft-ietf-ccamp-optical-impairment-topology-yang
* draft-ietf-idr-flowspec-redirect-ip
* draft-ietf-rtgwg-vrrp-rfc8347bis
* draft-ietf-sidrops-rpki-ta-tiebreaker
* draft-ietf-sidrops-avoid-rpki-state-in-bgp
* draft-ietf-ccamp-rfc9093-bis
* draft-dekater-scion-controlplane
* draft-dekater-scion-pki
* draft-dekater-scion-dataplane
* Final Review
* RFC-to-be 9996 - draft-ietf-dispatch-mime-protobuf
* Completed
* Format: 15
* Sent Intake Forms: 17
Rebecca (out of office this week)
Megan
* In progress
* AUTH/REF aka Blocked - Author Input Required
* C405 (since Sept 2025)
* draft-ietf-i2nsf-nsf-facing-interface-dm
* draft-ietf-i2nsf-capability-data-model
* draft-ietf-i2nsf-nsf-monitoring-data-model
* draft-ietf-i2nsf-registration-interface-dm
* draft-ietf-i2nsf-consumer-facing-interface-dm
* draft-ietf-i2nsf-applicability
* Final Review
* draft-ietf-alto-oam-yang / RFC-to-be 10012 (C463)
* draft-ietf-rats-eat-measured-component / RFC-to-be 10013
*Final Review - DONE
* Cluster 565
* draft-ietf-lamps-rfc5272bis / RFC-to-be 10002
* draft-ietf-lamps-rfc5273bis / RFC-to-be 10003 (awaiting
RFC-to-be 9846)
* draft-ietf-lamps-rfc5274bis / RFC-to-be 10004
* Completed
* First Editor
* draft-ietf-alto-oam-yang-18 (C463)
* Final Review
* draft-ietf-stir-servprovider-oob-08 Pub’d as RFC 9888
* C557
* draft-ietf-cose-merkel-tree-proofs-18 Pub’d as RFC 9942
* draft-ietf-scitt-architecture-22 Pub’d as RFC 9943
* draft-ietf-openpgp-pqc-17 Pub’d as RFC 9980
* draft-ietf-mpls-mna-hdr-21 Pub’d as RFC 9994
* draft-ietf-cose-hash-envelope-10 Pub’d as RFC 9995
Kaelin
* In progress
* First edit:
* draft-ietf-oauth-cross-device-security
* Final review:
* RFC-to-be 10015 (draft-ietf-tls-deprecate-obsolete-kex-08) (C430)
* Completed
* First edit:
* draft-ietf-httpbis-rfc6265bis
* draft-davids-forsalereg
* draft-ietf-sshm-mlkem-hybrid-kex
Ted
* 18 in progress
* draft-ietf-ccamp-layer1-types
* draft-ietf-ccamp-l1csm-yang
* draft-ietf-ccamp-otn-topo-yang
* draft-ietf-opsawg-pcaplinktype
* draft-ietf-netconf-adaptive-subscription
* draft-ietf-lamps-pq-composite-sigs
* draft-ietf-oauth-rfc7523bis
* draft-ietf-cellar-tags
* draft-pantos-hls-rfc8216bis
* draft-ietf-ippm-qoo
* draft-ietf-teas-rfc8776-update
* draft-ietf-bess-bgp-sdwan-usage
* draft-ietf-oauth-status-list
* draft-ietf-6man-snac-router-ra-flag
* draft-ietf-httpapi-privacy
* draft-ietf-idr-nhc
* draft-rswg-rfc7997bis
* draft-ietf-httpbis-unencoded-digest
* 19 reference checks completed since last community update.
Sandy
* In progress
* Second Edit
* draft-ietf-ntp-over-ptp (GH)
* Final Review
* RFC-to-be 9851 - draft-ietf-tls-tls12-frozen
* RFC-to-be 9846 - draft-ietf-tls-rfc8446bis (MD)
* RFC-to-be 9997 - draft-ietf-core-yang-sid-pen (MD)
* Completed
* First Edit
* draft-ietf-core-yang-sid-pen
* Second Edit
* draft-ietf-httpbis-safe-method-w-body (GH)
* Initiated Final Review in GH
* RFC-to-be 10009 - draft-ietf-netconf-netconf-client-server
* RFC-to-be 10010 - draft-ietf-netconf-restconf-client-server
* Final Review
* RFC 10008 - draft-ietf-httpbis-safe-method-w-body (GH)
* RFC 9974 - draft-ietf-bier-oam-requirements
* Published
* 15 RFCs
Karen
* In progress
* Second Edit:
* draft-ietf-netmod-system-config
* draft-ietf-core-oscore-groupcomm (C564) (MD/GH)
* draft-ietf-core-groupcomm-bis (C564) (MD/GH)
* Completed
* First Edit:
* * draft-ietf-oauth-browser-based-apps (MD)
* Second Edit:
* draft-ietf-netconf-netconf-client-server (C463) (RFC-to-be
10009) (GH)
* draft-ietf-netconf-restconf-client-server (C463) (RFC-to-be
10010) (GH)
* draft-ietf-alto-oam-yang (C463) (RFC-to-be 10012)
* Final Review (passed along for publication):
* RFC-to-be 9999 (draft-ietf-rats-msg-wrap)
## FYIs
### Stats
There are currently 148 documents in the queue.
In May, 15 documents entered the queue, and 23 RFCs were published.
## 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]
