Report from RPC Retreat 2025

The first major theme for this retreat was the productivity of the document editing and publication process, examining how these have changed over the last 10-15 years and applying significant focus on what needs to change in order for the process to speed up significantly. Several key influences on productivity were identified and ways forward identified to address them: the requirements, efficiency of the process, and tooling.

The influence of the community requirements on productivity has multiple components to it:

1. The introduction of RFCXML as the archiving format has significantly increased the workload of the RPC.  This is partly due to the increased complexity of RFCXML compared to the previous nroff format, but more so perhaps due to the switch to semantic markup with many new markup tags and features, and the explosion in their use. For example, RFCXML introduces the <tt> tag that is sometimes extensively used by authors for marking technical terms used in a document, meaning that the RPC now checks if this markup is used correctly and consistently throughout a document. Another example is the introduction of Right-To-Left text, which, while rarely used, adds considerable time to the editing process when it is. The introduction of RFCXML also means the editors are routinely reviewing the output of three formats (rather than just the text).  The editors manually check for display issues that are known to be problematic across the outputs (e.g., nested lists, complex tables, non-ASCII characters).  
   
   While not for the RPC to decide, it may be that a review of the cost/benefit of the expanded feature set of RFCXML leads to some features being dropped or their usage more strictly controlled. 
   
   
2. The individual tasks assigned to the RPC have also grown considerably. These include the more recent request to check all documents for imprecise or out-of-date terminology and the more established detailed checking of YANG modules. This is likely to increase as work goes through the RSWG to change the allowable SVG and potentially introduce higher accessibility standards.
   
   The time has come to review the full range of tasks expected of the RPC and determine if the cost of implementation, in terms of impact on document processing times, is worth it or not and if some should be dropped and the responsibility for quality left exclusively with authors.
   
   
3. Linked to the above components, is the issue of just how much formatting control authors should have. Almost all long running issues are related to format and it is very rare to have a content discussion with authors that takes a long time to resolve. A good example here is formatting of lists, where there is now a large number of choices regarding bullets, indents, spacing, hanging lines, etc. to accommodate personal author preference. The RFC Style Guide has been through a number of iterations, and both it and the technology that supports it have expanded to allow more and more individual preferences for text formatting.
   
   Again, it is time to reconsider if it should continue to be the policy that almost all individual preferences are supported, given the cost and complexity of doing so.

It is worth noting that the document/page count of documents submitted for publication has not changed much for some years.

The influence of the efficiency of process on productivity also has multiple components to it:

1. There are many choices that authors can make in the way a document is written and this in turn affects how the document is edited. Currently, the process of determining if the authors have made consistent terminology and formatting choices. For some documents, this is time-consuming and sub-optimal.  Asking a set of questions up front will reduce this workload considerably. For example, it is common for an author to write a document to match the style of a previous RFC, but this is something that the editors ‘discover’ during the editing process as it is not proactively communicated by the authors.
   
   The solution identified at the retreat is for the authors to be asked to fill out a document intake form with the key information needed to speed up processing. This form is also likely to ask the submitter to affirm that at least one author has read the approved version of the document all the way through. A draft of this form will go to the stream managers in due course for their feedback.
   
   
2. Very occasionally, a document submitted to the RPC is of such poor quality that the work to edit it is excessively disproportionate compared to an average document. While the RPC is empowered to return such a document (RFC 7322, Appendix A.2), there is currently no clear, documented process for doing that and instead the RPC adjusts resources to cope with the extra workload. 
   
   The RPC will be developing an internal process to ensure that documents that do not meet the quality threshold for editing are rejected at an early stage, following clear guidance and rules.
   
   
3. Last year the RPC recruited a citation specialist and now all reference checking and correcting is carried out by this role.  More recently, all documents go to a single editor for initial XML format checking and reformatting (e.g., converting tables in <artwork> to use <table> tags). This move towards editor specialism is likely to continue, with consideration being given to an editor specialising in checking and formatting code modules and another specialising in accessibility and diagrams.
   
   The RPC identified multiple smaller efficiency improvements, such as condensing their internal notes into a single place for ease of access and having all staff trained on relevant components of the new one-day training course produced for the New Participant Program.

The influence of tooling on productivity also has multiple components, though remediation of the issues by the IETF Tools Team is more advanced:

1. There are multiple areas of time-consuming manual editing work that would benefit from automation, with a potentially significant improvement in editing times. For example, checking for consistent use of a particular term or making metadata updates during the final publication step could be more quickly handled by automated means.
   
   Work is well underway on a new editing tool (DraftForge) for the RPC that replaces the current setup of Emacs and multiple single-task command line scripts, and automates many of the current manual tasks.  Over time this will grow increasingly sophisticated as new automations are added.
   
   
