RFC 4714

RFC 4714: Requirements for IETF Technical Publication Service 💖

Okay bestie, here's the vibe check on this one. It's an Informational doc from the Network Working Group, written by A. Mankin and S. Hayes (both from Ericsson) in October 2006. It's a requirements doc, so it doesn't set any standard, and the title block doesn't list anything it obsoletes or updates. 🦋

Status of This Memo ✨

This memo gives information to the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. 🌸

Copyright Notice 🎀

Copyright (C) The Internet Society (2006). 💜

Abstract 🧚

The IETF's whole thing is discussing, developing, and disseminating technical specifications so the Internet keeps running. Technical publication is how all that output reaches the wider community, so understanding the requirements on that publication process is a big deal. 👑

Table of Contents 📚

1. Introduction ....................................................2
2. Scope ...........................................................3
   2.1. Stages in the Technical Specification Publication
        Lifetime ...................................................4
3. Technical Publication Tasks and Requirements ....................5
   3.1. Pre-approval Review or Editing .............................6
   3.2. Preliminary Specification Availability .....................6
   3.3. Post-approval Editorial Cleanup (Non-author Editing) .......7
   3.4. Validation of References ...................................9
   3.5. Validation of Formal Languages .............................9
   3.6. Insertion of Parameter Values .............................10
   3.7. Post-approval, Pre-publication Technical Corrections ......10
   3.8. Allocation of Permanent Stable Identifiers ................11
   3.9. Document Format Conversions ...............................12
   3.10. Language Translation .....................................12
   3.11. Publication Status Tracking ..............................12
   3.12. Expedited Handling .......................................13
   3.13. Exception Handling .......................................14
   3.14. Notification of Publication ..............................14
   3.15. Post-publication Corrections (errata) ....................15
   3.16. Indexing: Maintenance of the Catalog .....................15
   3.17. Access to Published Documents ............................16
   3.18. Maintenance of a Vocabulary Document .....................17
   3.19. Providing Publication Statistics and Status Reports ......17
   3.20. Process and Document Evolution ...........................18
   3.21. Tutorial and Help Services ...............................18
   3.22. Liaison and Communication Support ........................19
4. Technical Publisher Performance Goals ..........................20
   4.1. Publication Timeframes ....................................20
   4.2. Publication Throughput ....................................21
5. IETF Implications of Technical Publication Requirements ........21
6. IANA Considerations ............................................22
7. Security Considerations ........................................22
8. Acknowledgements ...............................................23
9. Informative References .........................................23

---

1. Introduction 🌷

okay so the IETF's whole job is discussing, developing, and disseminating technical specs to keep the Internet running, and the published specs are a huge part of that output. 🫶 The IETF technical publisher handles the final steps in making those specs, and this doc lays out what that publisher is responsible for and how it works with the IETF to get everything published. 💅

Quick note: the phrase "technical specification" is used on purpose here, to mean the IETF's technical output. This doc is not getting into the whole debate about whether that output is expressed as RFCs or something else, what "is" an RFC, how to classify them, and so on. Those topics are out of scope, so no drama there. 🙈

The goal is to pin down the IETF's consensus on what it needs from its technical publication service, and it's expected to be used when writing future contracts. This doc is not judging how well the current technical publisher (the RFC Editor) meets those needs. 🍓

2. Scope 🦋

This doc is all about requirements for the IETF's technical publication process. Requirements on a technical publisher can be described two ways: the tasks the publisher is responsible for, and the performance targets it should meet. These functions are sometimes called editorial management [RFC2850]. 💜

This doc focuses on documents published through the IETF's technical standards process. The requirements are written in generic terms, though, so other publication streams can use them too, wherever they show up. 🌈

The list of potential publication tasks came from looking at what the RFC Editor does today, plus what technical publishers do at other standards organizations, including 3GPP, ATIS, ETSI, IEEE, and ITU. ⭐

This doc is mainly about process: how the IETF technical publisher serves the IETF. There are related non-technical issues about document content that this doc doesn't cover, including:

• Policies governing the acceptable input and output document formats (including figures, etc.)
• Policies governing the acceptable character sets (internationalization)
• Policies governing the layout and style of published documents
• Policies governing the contents of non-technical sections (acknowledgement sections, reference classifications, etc.)

Those policies still matter for making sure the final published document really is an IETF product. They'll probably keep evolving through the ongoing IETF dialog. The IETF technical publisher should be part of those policy discussions and be ready to implement and facilitate policy changes once IETF consensus lands on them. That requirement lives under process and document evolution. ✨

