The process for publishing an RFC begins when an Internet-Draft is approved by one of the publication streams:
Once a document is approved, it enters the publication queue and is managed by the RFC Production Center (RPC). From this point on, the RPC has change control of the document. This means that the RPC now manages the document in their own repository, and that all changes the authors wish to make must go through the RPC. Any non-technical changes, such as updating the contact information, will normally be accepted directly, but any technical updates will require stream approval.
Sometimes groups of documents are managed together as a cluster. This can be for two reasons:
Clusters can include both documents that are in the queue and those that are not yet in the queue (shown as Not received).
Clusters are assigned IDs and linked to each document in the cluster. The Clusters page shows the current clusters and the status of each document in the cluster.
A document waiting for a normative reference (or a stream-specified dependency) to enter the queue is shown as blocked and Reference Not Received. Specifically:
Reference Not Received has a reference to a document that is not received.Reference Not Received (2nd Generation) has a reference to a document that references a document that is not received.Reference Not Received (3rd Generation) has a reference to a document that references a document that references a document that is not received.Documents in a cluster can sometimes wait for a long time for the dependencies on the other documents to be resolved. Once the dependencies are resolved, the document is no longer blocked and is edited.
Once a document is approved and submitted for publication, control is handed over to the professional editors of the RFC Publication Center (RPC). They start by sending the authors an intake form to gather information significant to the editing process. Then they put the document through an extensive editing process with multiple stages.
If the document is not already in RFCXML, it is converted into RFCXML. The RFCXML is examined and may be restructured to ensure consistency and readability. The editors perform the following updates:
<!ENTITY nbsp " ">
<!ENTITY zwsp "​">
<!ENTITY nbhy "‑">
<!ENTITY wj "⁠">
]>
<reference anchor="URI" target="https://www.rfc-editor.org/info/rfc3986">
...
</reference>
is changed to the following:
<displayreference target="RFC3986" to="URI"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/>
During First Edit, the document is copy edited to find and correct errors and to ensure that the document conforms to the style guide. See Language and Style for details.
The references in the document are checked for accuracy and stability and, where needed, edited for correctness. See reference style guidance for details.
If the document contains IANA actions, such as creating or updating an IANA registry, then IANA will start their processing when the document is approved for publication. IANA processing usually takes place in parallel with editing.
Occasionally IANA processing can take longer than editing, for example, if IANA is waiting for a designated expert to respond. In which case, the document will be shown as blocked and IANA Hold, until the IANA processing is complete. Once IANA has completed their actions, the document will move forward to Second Edit.
During Second Edit, a senior editor reviews the formatting, copy edits, and the team's proposed questions to authors.
If there is an IANA Considerations section, the senior editor reviews the messages regarding IANA actions, compares the information within the document to the information within the registry, and updates the section. If there are any issues with the IANA registry itself, these are noted for discussion with IANA during Final Review.
If there are code components such as YANG modules, XML, or ABNF, the senior editor validates them with automated tools and notes any issues to discuss with authors during final approval.
Once Second Edit is complete, the senior editor launches Final Review (formerly known as AUTH48).
After editing, the document then enters Final Review, when the changes made by the RPC are shared with the authors for their approval.
Final Review begins with an email sent to the authors asking them to complete the following actions:
Instructions are provided on how an author can submit changes and how to give final approval for the document to be published. Sometimes this process involves multiple discussions about the edits, alternative edits proposed by the authors, and negotiation.
If the authors make any changes that seem beyond editorial in nature, e.g., addition of new text, deletion of text, and technical changes, then the RPC will seek approval for those changes from the originating stream.
Final Review finishes when all authors of the document give their final approval.
If it was determined that an IANA registry needed updates, the RPC editor will request that IANA make those updates.
There may be an occasion when one of the authors is no longer available, in which case the remaining authors can opt for one of the following paths:
Final Review) in place of the unavailable author. (See the IESG Statement on Final Review State.)Option 3 is typically used in instances where the unavailable author made significant contributions to the document, so the other authors are not comfortable removing the individual from the author list.
There are a number of reaons that a document can be blocked from further processing.
Sometimes the editors have questions for the authors that need to be resolved before they can move forward with copy editing the document. When this is the case, the document is shown as Author Input Required until the answers are received.
Occasionally, at the end of Final Review publication of the document is on hold pending the resolution of an issue with the software tools used to create the pubished versions. For example, if there is an error in the PDF generation. In these circumstances, the document is labeled as Tools Issue until the issue is resolved.
Sometimes a stream asks for a document to be held or the editing process raises issues that lead to technical discussions (e.g., involving the working group and an Area Director). In this case, the document is labeled as Stream Hold until the issue is resolved.
A document may occasionally be withdrawn from the queue, e.g., because a stream requests that it be withdrawn.
When an RFC is published, an announcement is sent to the ietf-announce and rfc-dist mailing lists. The URL for the info page of an RFC is of the form: https://www.rfc-editor.org/info/rfcXXXX. The RFC Editor maintains a list of the most recently published RFCs (RSS Feed).