2. Many of the current tools are very old and maintaining them is time-consuming with a lot of manual processing. One part of this is the RPC database, where for example adding the new Editorial Stream and adjusting the Areas following the Internet Engineering Steering Group (IESG) reorganisation was a lengthy process of manual testing and manual database edits.  The other part is the RFC Editor website, which is only very old technology and has reached end of life.
   
   The RPC database is being rewritten as a Datatracker module (Purple) and the RFC Editor website is being rewritten (Red) using a complete redesign produced by a professional UX company.
   
   
3. There are a few points in the editing process where Area Director (AD) approval is required, such as during AUTH48, or earlier in the process when authors submit a new version of the document from that submitted for publication. Currently the process relies on the AD checking their email for these approval requests, which can be sub-optimal as ADs receive a huge volume of email.
   
   The IESG is already pushing for all decision points to be automated and shown to ADs on their dashboards, and so it is likely that a future enhancement of these dashboards will be to include actions generated during the editing process.

The second major theme for this retreat was transparency. The RPC had already made some improvement here with the creation of the auth48archive list but now with the RPC under direct IETF Administration LLC management, there is the expectation that it adopts the same high level of transparency as the IETF LLC is required to in BCP 101.  Consequently the following transparency initiatives were discussed at this retreat:

1. The RPC plans to have an open monthly call, similar in nature to the monthly Tools Team call. The RPC will publish a detailed agenda and set of notes for this call and then one of the Directors will talk through it and answer any questions from the community. This will get into the details of individual documents in the publication queue and the details of change projects underway. It is expected that most of the RPC team will be able to join most of these calls, providing a human face to this otherwise remote service. 
   
   As part of supporting visibility into change projects, the RPC will develop a high-level roadmap, similar to that maintained by the Tools Team.
   
   
2. After a document enters the editing process, but before it reaches AUTH48, discussions with authors take place using the rfc-editor@rfc-editor.org list.  The RPC will aim to either open this list up (that presents some challenges) or move these discussions to a new, open list, mirroring the openness of auth48archive.
   
   
3. The move to a new database provides an opportunity for much more automated transparency into the editing process. While still only at the discussion stage, consideration is being given to how the community can view and track the progress of a document through the stages and see any holdups and what is causing them (such as missing references).

The third major theme for this retreat was how to change RPC processes to reflect the changing processes of authors, which in particular means using Markdown and GitHub.

1. Markdown is now used for over half of new I-Ds and is growing in popularity as an authoring format. The RPC have looked at Markdown and are enthusiastic about it for the same reasons as authors: In comparison to RFCXML it’s much easier to read and write, Markdown does not require special tools, and the current implementations have a simpler set of features.
   
   The RPC is experimenting with support for editing documents in the most popular Markdown variant, kramdown-rfc, and so far these experiments have gone well.  However, for this to become a permanent feature, there needs to be  a stable and fully featured Markdown syntax, fully supported in the tools maintained by the Tools Team, and preferably officially supported for I-D submission. The Tools Team have some ideas on how to address this and will be initiating a community discussion about it, in due course.
   
   
2. The RPC have spent considerable time looking at how they might implement GitHub, both for their own processes and cooperatively with authors who use it for their documents.  Support of GitHub would have to be in addition to the current email-based process as multiple authors and ADs have indicated a preference to continue with this.  This means that implementing GitHub support for authors would be a time cost in training staff and maintaining two editing processes.
   
   For their own processes, the RPC plans to switch from their long-standing practice of keeping working copies of files on a shared filesystem and manual version control, to authoritative repositories on GitHub accessed directly by their new editing tool. This is expected to be easier for editors to learn, faster to work with, and will maintain a good level of GitHub skill.
   
   Working cooperatively with authors who use GitHub is a more complex proposition and is still being looked at. A stumbling block is the regularly requested feature for the editors to send PRs, labelled as format edits or content edits or by severity or with some other label.  Unfortunately this just does not fit with the way that editors work, which is to identify and correct issues as they are found during a review pass, whether those issues are formatting or content, or low severity or high severity.  Switching to a process with multiple edit passes, or where every edit leads to an individually labelled commit, would drastically increase the editing time and the IETF LLC has made it clear that this would not be acceptable. The RPC plans to put out a proposal for community discussion at IETF 123 Madrid on how it might support authors who work in GitHub.

This was a very successful retreat to mark the start of the next phase of evolution for the RPC.  To feed your input into this change, please consider joining the new monthly open RPC calls, which will be announced on the rfc-interest mailing list.