2.1. Stages in the Technical Specification Publication Lifetime 🎀

Figure 1 is a handy overview of where technical publication sits in the life of a document in the IETF standards process. 🗺️ It shows a Working Group (WG) document going through reviews, including Working Group Last Call (WGLC), Area Director (AD) review, IETF Last Call (IETF LC), IANA review, and IESG review. The document shepherd (labelled "Shepherd" in the diagram) is someone the IESG assigns to walk a document through the reviews and the publication process. They're often not an AD. The lifetime looks very similar for AD-sponsored IETF documents, like ones that update IETF protocols that no longer have a working group, or documents on interdisciplinary topics. 💖

              Actors      Formal       Actors            Actors
                          Reviews

           |  Author,   | WGLC      | IESG,      |    |  IANA,
           |  Editor,   | AD        | Shepherd,  |  A |  Tech
           |  IETF Sec- | IETF LC   | Editor,    |  P |  Publisher,
           |  retariat  | IANA      | WG,        |  P |  input from
           |            | IESG      | AD         |  R |  authors, et al.
           |            |           |            |  O |
   Actions |  Creation, |           | Resolution |  V |  Non-author
           |  Editing,  |           | of all     |  A |  editing,
           |  Draft Pub,|           | reviews    |  L |  other
           |  Tracking  |           |            |    |  publication

           |---------------| |---------------------| |----------------|

                In WG               Out of WG          Post-approval

               Figure 1: Stages of a Working Group Document

Heads up: sometimes one submission is actually made up of several source documents, like supporting files and code. 📁

Under the IETF standards process stream, post-approval processing starts when the IESG gives technical approval. 👑

3. Technical Publication Tasks and Requirements 💅

Standards development organizations all include technical publication in their process. The line between what the technical committees do and what the technical publisher does, though, is different from one org to the next. 🌸

Here's the list of potential tasks for a technical publisher. It was built after looking at the technical publication policies of the IETF and other standards development organizations. 🧚

1. Pre-approval review or editing
2. Preliminary specification availability
3. Post-approval editorial cleanup (non-author editing)
4. Validation of references
5. Validation of formal languages
6. Insertion of parameter values
7. Post-approval, pre-publication technical corrections
8. Allocation of permanent stable identifiers
9. Document format conversions
10. Language translation
11. Publication status tracking
12. Expedited handling
13. Exception handling
14. Notification of publication
15. Post-publication corrections (errata)
16. Indexing: maintenance of the catalog
17. Access to published documents
18. Maintenance of a vocabulary document
19. Providing publication statistics and status reports
20. Process and document evolution
21. Tutorial and help services
22. Liaison and communication support

For each of these tasks, the doc looks at how relevant it is to the IETF and how it works within IETF processes. From there, it derives requirements for the IETF technical publisher. 🔥

3.1. Pre-approval Review or Editing 🌈

Task Description: This is a review or editing service that improves document quality before a document is approved. The review would normally cover things like grammar, spelling, formatting, adherence to pre-approval boilerplate, document structure, and so on. ✍️

Discussion: Pre-approval review isn't part of the current IETF standards process, but the idea was explored in the early copyediting experiment. Early feedback from that experiment has been promising, though whether early editing is effective is still being evaluated. 🧐

Derived Requirements:

Req-PREEDIT-1: The IETF technical publisher should be capable of performing an editorial review of documents early enough to allow changes to be reviewed within the technical review process, should the IETF choose to implement pre-approval editing. For the IETF standards process stream, this review should be performed before WG Last Call and provide feedback to the authors to improve the quality of the documents. For the IETF standards process stream, the publisher should not perform a technical review of the document. 💖

3.2. Preliminary Specification Availability ✨

Task Description: Okay so some standards orgs want their publisher to put out a preliminary version of a doc (with proper caveats!) so the industry can see the info as early as possible 🌸. This doc is provided "as is" after the approval. And it gets withdrawn once the final doc is published 🫶.

Discussion: This is not required 💅. A final approved version is available as an internet draft. If publication can take more than 6 months, it may be necessary to request that the draft version remains available 🕰️.

Derived Requirements: none 🦋

---

3.3. Post-approval Editorial Cleanup (Non-author Editing) 💅

Task Description: Most technical publishers do an editorial review to make sure published docs are high quality ✨. This usually covers stuff like grammar, spelling, readability, formatting, adherence to boilerplate, document structure, etc. Since any proposed changes happen after approval, a review and signoff mechanism should usually be set up so everyone knows the required changes are truly editorial 🔍. These changes happen outside the normal approval process, so it is desirable that they're minimized. Most standards orgs target "light" editing because messing with agreed-on text is dangerous 😬.

