Network Working Group A. Mankin
Request for Comments: 4714
Category: Informational S. Hayes
Ericsson
October 2006
Network Working Group A. Mankin
Request for Comments: 4714
Category: Informational S. Hayes
Ericsson
October 2006
Requirements for IETF Technical Publication Service
IETF技术出版服务的要求
Status of This Memo
关于下段备忘
This memo provides information for 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).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
The work of the IETF is to discuss, develop, and disseminate technical specifications to support the Internet's operation. Technical publication is the process by which that output is disseminated to the community at large. As such, it is important to understand the requirements on the publication process.
IETF的工作是讨论、制定和传播支持互联网运行的技术规范。技术出版物是向整个社区传播成果的过程。因此，了解发布过程的要求很重要。
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 ....................................................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
The work of the IETF is to discuss, develop, and disseminate technical specifications to support the Internet's operation. Therefore, an important output of the IETF is published technical specifications. The IETF technical publisher is responsible for the final steps in the production of the published technical specifications. This document sets forth requirements on the duties of the IETF technical publisher and how it interacts with the IETF in the production of those publications.
IETF的工作是讨论、制定和传播支持互联网运行的技术规范。因此，IETF的一个重要输出是发布技术规范。IETF技术出版商负责出版技术规范的最后制作步骤。本文件规定了IETF技术出版商的职责要求，以及在这些出版物的制作过程中如何与IETF互动。
The term "technical specification" is used here purposefully to refer to the technical output of the IETF. This document does not engage in the debate about whether it is expressed as RFCs or otherwise, what "is" an RFC, how to classify them, etc. These issues are considered out of scope.
术语“技术规范”在这里是指IETF的技术输出。本文件不涉及是否表示为RFC、什么是RFC、如何对其进行分类等方面的辩论。这些问题被认为超出了范围。
The intention of this document is to clarify the IETF's consensus on its requirements for its technical publication service. It is expected to be used in the preparation of future contracts. This document is not a discussion of how well the current technical publisher (the RFC Editor) fulfills those requirements.
本文件旨在澄清IETF对其技术出版服务要求的共识。预计将在编制未来合同时使用。本文档不讨论当前技术出版商（RFC编辑器）如何满足这些要求。
The scope of this document is the requirements for the technical publication process for the IETF. Requirements on a technical publisher can be expressed in terms of both what tasks the IETF technical publisher is responsible for and performance targets the IETF technical publisher should meet. The functions provided by the technical publisher are sometimes referred to as editorial management [RFC2850].
本文件的范围是IETF技术出版过程的要求。对技术发布者的要求可以用IETF技术发布者负责的任务和IETF技术发布者应达到的性能目标来表示。技术出版商提供的功能有时被称为编辑管理[RFC2850]。
This document specifically addresses those documents published by the IETF technical standards process. In all cases, the requirements have been written in generic terms, so that they may be used to express the requirements of other publication streams, elsewhere.
本文件专门针对IETF技术标准过程发布的文件。在所有情况下，需求都是以通用术语编写的，因此它们可以用于表达其他发布流的需求。
The list of potential technical publication tasks was derived by considering the tasks currently performed by the RFC Editor as well as the responsibilities of the technical publishers in other standards organizations including 3GPP, ATIS, ETSI, IEEE, and ITU.
潜在技术发布任务列表是通过考虑RFC编辑器当前执行的任务以及其他标准组织（包括3GPP、ATIS、ETSI、IEEE和ITU）中技术发布者的责任而得出的。
This requirements document focuses on process issues in how the IETF technical publisher serves the IETF. There are related issues regarding non-technical aspects of document content that are not addressed in this requirements document. Issues not addressed in this document are:
本需求文件主要关注IETF技术出版商如何为IETF服务的过程问题。本需求文件中未涉及与文件内容的非技术方面相关的问题。本文件未涉及的问题包括：
o Policies governing the acceptable input and output document formats (including figures, etc.)
o 管理可接受的输入和输出文件格式的政策（包括数字等）
o Policies governing the acceptable character sets (internationalization)
o 管理可接受字符集的策略（国际化）
o Policies governing the layout and style of published documents
o 管理已发布文档的布局和样式的策略
o Policies governing the contents of non-technical sections (acknowledgement sections, reference classifications, etc.)
o 管理非技术章节内容的政策（确认章节、参考分类等）
It is realized that the above policies are also important aspects in determining that the final published document is a product of the IETF. These policies are likely to evolve as part of the ongoing IETF dialog. The IETF technical publisher should be part of the discussions of these policies and be prepared to implement and facilitate policy changes as they are determined by IETF consensus. This requirement is captured under the discussion of process and document evolution.
人们认识到，上述政策也是确定最终发布的文件是IETF产品的重要方面。这些政策可能会随着正在进行的IETF对话而发展。IETF技术出版商应参与这些政策的讨论，并准备实施和促进IETF共识确定的政策变更。这一需求在过程和文档演变的讨论中得到了体现。
Figure 1 below provides a useful summary of where technical publication falls in the current lifetime of a document in the IETF standards process. This figure shows a Working Group (WG) document and the reviews including Working Group Last Call (WGLC), Area Director (AD) review, IETF Last Call (IETF LC), IANA review, and IESG review. The document shepherd (shown in the diagram as "Shepherd") is an individual designated by the IESG to shepherd a document through the reviews and the publication process and is often not an AD. The lifetime is very similar for AD-sponsored IETF documents, such as documents that update IETF protocols for which there is no longer a working group, or documents on interdisciplinary topics.
下面的图1提供了一个有用的摘要，说明了IETF标准过程中技术出版物在文档当前生命周期中的位置。此图显示了工作组（WG）文件和评审，包括工作组最后一次呼叫（WGLC）、区域总监（AD）评审、IETF最后一次呼叫（IETF LC）、IANA评审和IESG评审。文件守护者（图中显示为“守护者”）是IESG指定的个人，负责引导文件通过审查和发布过程，通常不是广告。广告赞助的IETF文件的生命周期非常相似，例如更新IETF协议的文件，不再有工作组，或跨学科主题的文件。
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
| 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
图1：工作组文件的各个阶段
Note that in some cases a single submission may actually consist of multiple source documents (supporting files, code, etc.).
请注意，在某些情况下，一次提交实际上可能包含多个源文档（支持文件、代码等）。
Under the IETF standards process stream, the post-approval processing is initiated by the IESG after technical approval.
根据IETF标准流程，在技术批准后，IESG启动批准后处理。
Standards development organizations all have technical publication as part of their process. However, the boundaries between what is done by the technical committees and the technical publisher vary.
标准开发组织都有技术出版物作为其过程的一部分。但是，技术委员会和技术出版商所做工作之间的界限各不相同。
The following are potential tasks of a technical publisher. The following list was derived after analyzing the technical publication policies of the IETF and other standards development organizations.
以下是技术出版商的潜在任务。以下列表是在分析IETF和其他标准开发组织的技术发布政策后得出的。
1. Pre-approval review or editing
1. 预批准审核或编辑
2. Preliminary specification availability
2. 初步规范可用性
3. Post-approval editorial cleanup (non-author editing)
3. 审批后编辑清理（非作者编辑）
4. Validation of references
4. 参考文献的验证
5. Validation of formal languages
5. 形式语言的验证
6. Insertion of parameter values
6. 插入参数值
7. Post-approval, pre-publication technical corrections
7. 批准后、出版前技术更正
8. Allocation of permanent stable identifiers
8. 永久稳定标识符的分配
9. Document format conversions
9. 文档格式转换
10. Language translation
10. 语言翻译
11. Publication status tracking
11. 发布状态跟踪
12. Expedited handling
12. 加急处理
13. Exception handling
13. 异常处理
14. Notification of publication
14. 发布通知
15. Post-publication corrections (errata)
15. 出版后更正（勘误表）
16. Indexing: maintenance of the catalog
16. 索引：目录的维护
17. Access to published documents
17. 查阅已出版的文件
18. Maintenance of a vocabulary document
18. 词汇表文档的维护
19. Providing publication statistics and status reports
19. 提供出版物统计和状态报告
20. Process and document evolution
20. 过程和文件演变
21. Tutorial and help services
21. 教程和帮助服务
22. Liaison and communication support
22. 联络和通信支助
For each of these tasks, we discuss its relevance to the IETF and how it is realized within the IETF processes. Based upon this information, we derive requirements on the IETF technical publisher.
对于这些任务中的每一项，我们讨论其与IETF的相关性以及如何在IETF过程中实现。根据这些信息，我们得出了对IETF技术出版商的要求。
Task Description: This provides a review or editing service to improve document quality prior to the approval of a document. This review process would normally address issues such as grammar, spelling, formatting, adherence to pre-approval boilerplate, document structure, etc.
任务描述：提供审阅或编辑服务，以在批准文档之前提高文档质量。该审查过程通常会解决语法、拼写、格式、遵守预批准样板文件、文档结构等问题。
Discussion: Pre-approval review is not part of the current IETF standards process, but this concept has been explored in the early copyediting experiment. Early feedback from the experiment has been promising; however, the effectiveness of early editing is still being evaluated.
讨论：预批准审查不是当前IETF标准流程的一部分，但这一概念已在早期的文案编辑实验中得到探讨。实验的早期反馈是有希望的；然而，早期编辑的有效性仍在评估中。
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.
Req-PREEDIT-1：如果IETF选择实施预批准编辑，IETF技术出版商应能够尽早对文件进行编辑审查，以允许在技术审查过程中审查变更。对于IETF标准流程，应在工作组最后一次呼叫之前进行审查，并向作者提供反馈，以提高文件质量。对于IETF标准流程，出版商不应对文档进行技术审查。
Task Description: Some standards organizations require their publisher to make available a preliminary version of a document (with appropriate caveats) to make the information available to the industry as early as possible. This document is provided "as is" after the approval. This document is withdrawn once the final document 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.
讨论：这不是必需的。最终批准版本可作为互联网草稿提供。如果发布可能需要6个月以上的时间，则可能需要请求保留草稿版本。
Derived Requirements: none
衍生需求：无
Task Description: Most technical publishers do an editorial review to ensure the quality of published documents. Typically, this may address issues such as grammar, spelling, readability, formatting, adherence to boilerplate, document structure, etc. Since any proposed changes occur after approval, a review and signoff mechanism should usually be established to ensure that the required changes are truly editorial. Since such changes occur outside of the normal approval process, it is desirable that such changes are minimized. Most standards organizations target "light" editing due to the dangers of changing agreed-on text.
任务描述：大多数技术出版商都会进行编辑审查，以确保发布文档的质量。通常，这可能会解决语法、拼写、可读性、格式、遵守样板文件、文档结构等问题。由于任何提议的更改都是在批准后发生的，因此通常应建立审查和签署机制，以确保所需的更改是真正的编辑性更改。由于此类变更发生在正常审批流程之外，因此希望尽量减少此类变更。大多数标准组织的目标是“轻松”编辑，因为更改商定文本存在危险。
Discussion: Within the IETF, the RFC Editor does post-approval cleanup review and editing. The ambition level for cleanup can vary from:
讨论：在IETF中，RFC编辑器进行审批后清理审查和编辑。清理的目标级别可能不同于：
o corrections to errors only,
o 仅对错误进行更正，
o light rewriting,
o 轻改写，
o significant editing of documents with less skillful WG editors, and minimal editing when the WG editors were skilled, to
o 使用不太熟练的工作组编辑器对文档进行重大编辑，并在工作组编辑器熟练时进行最少的编辑，以
o rewriting of all documents to the dictates of a style manual.
o 按照样式手册的要求重写所有文档。
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)).
- IETF工作组商定的“样板”适用于衍生作品的所有实例（如IANA注册文件和管理信息库（MIB））。
- 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:
衍生需求：
o 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.
o Req-POSTEDIT-1-IETF技术出版商应审查文档的语法、拼写、格式、与样板文件的一致性、文档结构等。审查应努力保持与先前发布的文档外观的一致性。在IETF标准流程中，出版商不应对文档进行技术审查。
o 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.
o Req-POSTEDIT-2-应对审批后文件所做的所有更改进行跟踪，并且这些更改必须由相应的技术代表签字。对于IETF标准流程，这包括作者、文档管理员（如果有）和区域主管。区域总监是批准所有变更的权力机构。
o 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.
o Req-POSTEDIT-3-IETF技术出版商在进行风格变更时应加以限制，以引入大量的审查工作量，但仅增加规范的清晰度。可进一步规定允许变更类型的具体指南，但最终必须由IETF技术出版商对编辑进行限制。只有在文档质量出现重大问题时，才应更改样式一致性。
o 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.
o Req-POSTEDIT-4-IETF技术出版者在进行更改时应保持克制，以提高可读性，这可能会改变技术和共识措辞。可进一步规定允许变更类型的具体指南，但最终必须由IETF技术出版商对编辑进行限制。
o 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.
o Req-POSTEDIT-5-在特定情况下，如果部分或全部文件文本是（在工作组、评审员等内部或之间）对稿件进行仔细协商的结果，技术出版商可能需要逐字发布该文本。在IETF标准过程中，IESG可能会要求逐字出版。IETF社区期望不会经常这样做。
Task Description: Most standards organizations 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 more severe 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.
讨论：RFC编辑器可能会在等待其他IETF文档的可用性时搁置文档。不正确的引用会像编辑评论中检测到的任何其他错误一样进行处理。
Derived Requirements:
衍生需求：
o Req-REFVAL-1 - The IETF technical publisher should ensure that all references within specifications are currently available and are expected to remain available.
o Req-REFVAL-1-IETF技术出版商应确保规范中的所有参考文件当前可用，并且预计将保持可用。
o Req-REFVAL-2 - The IETF technical publisher should delay publication until all required (normative) references are ready for publication.
o Req-REFVAL-2-IETF技术出版商应推迟发布，直到所有要求的（规范性）参考文件准备好发布。
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.
任务描述：如果规范包含正式的语言部分（如MIB），则可能需要技术发布者使用工具对此进行验证。
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.
讨论：RFC编辑器在语法上验证文档的各个部分，这些部分包含MIB、增强的Backus Naur表单（ABNF）、可扩展标记语言（XML）、抽象语法表示法（ASN.1）以及可能的其他形式语言。
Derived Requirements:
衍生需求：
o 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.
o Req-FORMALVAL-1-IETF技术出版商应验证包含正式语言的文档部分的语法。特别是，ASN.1、ABNF和XML应该使用适当的工具进行验证。
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.
任务描述：技术发布者应在发布前与IANA（或维护注册中心的其他组织）合作，在需要时填充分配的协议参数值。这些参数值的总体不应要求技术发布者提供技术专业知识。
Discussion: Within the IETF, IANA normally does its allocations as an early step in the technical publication process.
讨论：在IETF中，IANA通常将其分配作为技术发布过程的早期步骤。
Derived Requirements:
衍生需求：
o Req-PARAMEDIT-1 - The IETF technical publisher should work with IANA in the population of required parameter values into documents.
o Req-PARAMEDIT-1-IETF技术出版商应与IANA合作，将所需参数值填充到文档中。
Task Description: Regardless of efforts to minimize their occurrence, it is always possible that technical flaws will be discovered 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 as post-publication errata would be treated. Note that this task is distinct from post-approval changes that might originate due to editorial review because they 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).
任务描述：无论如何努力将其发生率降到最低，在文档批准和发布之间的窗口中总是有可能发现技术缺陷。可能会要求技术出版者在出版前将技术变更纳入文件中。此类变更需要审查和签署程序。另一种选择是不允许此类更正，并将其视为出版后勘误表。请注意，此任务不同于可能由于编辑审查而产生的批准后更改，因为它们来自技术发布者之外。对于严重缺陷，应始终可以从发布队列中撤回文档（参见第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.
讨论：IETF允许在发布过程中进行轻微的技术更正。这在理想情况下应该很少发生。由于在批准后阶段引入的任何更改都可能导致发布延迟，因此只允许具有技术优点的更改非常重要。特别是，风格上的改变应该被阻止。IETF过程必须到位，以审查作者提出的变更，但这不是技术出版商的具体要求。
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.
作者和技术出版商之间的互动必须受到充分的监管，以确保作者或其他方不能引入未经跟踪和未经批准的变更。
Derived Requirements:
衍生需求：
o Req-POSTCORR-1 - The IETF technical publisher should permit the incorporation of technical changes detected after approval but pre-publication.
o Req-POSTCORR-1-IETF技术出版商应允许在批准后但在发布前检测到的技术变更纳入其中。
o 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.
o Req-POSTCORR-2-IETF技术出版商应仅允许经相关方批准的批准后技术变更。在IETF标准流程中，这包括作者和区域主管。应将这些变更告知文件管理员（如果有）。
o 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.
o Req-POSTCORR-3-当IETF技术出版商认为请求的变更可疑（例如，未经批准的技术变更）或不合理（例如，大量编辑变更）时，应通知相关机构。在该当局作出答复之前，应暂停对草案的进一步处理。对于IETF标准流程，该机构是区域主管。如果有文件管理员与区域总监一起工作，则应通知管理员，并随时通知管理员。
o 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.
o Req-POSTCORR-4-IETF技术出版商应确保与出版物相关的任何源文件均与其相关规范一起更新。
Task Description: For a document to be referenced, it must have a unique permanent identifier. In some standards organizations, it is the technical publisher that generates this identifier. In other cases, the identifier may be allocated earlier in the process.
任务描述：对于要引用的文档，它必须具有唯一的永久标识符。在某些标准组织中，是技术发布者生成此标识符。在其他情况下，标识符可以在过程的早期分配。
Discussion: Currently, the RFC Editor allocates RFC numbers and other identifiers (the current IETF stable identifiers) when the document is near the end of the publication process. Having identifiers allocated early was considered, but a definite need could not be established.
讨论：目前，RFC编辑器在文档接近发布过程结束时分配RFC编号和其他标识符（当前IETF稳定标识符）。已考虑提前分配标识符，但无法确定是否需要。
Derived Requirements:
衍生需求：
o Req-PERMID-1 - The IETF technical publisher should allocate stable identifiers as part of the publication process.
o Req-PERMID-1-IETF技术发布者应在发布过程中分配稳定的标识符。
o 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.
o Req-PERMID-2-IETF技术出版商应按照相关机构的指示，分配与各类文件相关的额外永久标识符。对于IETF标准流程，该机构是IESG。
Task Description: The technical publisher is responsible for converting the documents into one or more output formats (e.g., text, Portable Document Format (PDF)). In some standards organizations, the technical publisher may be required to accept input documents in various formats and produce a homogeneous set of output documents.
任务描述：技术出版商负责将文档转换为一种或多种输出格式（例如文本、可移植文档格式（PDF））。在一些标准组织中，技术发布者可能需要接受各种格式的输入文档，并生成一组同质的输出文档。
Discussion: Currently, the RFC Editor accepts input as an ASCII text file. The RFC Editor has also accepted supplementary formats that were used to generate the ASCII text (XML and NROFF). The documents are published as ASCII text and PDF files.
讨论：目前，RFC编辑器接受作为ASCII文本文件的输入。RFC编辑器还接受了用于生成ASCII文本（XML和NROFF）的补充格式。这些文档以ASCII文本和PDF文件的形式发布。
Derived Requirements:
衍生需求：
o Req-DOCCONVERT-1 - The IETF technical publisher should accept as input ASCII text files and publish documents as ASCII text files and PDF files.
o Req-DOCCONVERT-1-IETF技术出版商应接受ASCII文本文件作为输入，并将文档发布为ASCII文本文件和PDF文件。
o 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.
o Req-DOCCONVERT-2-技术出版商应接受可能包含代码、正式描述（如XML、ASN.1）图形、数据文件等信息的补充文件。补充文件还可能包括文件的增强版本，其中包含无法以文本格式呈现的图形或部分。除非对IETF过程规则进行任何更改，否则任何补充文件都将与已发布的IETF文档相关联，但出版商可能无法编辑。
Task Description: Some standards organizations require publication of documents in multiple languages. This translation is the responsibility of the technical publisher.
任务描述：一些标准组织要求以多种语言发布文档。此翻译由技术出版商负责。
Discussion: IETF specifications are published only in English.
讨论：IETF规范仅以英文发布。
Derived Requirements: none
衍生需求：无
Task Description: The technical publisher should have the ability to provide status information on the status of 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 the need for transparency, this information may need to be available online and continuously updated.
有关文档状态、未决问题和责任标记的信息。根据透明度的需要，这些信息可能需要在线提供并不断更新。
Discussion: The RFC Editor currently provides status information via the RFC Editor queue. Each document is attributed a status (e.g., AUTH48, RFC-EDITOR, IANA, ISR). Items may stay in the queue for a long time without changing status. This status tracking information is not integrated with the IESG tracking tools. Within the IETF, the Process and Tools (PROTO) team is considering requirements for marking the token-holder accurately during long waiting periods, and others are looking into improved notification tools. Requirements on the IETF technical publisher for improved status integration and visibility could be met by collaborations with these efforts, by providing public access to email logs regarding publications, or by some other proposal.
讨论：RFC编辑器当前通过RFC编辑器队列提供状态信息。每个文档都有一个状态（例如AUTH48、RFC-EDITOR、IANA、ISR）。项目可能会在队列中停留很长时间而不改变状态。此状态跟踪信息未与IESG跟踪工具集成。在IETF中，过程和工具（PROTO）团队正在考虑在长时间等待期间准确标记令牌持有者的要求，其他团队正在研究改进的通知工具。IETF技术发布商对改进状态集成和可见性的要求可以通过与这些工作的合作、提供有关出版物的电子邮件日志的公共访问或其他一些提案来满足。
Derived Requirements:
衍生需求：
o 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.
o Req-STATUSTRK-1-IETF技术出版商应在出版过程中公开每个文件的状态信息。希望通过文档化的界面提供这些信息，以促进工具开发。
o 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.
o Req-STATUSTRK-2-IETF技术发布者应将其状态信息与IETF工具集成，以提供文件的端到端状态跟踪。对于IETF标准流程中的文件，预计文件应能够无缝地从IETF标准跟踪系统移动到技术出版物跟踪系统。
o 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.
o Req-STATUSTRK-3-IETF技术发布者不仅应提供文档处于延长等待期这一事实的外部可视性，还应提供令牌持有人和等待情况的外部可视性。
Task Description: In some cases (such as when the documents are needed by another standards body), it should be possible for the approving organization to request expedited publication of a document. Ideally, this should not skip any of the publication steps, but allocates it higher priority in the work queue to ensure earlier publication than normal. Expedited publication should be used sparingly since as with any priority scheme, overuse will negate 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 employed when an external organization has a looming publication deadline and a need to reference a document currently in the RFC Editor's queue. Having short publication times would likely reduce the need for fast-tracking.
讨论：应IESG的要求，快速跟踪程序用于加快文件的发布。当外部组织的发布截止日期迫在眉睫，并且需要引用RFC编辑器队列中当前的文档时，通常采用快速跟踪。出版时间短可能会减少快速追踪的需要。
Since fast-tracking is disruptive to the work flow, it is recommended that expedited handling be phased out as soon as alternative ways of achieving timely publication are in place.
由于快速跟踪会中断工作流程，因此建议在实现及时发布的替代方法到位后，尽快停止快速处理。
Derived Requirements:
衍生需求：
o 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.
o Req-EXPENCE-1-IETF技术出版商应在适当机构的要求下加快特定文件的处理。对于IETF标准流程，该机构是IESG或IAB。
Task Description: It should be possible for various reasons for a document to be withdrawn from publication or the publication to be put on hold. Reasons for this could be due to an appeals process, detection of a serious technical flaw, or determination that the document is unsuitable for publication.
任务描述：由于各种原因，文档应该可以从出版物中撤回或暂停出版物。原因可能是上诉程序、检测到严重的技术缺陷或确定文件不适合出版。
Discussion: For various reasons, a document can be withdrawn before publication.
讨论：由于各种原因，文件可以在发布前撤回。
Derived Requirements:
衍生需求：
o 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.
o Req-EXCEPTIONS-1-IETF技术出版商应允许在适当权威机构的指示下从出版物中撤回文件。对于IETF标准流程，该机构是IESG。
o 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.
o Req-EXCEPTIONS-2-IETF技术出版商应允许在适当当局的指示下，在等待上诉结果时搁置文件。对于IETF标准流程，该机构是IESG。
Task Description: The technical publisher should provide a mechanism for alerting the community at large of the availability of published documents.
任务描述：技术发布者应提供一种机制，提醒社区发布文档的可用性。
Discussion: The RFC Editor notifies the community of document publication on the rfc-dist and ietf-announce mailing lists.
讨论：RFC编辑器通知社区RFC dist和ietf公告邮件列表上的文档发布。
Derived Requirements:
衍生需求：
o Req-PUBNOTIFY-1 - The IETF technical publisher should announce the availability of published documents.
o Req-PUBNOTIFY-1-IETF技术出版商应宣布已发布文件的可用性。
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 are presented as output from the RFC Editor search engine.
讨论：RFC编辑器维护勘误表列表。指向相关勘误表的指针显示为RFC编辑器搜索引擎的输出。
Derived Requirements:
衍生需求：
o 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.
o Req-ERRATA-1-IETF技术出版商应维护已发布文件的勘误表。IETF将定义IETF文件勘误表的审查、更新和批准过程。
o Req-ERRATA-2 - The IETF technical publisher should provide information on relevant errata as part of the information associated with an RFC.
o Req-ERRATA-2-IETF技术出版商应提供相关勘误表的信息，作为RFC相关信息的一部分。
Task Description: The technical publisher normally provides and maintains the master catalog of publications of that organization. As the publishers of the organization's output, the technical publisher is expected to be the definitive source of publications and the maintainer of the database of published documents. This also includes the cataloging and storage of meta-information associated with documents such as their history, status (e.g., updated, obsoleted), document categories (e.g., standard, draft standard, BCP).
任务描述：技术出版商通常提供并维护该组织出版物的主目录。作为本组织产出的出版者，技术出版者有望成为出版物的最终来源和已出版文件数据库的维护者。这还包括与文档相关的元信息的编目和存储，如文档的历史、状态（如更新、过时）、文档类别（如标准、标准草案、BCP）。
Discussion: The RFC Editor maintains the catalog. The RFC Editor 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.
讨论：RFC编辑器维护目录。RFC编辑器还负责规范的永久存档。还应维护与RFC关联的元信息。由于这是最终存档，因此应采取足够的安全措施，以防止篡改已批准的文档。
Derived Requirements:
衍生需求：
o 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.
o Req-INDEX-1-IETF技术出版商应维护所有IETF发布文件的索引。最好记录索引的接口，以便于工具开发。
o Req-INDEX-2 - The IETF technical publisher should provide the permanent archive for published documents.
o Req-INDEX-2-IETF技术出版商应提供已发布文件的永久存档。
o Req-INDEX-3 - Meta-information associated with a published document must be stored and updated as its status changes.
o Req-INDEX-3-必须存储与已发布文档相关的元信息，并在其状态更改时进行更新。
o Req-INDEX-4 - The archive must be sufficiently secure to prevent the modification of published documents by external parties.
o Req-INDEX-4-档案必须足够安全，以防止外部各方修改已发布的文件。
o Req-INDEX-5 - The IETF technical publisher should provide the permanent archive of any source documents associated with a published specification.
o Req-INDEX-5-IETF技术出版商应提供与已发布规范相关的任何源文件的永久存档。
o 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.
o Req-INDEX-6-适当的权威机构可以向发布者指出，它应该更改文档的状态（例如，更改为历史），这应该反映在索引中。对于IETF标准流程，指示机构为IESG。
Task Description: The technical publisher should facilitate access to the documents published. It is assumed that the technical publisher will provide online tools to search for and find information within the archive of published documents. These access tools should facilitate understanding the state of the document (e.g., identification of replacement or updated documents, linkage to pertinent errata).
任务描述：技术发布者应方便访问已发布的文档。假设技术出版商将提供在线工具，以搜索和查找已发布文档档案中的信息。这些访问工具应有助于理解文件的状态（例如，替换或更新文件的标识，与相关勘误表的链接）。
Discussion: Documents and status may be accessed via the RFC Editor's web page.
讨论：可以通过RFC编辑器的网页访问文档和状态。
Derived Requirements:
衍生需求：
o Req-PUBACCESS-1 - The IETF technical publisher should provide search tools for finding and retrieving published documents.
o Req-PUBACCESS-1-IETF技术出版商应提供搜索工具，用于查找和检索已发布的文档。
o 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
o Req-PUBACCESS-2-IETF技术发布工具应返回与已发布文档相关的元信息（例如，文档类别、标准类型（如果是标准
track), obsoleted by or updated by information, associated errata).
跟踪），由信息、相关勘误表淘汰或更新）。
o 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.
o Req-PUBACCESS-3-IETF技术出版物搜索工具应与IETF搜索工具集成。对于IETF标准流程，这是指与IETF标准流程使用的搜索工具的集成。
Task Description: Some standards organizations require the technical publisher to maintain a publicly available vocabulary document or database containing common terms and acronyms. The goal is to provide consistency of terminology between documents.
任务描述：一些标准组织要求技术发布者维护一个公开的词汇文档或包含常用术语和首字母缩略词的数据库。目标是提供文档之间术语的一致性。
Discussion: The RFC Editor does not maintain a public document or database of terms or acronyms.
讨论：RFC编辑器不维护术语或首字母缩略词的公共文档或数据库。
Derived Requirements: none
衍生需求：无
Task Description: The technical publisher may be required to periodically or continuously measure its performance. In many standards organizations, performance targets are set in terms of timeliness, throughput, etc.
任务描述：技术发布者可能需要定期或连续测量其性能。在许多标准组织中，性能目标是根据及时性、吞吐量等设定的。
Discussion: The IETF technical publisher currently provides monthly statistics on arrivals and completions of documents by category. In addition, a status report is provided at each IETF meeting. Other statistics can be used to judge the health of the editing process. Many of these statistics could be gathered using sampling techniques to avoid excessive load on the technical publisher.
讨论：IETF技术出版商目前提供按类别的文件到达和完成情况的月度统计数据。此外，在每次IETF会议上提供状态报告。其他统计数据可用于判断编辑过程的运行状况。可以使用抽样技术收集其中许多统计数据，以避免技术发布者承受过多的负载。
Derived Requirements:
衍生需求：
o 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.
o Req-STATS-1-IETF技术发布者应提供关于平均队列时间和处理文档的公开每月统计数据。演示文稿应提供历史背景，以确定趋势（见目标-1）。对于IETF标准流程，这应包括队列到达、完成、队列中的文档以及月末每个州的文档数量。
o 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.
o Req-STATS-2-IETF技术出版商应在IETF会议上提供定期状态报告，以告知社区其工作和绩效。
o 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.
o Req-STATS-3-IETF技术出版商应提供公开的每月统计数据，说明审查期间发现的编辑更正类型以及被作者拒绝的更正百分比。
o 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.
o Req-STATS-4-IETF技术出版商应提供公开的每月统计数据，说明作者要求对出版物中的文件进行的更改。该统计数据还应包括授权进行更改的技术出版商以外的其他机构所要求的更改。对于IETF标准过程，指定机构应为IESG或其指定人员。
Task Description: The guidelines and rules for an organization's publication output will change over time. New sections will be added to documents, styles and conventions will change, boilerplate will be changed, etc. Similarly, the specific processes for publication of a specification will change. The technical publisher is expected to be involved in these discussions and accommodate these changes as required.
任务描述：组织出版物输出的准则和规则将随时间而变化。新的章节将添加到文档中，样式和惯例将发生变化，样板文件将发生变化，等等。同样，规范发布的具体过程也将发生变化。技术出版商应参与这些讨论，并根据需要调整这些变更。
Discussion: Over time, the IETF consensus on what should be in a published document has changed. Processes interfacing with the publisher have also changed. Such changes are likely to continue in the future. The RFC Editor has been involved in such discussions and provided guides, policies, faqs, etc. to document the current expectations on published documents.
讨论：随着时间的推移，IETF对已发布文件中应包含的内容的共识发生了变化。与发布者接口的流程也发生了变化。这种变化在未来可能会继续。RFC编辑参与了此类讨论，并提供了指南、政策、常见问题解答等，以记录对已发布文档的当前期望。
Derived Requirements:
衍生需求：
o Req-PROCESSCHG-1 - The IETF technical publisher should participate in the discussions of changes to author guidelines and publication process changes.
o Req-PROCESSCHG-1-IETF技术出版商应参与对作者指南和出版过程变更的讨论。
o Req-PROCESSCHG-2 - The IETF technical publisher should participate in and support process experiments involving the technical publication process.
o Req-PROCESSCHG-2-IETF技术出版商应参与并支持涉及技术出版过程的过程实验。
Task Description: The technical publisher may be required to provide tutorials, mentoring, help desks, online tools, etc. to facilitate smooth interaction with the technical publisher and to increase the IETF community's awareness of document guidelines, procedures, etc. In many organizations, the publisher maintains a style manual giving explicit guidance to authors on how to write a specification.
任务描述：技术出版商可能需要提供教程、指导、帮助台、在线工具等，以促进与技术出版商的顺利互动，并提高许多组织的IETF社区对文档指南、程序等的认识，出版商维护一份样式手册，明确指导作者如何编写规范。
Discussion: Guidelines are provided to the authors on how to write an RFC as well as occasional tutorial presentations. The RFC Editor provides a help desk at IETF meetings.
讨论：为作者提供了如何编写RFC的指南，以及偶尔的教程演示。RFC编辑器在IETF会议上提供帮助台。
Derived Requirements:
衍生需求：
o 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.
o Req-PUBHELP-1-IETF技术出版商应提供并维护文件，为作者提供开发适合出版的文件所需的布局、结构、期望等方面的指导。对于IETF标准过程流，技术出版商应遵循IESG指南指定文档指南。
o 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.
o Req-PUBHELP-2-IETF技术出版商应向IETF社区提供教程，以教育作者了解IETF技术出版商的流程和期望。
o 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.
o Req-PUBHELP-3-IETF技术出版商应提供联系电子邮件地址，并根据需要进行通信，以推进出版工作。发布者应处理来自IETF社区内外的查询。
o Req-PUBHELP-4 - The IETF technical publisher should provide a help desk at IETF meetings.
o Req-PUBHELP-4-IETF技术出版商应在IETF会议上提供帮助台。
Task Description: It is very valuable for the technical publisher of an organization to have good information and communication about the work streams that will result in publication streams. In order to ensure a wide communication channel for the work, 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.
任务描述：对于一个组织的技术发布者来说，获得关于将产生发布流的工作流的良好信息和沟通是非常有价值的。为了确保工作有广泛的沟通渠道，技术出版商在IESG上保持联络，在IESG上可以就IETF标准流的相关事宜进行有价值的交流。
Discussion: The RFC Editor currently maintains a liaison position with the IESG. Although not specifically addressed in these requirements, the RFC Editor also maintains a liaison position toward the IAB.
讨论：RFC编辑目前与IESG保持联络。尽管在RFIAB的位置上，这些要求也没有明确提到。
Derived Requirements:
衍生需求：
o 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.
o Req-LIONATION-1-通过联络参与者，技术出版商应根据需要参加会议和活动，以了解与工作流相关的正在进行的活动。对于IETF标准流，技术出版商应参加IESG正式会议、IESG在IETF的面对面活动以及其他活动，如静修。
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 because:
技术发布者通常不仅要衡量他们做什么，还要衡量他们完成任务的能力。本节中的期望被视为目标而不是要求，因为：
- 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.
- 实际绩效目标将以合同形式设定。本文中的值表示IETF社区认为在不考虑财务或其他因素的情况下，工作进展是可取和合理的值。
Goals are set forth in the following areas:
目标规定在以下领域：
1. Publication timeframes
1. 出版时间表
2. Publication throughput
2. 出版物吞吐量
Goal Description: This is a measure of the time from entry into the RFC Editor queue until the documents are published. The metrics are defined in (req-STATS-1).
目标描述：这是从进入RFC编辑器队列到文档发布的时间度量。指标在（req-STATS-1）中定义。
Discussion: Long publication times create both internal and external difficulties. Internal difficulties include the migration of authors to other activities and the accumulation of tempting post-approval fixes to be added to the document. External difficulties include the inability of other standards organizations to reference IETF publications for lack of an RFC number.
讨论：较长的出版时间造成内部和外部困难。内部困难包括作者迁移到其他活动，以及在文档中添加诱人的批准后修复。外部困难包括由于缺少RFC编号，其他标准组织无法参考IETF出版物。
Derived Goals:
衍生目标：
o 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.
o 目标-时间框架-1-IETF社区的共识是，平均出版时间不到一个月是可取的。据了解，在某些情况下，会出现出版商无法控制的延迟。实际绩效目标和指标预计将作为合同谈判过程的一部分确定。
o 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.
o 目标-时间框架-2-IETF社区的共识是，预批准审查所需的时间应在10天以内。实际绩效目标和指标预计将作为合同谈判过程的一部分确定。
Goal Description: The number of documents published during a given time period is a measure of publisher throughput. Some publishers also provide the data in terms of pages produced. The counts should be separated by categories of documents. The metrics are defined in (req-STATS-1).
目标描述：给定时间段内发布的文档数量是发布者吞吐量的度量。一些出版商还提供所制作页面的数据。计数应按文件类别分开。指标在（req-STATS-1）中定义。
Discussion: The RFC Editor currently provides monthly statistics on the arrival and completion of documents into the RFC queue. This is sorted by category of document. This provides a measure of the delays in the publication process.
讨论：RFC编辑器目前提供RFC队列中文档到达和完成情况的月度统计信息。这是按文档类别排序的。这提供了发布过程中延迟的度量。
Derived Goals:
衍生目标：
o 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.
o 目标-吞吐量-1-虽然预计会有微小的变化，但发布队列的长度不会有长期增长趋势。实际绩效目标和指标预计将作为合同谈判过程的一部分确定。
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.
到目前为止，技术出版过程的要求已在技术出版商的要求中说明。然而，必须认识到，这些要求中的许多对IETF本身的过程和工具有影响。预计这些过程将记录在配套文件中。
The following is a list of potential issues that should be addressed within the IETF based on the requirements applied to the technical publisher:
以下是应根据适用于技术出版商的要求在IETF中解决的潜在问题列表：
o 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.
o 批准前编辑与批准后编辑：如果重点从批准后编辑切换到批准前编辑，则必须调整IETF流程以使用此服务。还可以简化审批后编辑流程。
o Post-approval Editorial Cleanup: The IETF must define under what conditions the publisher should be instructed to bypass or minimize post-approval editing.
o 批准后编辑清理：IETF必须定义在何种条件下出版商应被指示绕过或最小化批准后编辑。
o 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.
o 批准后、发布前技术更正的批准：由于技术发布者只能接受批准的更改，因此必须明确允许谁批准技术更改。需要确定并记录IETF中的该过程。
o 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.
o 永久稳定标识符的分配：IETF需要清楚地确定命名/编号方案以及这些名称和编号适用的文件类别。此外，需要确定分配这些姓名/号码的责任。
o Expedited Handling: If publication timelines can be reduced sufficiently, then expedited handling may no longer be needed.
o 快速处理：如果可以充分缩短发布时间，则可能不再需要快速处理。
o Post-publication Corrections: Appropriate processes must be defined with the IETF to ensure that errata are appropriately vetted and authorized.
o 出版后更正：必须与IETF一起定义适当的过程，以确保勘误表得到适当的审查和授权。
o 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.
o 索引：必须在IETF中定义适当的过程，以决定并通知技术出版商由于上诉、法律行动或其他程序行动而导致的已发布文件的状态变化。
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.
讨论产生的任何新要求都需要IANA和IETF进行审查，以了解通过IANA的文件工作流程受到的影响程度（如有）。
Interactions with IANA on population of parameter values is discussed in Section 3.6.
第3.6节讨论了与IANA在参数值总体上的相互作用。
There is a tussle between the sought-for improvements in readability and the specific language that has often been negotiated carefully for the security content of IETF documents. As with other text, extreme caution is needed in modifying any text in the security considerations. This issue is assumed to have been dealt with under Section 3.3.
在寻求提高可读性的方法和通常为IETF文档的安全内容而仔细协商的特定语言之间存在着一场争斗。与其他文本一样，在修改安全注意事项中的任何文本时，都需要格外小心。假设该问题已在第3.3节中处理。
The processes for the publication of documents should prevent the introduction of unapproved changes (see Section 3.7). Since the IETF publisher maintains the index of publications, sufficient security should be in place to prevent these published documents from being changed by external parties (see Section 3.16)
文件发布流程应防止引入未经批准的变更（见第3.7节）。由于IETF出版商维护出版物索引，因此应采取足够的安全措施，以防止外部各方更改这些已发布的文件（见第3.16节）
Bert Wijnen has provided input on the early copyedit experiment and made useful comments throughout the document. Leslie Daigle has contributed strongly to this text. Thanks to Steve Barclay, John Meredith, Yvette Ho Sang, and Sami Trabulsi for discussions of the publication practices of ATIS, ETSI, IEEE, and ITU. Other acknowledgements to date: a discussion on the wg chairs mailing list, Henning Schulzrinne, and Henrik Levkowetz.
Bert Wijnen就早期的文案编辑实验提供了意见，并在整个文档中发表了有用的评论。莱斯利·戴格尔（Leslie Daigle）对这篇文章做出了巨大贡献。感谢Steve Barclay、John Meredith、Yvette Ho Sang和Sami Trabulsi讨论ATIS、ETSI、IEEE和ITU的出版实践。迄今为止的其他确认：关于工作组主席邮寄名单的讨论，Henning Schulzrinne和Henrik Levkowetz。
[RFC2850] Internet Architecture Board and B. Carpenter, "Charter of the Internet Architecture Board (IAB)", BCP 39, RFC 2850, May 2000.
[RFC2850]互联网架构委员会和B.Carpenter，“互联网架构委员会（IAB）章程”，BCP 39，RFC 2850，2000年5月。
Authors' Addresses
作者地址
Allison Mankin Bethesda, MD USA
Allison Mankin Bethesda，美国马里兰州
Phone: +1 301 728 7199
EMail: mankin@psg.com
URI: http://www.psg.com/~mankin/
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
斯蒂芬·海斯·爱立信美国德克萨斯州花丘街108-125号长草原路3634号，邮编75022
Phone: +1 469 360 8500
EMail: stephen.hayes@ericsson.com
Phone: +1 469 360 8500
EMail: stephen.hayes@ericsson.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（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.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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 takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。