Discussion: Within the IETF, the RFC Editor does post-approval cleanup review and editing. The ambition level for cleanup can vary from:

• corrections to errors only,
• light rewriting,
• significant editing of documents with less skillful WG editors, and minimal editing when the WG editors were skilled, to
• rewriting of all documents to the dictates of a style manual.

At times in the past year, stylistic editing has resulted in a substantial number of changes in many documents. These changes must then be vetted by all the authors, followed by subsequent rounds of author acceptance and re-vetting. This can add up to a substantial delay in the publication process, which must be weighed against the incremental gain in communication improvement accomplished by the cleanup.

Changes to improve readability (or possibly even grammar) can end up inadvertently affecting consensus wording or technical meaning. Note that pre-approval editing to some extent avoids this problem 🙈.

In specific instances, it may be necessary to require that text be published "verbatim" even if doing so introduces what is perceived as poor readability or stylistic inconsistency. Examples of this include:

• "Boilerplate" agreed on in an IETF working group to apply to all instances of derivative works (e.g., IANA registration documents and Management Information Bases (MIBs)).
• Text referring to other organizations' work that has been carefully phrased and arranged with representatives of that other organization to deal with some politically sensitive issue.

If pre-approval editing or review is done, it may be possible to reduce or even eliminate entirely the post-approval editing task in some cases. Pre-approval editing may be more efficient since a separate change control process is not required 🧚.

Derived Requirements:

• Req-POSTEDIT-1 - The IETF technical publisher should review the document for grammar, spelling, formatting, alignment with boilerplate, document structure, etc. The review should strive to maintain consistency in appearance with previously published documents. In the IETF standards process stream, the publisher should not perform a technical review of the document.
• Req-POSTEDIT-2 - All changes made to post-approval documents should be tracked and the changes must be signed off on by the appropriate technical representatives. For the IETF standards process stream, this includes the authors, the document shepherd (if there is one), and the Area Director. The Area Director is the authority for approval of all changes.
• Req-POSTEDIT-3 - The IETF technical publisher should exercise restraint in making stylistic changes that introduce a substantial review load but only provide an incremental increase in the clarity of the specification. Specific guidelines on the types of changes allowed may be further specified, but ultimately restraint in editing must be imposed by the IETF technical publisher. Changes for stylistic consistency should be done only when there are major problems with the quality of the document.
• Req-POSTEDIT-4 - The IETF technical publisher should exercise restraint in making changes to improve readability that may change technical and consensus wording. Specific guidelines on the types of changes allowed may be further specified, but ultimately restraint in editing must be imposed by the IETF technical publisher.
• Req-POSTEDIT-5 - In specific instances, where some or all of document text is the result of a careful negotiation of contributions (within or between working groups, reviewers, etc.), the technical publisher may be required to publish that text verbatim. In the IETF standards process, verbatim publication may be requested by the IESG. It is the expectation of the IETF community that this will not be done often 🌈.

---

3.4. Validation of References 🔗

Task Description: Most standards orgs require that normative references be publicly available. Some technical publishers verify the validity and availability of references (including referenced clauses and figures). Although some editorial cleanup of references may be obvious, the issue becomes way more serious when reference links are broken, are not publicly available, or refer to obsoleted documents 💀. Such faults may be viewed as a post-approval fault found in the document. Most publishers have the ability to put a document on hold awaiting the publication of a reference expected to be available soon.

Discussion: The RFC Editor may put a document on hold while waiting for the availability of other IETF documents. Incorrect references are handled like any other fault detected in the editorial review.

Derived Requirements:

• Req-REFVAL-1 - The IETF technical publisher should ensure that all references within specifications are currently available and are expected to remain available.
• Req-REFVAL-2 - The IETF technical publisher should delay publication until all required (normative) references are ready for publication.

---

3.5. Validation of Formal Languages 🧪

Task Description: If the specification contains a formal language section (such as a MIB), the technical publisher may be required to validate this using a tool.

Discussion: The RFC Editor syntactically validates sections of a document containing MIBs, Augmented Backus Naur Form (ABNF), eXtensible Markup Language (XML), Abstract Syntax Notation One (ASN.1), and possibly other formal languages. Very precise, very necessary 🤓.

Derived Requirements:

• Req-FORMALVAL-1 - The IETF technical publisher should validate the syntax of sections of documents containing formal languages. In particular, ASN.1, ABNF, and XML should be verified using appropriate tools.

---

3.6. Insertion of Parameter Values 🎀

Task Description: The technical publisher is expected to work with IANA (or possibly other organizations maintaining registries) to populate assigned protocol parameter values when required, prior to publication. The population of these parameters values should not require technical expertise by the technical publisher.

Discussion: Within the IETF, IANA normally does its allocations as an early step in the technical publication process 🌸.

Derived Requirements:

• Req-PARAMEDIT-1 - The IETF technical publisher should work with IANA in the population of required parameter values into documents.

---

3.7. Post-approval, Pre-publication Technical Corrections 🚨

Task Description: No matter how hard everyone tries to minimize them, technical flaws can always show up in the window between document approval and publication 😭. The technical publisher may be requested to incorporate technical changes into the document prior to publication. Such changes necessitate a review and sign-off procedure. Another option is to disallow such corrections and treat them the same way post-publication errata would be treated. Note that this task is distinct from post-approval changes that might originate due to editorial review, because those originate from outside the technical publisher. For severe flaws, it should always be possible to withdraw the document from the publication queue (see Section 3.13) 🛑.

Discussion: The IETF allows minor technical corrections during the publication process. This should ideally be a rare occurrence. Since any changes introduced during the post-approval phase can lead to publication delays, it is important that only changes with technical merit be permitted. In particular, stylistic changes should be discouraged. IETF processes must be in place to vet changes proposed by the author, but this is not specifically a requirement on the technical publisher.

The interaction between the authors and the technical publisher must be sufficiently well policed that untracked and unapproved changes cannot be introduced by the author or other parties. Main character energy only, no sneaky edits 🙅‍♀️.

Derived Requirements:

• Req-POSTCORR-1 - The IETF technical publisher should permit the incorporation of technical changes detected after approval but pre-publication.
• Req-POSTCORR-2 - The IETF technical publisher should only allow post-approval technical changes that have been approved by the appropriate party. In the IETF standards process stream, this includes the authors and the Area Director. The document shepherd (if there is one) should be kept informed of these changes.
• Req-POSTCORR-3 - The IETF technical publisher should alert the appropriate authority when it feels that a requested change is suspect (e.g., an unapproved technical alteration) or unreasonable (e.g., massive editorial changes). Further processing of the draft should be suspended pending a response by that authority. For the IETF standards process stream, that authority is the Area Director. If there is a document shepherd working with the Area Director, the shepherd should be notified and kept informed as well.
• Req-POSTCORR-4 - The IETF technical publisher should ensure that any source documents associated with a publication are updated in conjunction with their associated specifications.

3.8. Allocation of Permanent Stable Identifiers 🆔

Task Description: Okay bestie, so if a document is gonna get referenced, it absolutely needs a unique permanent identifier 💅 Some standards orgs have the technical publisher generate that ID. In other cases the ID can get allocated earlier in the process ✨

Discussion: Rn the RFC Editor allocates RFC numbers and the other current IETF stable identifiers once a doc is near the end of publication 🧚 Getting IDs allocated early was considered, but a definite need just couldn't be established 🤷‍♀️

Derived Requirements:

• Req-PERMID-1 - The IETF technical publisher should allocate stable identifiers as part of the publication process.
• Req-PERMID-2 - The IETF technical publisher should assign additional permanent identifiers associated with various classes of documents as directed by the appropriate authority. For the IETF standards process stream, that authority is the IESG.

3.9. Document Format Conversions 📄

Task Description: The technical publisher handles converting documents into one or more output formats (for example, text and Portable Document Format (PDF)) 🎀 In some standards orgs, the technical publisher may have to accept input documents in various formats and turn them into a homogeneous set of output documents 🌈

Discussion: Rn the RFC Editor accepts input as an ASCII text file. It has also accepted supplementary formats that were used to generate the ASCII text, namely XML and NROFF 🍓 Documents get published as ASCII text and PDF files 💜

Derived Requirements:

• Req-DOCCONVERT-1 - The IETF technical publisher should accept as input ASCII text files and publish documents as ASCII text files and PDF files.
• Req-DOCCONVERT-2 - The technical publisher should accept supplemental files that may contain information such as code, formal descriptions (e.g., XML, ASN.1), graphics, data files, etc. Supplemental files may also include enhanced versions of the document containing graphics or sections not presentable in text format. Any supplemental files, barring any changes to the IETF process rules, will be associated with the published IETF documents, but may not be editable by the publisher.

3.10. Language Translation 🌍

Task Description: Some standards orgs require documents to be published in multiple languages. This translation is the responsibility of the technical publisher 🫶

Discussion: IETF specifications are published only in English 🇬🇧

Derived Requirements: none

3.11. Publication Status Tracking 🔍

Task Description: The technical publisher should be able to provide status information about a document 👀 This may involve developing a process model or a checklist and providing information on a document's state, outstanding issues, and responsibility tokens. Depending on how much transparency is needed, this information may need to be available online and continuously updated ✨

Discussion: Rn the RFC Editor shows status info through the RFC Editor queue. Each document gets a status (for example, AUTH48, RFC-EDITOR, IANA, ISR) 😭 Items can sit in the queue for a long time without changing status, and this tracking info isn't integrated with the IESG tracking tools 💀 Within the IETF, the Process and Tools (PROTO) team is looking at requirements for marking the token-holder accurately during long waiting periods, and others are looking into better notification tools 🔥 Requirements on the IETF technical publisher for better status integration and visibility could be met by collaborating with these efforts, by providing public access to email logs about publications, or by some other proposal 🧚

Derived Requirements:

• Req-STATUSTRK-1 - The IETF technical publisher should make state information publicly available for each document in the publication process. It is desirable that this information be available through a documented interface to facilitate tools development.
• Req-STATUSTRK-2 - The IETF technical publisher should integrate its state information with the IETF tools to provide end-to-end status tracking of documents. For the documents in the IETF standards process stream, it is expected that documents should be able to move seamlessly from the IETF standards tracking system into the technical publication tracking system.
• Req-STATUSTRK-3 - The IETF technical publisher should provide external visibility of not only the fact that a document is in an extended waiting period but also the token-holder and circumstances of the wait.

3.12. Expedited Handling 🚀

Task Description: In some cases (like when another standards body needs the documents), the approving organization should be able to request expedited publication of a document 🏃‍♀️ Ideally this doesn't skip any publication steps. Instead it gives the doc higher priority in the work queue so it gets published sooner than normal. Expedited publication should be used sparingly, because like any priority scheme, overusing it will cancel out its benefits 🙈

Discussion: The fast-tracking procedure is used to expedite publication of a document at the request of the IESG. Fast-tracking is generally used when an external org has a looming publication deadline and needs to reference a document that's currently in the RFC Editor's queue 😩 Short publication times would likely reduce the need for fast-tracking ⭐

Since fast-tracking disrupts the workflow, it is recommended that expedited handling be phased out as soon as alternative ways of achieving timely publication are in place 🌸

Derived Requirements:

• Req-EXPEDITE-1 - The IETF technical publisher should expedite the processing of specific documents at the request of an appropriate authority. For the IETF standards process stream, that authority is the IESG or the IAB.

3.13. Exception Handling 🛑

Task Description: There should be a way for a document to be withdrawn from publication, or for publication to be put on hold, for various reasons 🎀 Those reasons could include an appeals process, detection of a serious technical flaw, or a determination that the document is unsuitable for publication 😬

Discussion: For various reasons, a document can be withdrawn before publication 🥀

Derived Requirements:

• Req-EXCEPTIONS-1 - The IETF technical publisher should permit documents to be withdrawn from publication at the direction of an appropriate authority. For the IETF standards process stream, that authority is the IESG.
• Req-EXCEPTIONS-2 - The IETF technical publisher should permit documents to be put on hold awaiting the outcome of an appeal at the direction of an appropriate authority. For the IETF standards process stream, that authority is the IESG.

3.14. Notification of Publication 📣

Task Description: The technical publisher should provide a mechanism for alerting the wider community that published documents are available 💖

Discussion: The RFC Editor tells the community about publications on the rfc-dist and ietf-announce mailing lists 📬

Derived Requirements:

• Req-PUBNOTIFY-1 - The IETF technical publisher should announce the availability of published documents.

3.15. Post-publication Corrections (errata) 🩹

Task Description: If corrections are identified after publication, the technical publisher should be able to publish errata that can be linked with the original document 🔧

Discussion: The RFC Editor maintains a list of errata. Pointers to relevant errata show up as output from the RFC Editor search engine 🔎

Derived Requirements:

• Req-ERRATA-1 - The IETF technical publisher should maintain errata for published documents. The process for review, updating, and approval of errata for IETF documents will be defined by the IETF.
• Req-ERRATA-2 - The IETF technical publisher should provide information on relevant errata as part of the information associated with an RFC.

3.16. Indexing: Maintenance of the Catalog 📚

Task Description: The technical publisher normally provides and maintains the master catalog of that organization's publications 👑 As the publisher of the org's output, it's expected to be the definitive source of publications and the maintainer of the database of published documents. This also covers cataloging and storing meta-information about documents, such as their history, status (for example, updated or obsoleted), and document categories (for example, standard, draft standard, BCP) 🧚

Discussion: The RFC Editor maintains the catalog and is also responsible for the permanent archival of specifications 🗄️ Meta-information associated with an RFC should also be maintained. Since this is the definitive archive, sufficient security should be in place to prevent tampering with approved documents 🔐

Derived Requirements:

• Req-INDEX-1 - The IETF technical publisher should maintain the index of all IETF published documents. It is desirable that the interface to the index be documented to facilitate tools development.
• Req-INDEX-2 - The IETF technical publisher should provide the permanent archive for published documents.
• Req-INDEX-3 - Meta-information associated with a published document must be stored and updated as its status changes.
• Req-INDEX-4 - The archive must be sufficiently secure to prevent the modification of published documents by external parties.
• Req-INDEX-5 - The IETF technical publisher should provide the permanent archive of any source documents associated with a published specification.
• Req-INDEX-6 - An appropriate authority can indicate to the publisher that it should change the status of a document (e.g., to Historical) and this should be reflected in the index. For the IETF standards process stream, the indicating authority is the IESG.

3.17. Access to Published Documents 🔓

Task Description: The technical publisher should make published documents easy to access 💅 It's assumed the technical publisher will provide online tools for searching and finding information within the archive of published documents. These access tools should help people understand a document's state, such as identifying replacement or updated documents and linking to relevant errata 🦋

Discussion: Documents and their status can be accessed through the RFC Editor's web page 🌐

Derived Requirements:

• Req-PUBACCESS-1 - The IETF technical publisher should provide search tools for finding and retrieving published documents.
• Req-PUBACCESS-2 - The IETF technical publisher tool should return relevant meta-information associated with a published document (e.g., category of document, type of standard (if standards track), obsoleted by or updated by information, associated errata).
• Req-PUBACCESS-3 - The IETF technical publication search tools should be integrated with the IETF search tools. For the IETF standards process stream, this refers to integration with the search tools used by the IETF standards process.

3.18. Maintenance of a Vocabulary Document

Task Description: okay so some standards orgs want the technical publisher to keep a public vocabulary doc or database of common terms and acronyms 📚 The whole point is consistent terminology across documents, so everyone's speaking the same language bestie 🫶

Discussion: the RFC Editor does not maintain a public document or database of terms or acronyms 💅

Derived Requirements: none ✨

3.19. Providing Publication Statistics and Status Reports

Task Description: the technical publisher may be required to measure its performance regularly or continuously 📊 In lots of standards orgs, the targets are set around timeliness, throughput, and things like that. Very measurable, very serious 🤓

Discussion: the IETF technical publisher currently gives out monthly stats on arrivals and completions of documents by category 🎀 On top of that, there's a status report at every IETF meeting. Other stats can also show how healthy the editing process is 🌸 A lot of these could be gathered with sampling techniques, so the publisher isn't overloaded 🧚

Derived Requirements:

• Req-STATS-1 - The IETF technical publisher should provide publicly available monthly statistics on average queue times and documents processed. The presentation should provide a historical context to identify trends (see Goal-THROUGHPUT-1). For the IETF standards process, this should include queue arrivals, completions, documents in the queue, and the number of documents in each state at the end of the month. 📈✨
• Req-STATS-2 - The IETF technical publisher should provide periodic status reports at the IETF meetings to apprise the community of its work and performance. 🎤
• Req-STATS-3 - The IETF technical publisher should provide publicly available monthly statistics on the types of editorial corrections being found during reviews as well as the percentage of corrections that are rejected by the authors. 🧐
• Req-STATS-4 - The IETF technical publisher should provide publicly available monthly statistics on author-requested changes to documents under publication. This statistic should also include changes required by other authorities outside of the technical publisher empowered to make changes. For the IETF standards process, the designated authority would be the IESG or its designees. 👑

3.20. Process and Document Evolution

Task Description: the rules for an org's publication output are going to keep changing, no cap 🔄 New sections get added, styles and conventions shift, boilerplate gets updated, and the processes for publishing a spec change too. The technical publisher is expected to be part of those conversations and adapt as needed 🦋

Discussion: over time, the IETF consensus on what belongs in a published document has changed, and the processes that touch the publisher have changed too 🌈 Honestly, more changes are likely coming. The RFC Editor has been involved in these discussions and has put out guides, policies, FAQs, etc. to document what's currently expected of published documents 📝

Derived Requirements:

• Req-PROCESSCHG-1 - The IETF technical publisher should participate in the discussions of changes to author guidelines and publication process changes. 🗣️
• Req-PROCESSCHG-2 - The IETF technical publisher should participate in and support process experiments involving the technical publication process. 🧪

3.21. Tutorial and Help Services

Task Description: the technical publisher may be required to provide tutorials, mentoring, help desks, online tools, and so on 🎓 The goal is smooth interaction with the publisher and more awareness in the IETF community of document guidelines and procedures. Lots of orgs have a style manual that tells authors how to write a specification, and that's giving very helpful energy 💖

Discussion: authors get guidelines on how to write an RFC, plus the occasional tutorial presentation 🎀 The RFC Editor also runs a help desk at IETF meetings 🫶

Derived Requirements:

• Req-PUBHELP-1 - The IETF technical publisher should provide and maintain documentation giving guidance to authors on the layout, structure, expectations, etc. required to develop documents suitable for publication. For the IETF standards process stream, the technical publisher should follow IESG guidance in specifying documentation guidelines. 📖
• Req-PUBHELP-2 - The IETF technical publisher should provide tutorials to the IETF community to educate authors on the processes and expectations of the IETF technical publisher. 🍓
• Req-PUBHELP-3 - The IETF technical publisher should provide a contact email address and correspond as required to progress the publication work. The publisher should address queries from both inside and outside of the IETF community. 💌
• Req-PUBHELP-4 - The IETF technical publisher should provide a help desk at IETF meetings. 🙋‍♀️

3.22. Liaison and Communication Support

Task Description: it's a whole vibe for the technical publisher to have good info and communication about the work streams that will become publications 🦋 To keep the channel wide open, the technical publisher holds a liaison position on the IESG, where there can be valuable give-and-take about matters concerning the IETF standards stream 🤝

Discussion: the RFC Editor currently keeps a liaison position with the IESG 👑 Not specifically covered in these requirements, but the RFC Editor also keeps a liaison position toward the IAB 🌸

Derived Requirements:

• Req-LIAISON-1 - Through a liaison participant, the technical publisher should take part in meetings and activities as required in order to be aware of ongoing activities related to the work streams. For the IETF standards stream the technical publisher should participate in IESG formal meetings, IESG face-to-face activities at IETF, and other activities such as retreats. 🏕️✨

4. Technical Publisher Performance Goals

Technical publishers are typically measured not only on what they do but how well they perform the tasks 📊 The expectations in this section are treated as goals instead of requirements, and here's why 👀

• Achieving a given level of performance is not totally under the control of the technical publisher. Publication is a process, and the goals are of the process, not just the publisher 🫠
• The actual performance objectives will be set contractually. The values herein represent values that the IETF community feels are desirable and reasonable for work progress without consideration of financial or other factors 💼

Goals are set forth in the following areas:

1. Publication timeframes
2. Publication throughput

4.1. Publication Timeframes

Goal Description: this measures the time from entry into the RFC Editor queue until the documents are published ⏳ The metrics are defined in (req-STATS-1).

Discussion: long publication times cause both internal and external headaches 😭 Internally, authors wander off to other activities, and tempting post-approval fixes pile up on the document 🙈 Externally, other standards orgs can't reference IETF publications because there's no RFC number yet 💀

Derived Goals:

• Goal-TIMEFRAMES-1 - The consensus of the IETF community is that an average publication time of under a month is desirable. It is understood that in some cases there will be delays outside of the publisher's control. The actual performance targets and metrics are expected to be determined as part of the contract negotiation process. ⏰
• Goal-TIMEFRAMES-2 - The consensus of the IETF community is that the time required for a pre-approval review should be under 10 days. The actual performance targets and metrics are expected to be determined as part of the contract negotiation process. 🏃‍♀️💨

4.2. Publication Throughput

Goal Description: the number of documents published in a given time period is a measure of publisher throughput 🚀 Some publishers also report pages produced. The counts should be separated by categories of documents. The metrics are defined in (req-STATS-1).

Discussion: the RFC Editor currently gives monthly stats on arrivals and completions into the RFC queue, sorted by document category 📊 This shows how long things are being delayed in the publication process, which is very useful info 🧐

Derived Goals:

• Goal-THROUGHPUT-1 - Although minor variations are expected, there should be no long-term growth trend in the length of the publication queue. The actual performance targets and metrics are expected to be determined as part of the contract negotiation process. 📉💖

5. IETF Implications of Technical Publication Requirements

Requirements on the technical publication process have so far been stated in terms of requirements on the technical publisher. However, it must be recognized that many of these requirements have implications for the processes and tools within the IETF itself 🛠️ It is anticipated that these processes will be documented in companion documents 📚

The following is a list of potential issues that should be addressed within the IETF based on the requirements applied to the technical publisher 👑

• Pre- vs. Post-approval Editing: If emphasis switches from post-approval editing to pre-approval editing, then IETF processes must be adapted to make use of this service. The processes for post-approval editing can also be streamlined. ✂️
• Post-approval Editorial Cleanup: The IETF must define under what conditions the publisher should be instructed to bypass or minimize post-approval editing. 🧹
• Approval of Post-approval, Pre-publication Technical Corrections: Since the technical publisher can only accept approved changes, it must be clear who is allowed to approve technical changes. This process within the IETF needs to be decided and documented. ✅
• Allocation of Permanent Stable Identifiers: The IETF needs to clearly identify the naming/numbering schemes and classes of documents to which those names and numbers apply. Furthermore, the responsibility for allocation of those names/numbers needs to be identified. 🔢
• Expedited Handling: If publication timelines can be reduced sufficiently, then expedited handling may no longer be needed. 🏎️
• Post-publication Corrections: Appropriate processes must be defined with the IETF to ensure that errata are appropriately vetted and authorized. 🔍
• Indexing: Appropriate processes must be defined within the IETF to decide and inform the technical publisher of status changes to published documents as the result of an appeal, legal action, or some other procedural action. ⚖️

6. IANA Considerations

Any new requirements that result from this discussion need to be reviewed by IANA and the IETF to understand to what extent, if any, the work flow of the documents through IANA is affected 🦋

Interactions with IANA on population of parameter values is discussed in Section 3.6. 💜

7. Security Considerations 🔐

Okay bestie, this part is serious. There's a tussle between making things more readable ✨ and keeping the exact wording that people negotiated really carefully for the security stuff. That security language is the most sensitive part of any IETF doc, so extreme caution is needed before changing any of it. We're assuming that was already sorted out under Section 3.3 💅

The publishing processes should stop unapproved changes from getting in (see Section 3.7) 🚫 And since the IETF publisher keeps the index of publications, there should be enough security in place so outside parties can't change the published documents (see Section 3.16) 🔒

8. Acknowledgements 🫶

Bert Wijnen gave input on the early copyedit experiment and left useful comments all through the doc 💜 Leslie Daigle contributed a ton to this text 👑 Huge thanks to Steve Barclay, John Meredith, Yvette Ho Sang, and Sami Trabulsi for talking through how ATIS, ETSI, IEEE, and ITU publish things 🌸 Other shout-outs so far: a discussion on the wg chairs mailing list, Henning Schulzrinne, and Henrik Levkowetz 🎀

9. Informative References 📚

• [RFC2850] Internet Architecture Board and B. Carpenter, "Charter of the Internet Architecture Board (IAB)", BCP 39, RFC 2850, May 2000.

Authors' Addresses 🖊️

Allison Mankin
Bethesda, MD
USA

Phone: +1 301 728 7199
EMail: mankin@psg.com
URI: http://www.psg.com/~mankin/


Stephen Hayes
Ericsson
3634 Long Prairie Rd.
Ste 108-125
Flower Mound, TX 75022
USA

Phone: +1 469 360 8500
EMail: stephen.hayes@ericsson.com

Full Copyright Statement ©️

Copyright (C) The Internet Society (2006).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

The legal disclaimer, word for word:

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 💡

The IETF doesn't take a position on whether any Intellectual Property Rights or other rights that someone might claim for the tech in this document are valid or how far they reach, or whether licenses for them are available 🤷‍♀️ It also doesn't say it has independently tried to find any of those rights. For info on how rights work for RFC documents, check BCP 78 and BCP 79 📖

Copies of IPR disclosures sent to the IETF Secretariat, any assurances of licenses that will be available, and the results of any attempt to get a general license or permission to use these proprietary rights for implementers or users of this spec can be found at the IETF online IPR repository: http://www.ietf.org/ipr 🌐

The IETF invites anyone interested to flag any copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard 🦋 Send that info to the IETF at ietf-ipr@ietf.org 💌

Acknowledgement 🌈

Funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA) 💖