Network Working Group J. Klensin, Ed.
Request for Comments: 4846 D. Thaler, Ed.
Category: Informational July 2007
Network Working Group J. Klensin, Ed.
Request for Comments: 4846 D. Thaler, Ed.
Category: Informational July 2007
Independent Submissions to the RFC Editor
向RFC编辑器提交的独立意见
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 IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
There is a long-standing tradition in the Internet community, predating the Internet Engineering Task Force (IETF) by many years, of use of the RFC Series to publish materials that are not rooted in the IETF standards process and its review and approval mechanisms. These documents, known as "Independent Submissions", serve a number of important functions for the Internet community, both inside and outside of the community of active IETF participants. This document discusses the Independent Submission model and some reasons why it is important. It then describes editorial and processing norms that can be used for Independent Submissions as the community goes forward into new relationships between the IETF community and its primary technical publisher.
互联网社区有一个悠久的传统，比互联网工程任务组（IETF）早了很多年，即使用RFC系列来发布不符合IETF标准流程及其审查和批准机制的材料。这些文件被称为“独立提交”，为互联网社区提供了许多重要功能，包括活跃IETF参与者社区内外的功能。本文讨论了独立提交模型及其重要性的一些原因。然后描述了在IETF社区与其主要技术出版商之间建立新关系时，可用于独立提交的编辑和处理规范。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology Note . . . . . . . . . . . . . . . . . . . . . 3
1.2. Context and Philosophical Assumptions . . . . . . . . . . 4
2. The Role of Independent Submissions . . . . . . . . . . . . . 4
3. Document Submission . . . . . . . . . . . . . . . . . . . . . 5
4. The Review Process . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Posting of Draft . . . . . . . . . . . . . . . . . . . . . 6
4.2. Request for Publication . . . . . . . . . . . . . . . . . 6
4.3. Initial RFC Editor Review . . . . . . . . . . . . . . . . 6
4.4. Review and Evaluation . . . . . . . . . . . . . . . . . . 7
4.5. Additional Reviews . . . . . . . . . . . . . . . . . . . . 7
4.6. Document Rejection . . . . . . . . . . . . . . . . . . . . 7
4.7. Final Decision and Notification . . . . . . . . . . . . . 8
4.8. Final Editing and Publication . . . . . . . . . . . . . . 8
5. Formal IESG Review . . . . . . . . . . . . . . . . . . . . . . 8
6. The Editorial Review Board . . . . . . . . . . . . . . . . . . 9
7. Status and Availability of Reviews . . . . . . . . . . . . . . 10
7.1. Posted Reviews . . . . . . . . . . . . . . . . . . . . . . 10
7.2. Rejected Documents . . . . . . . . . . . . . . . . . . . . 11
7.3. Documents Approved for Publication . . . . . . . . . . . . 11
8. Intellectual Property Rights . . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. IAB Members at the Time of Approval . . . . . . . . . 15
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology Note . . . . . . . . . . . . . . . . . . . . . 3
1.2. Context and Philosophical Assumptions . . . . . . . . . . 4
2. The Role of Independent Submissions . . . . . . . . . . . . . 4
3. Document Submission . . . . . . . . . . . . . . . . . . . . . 5
4. The Review Process . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Posting of Draft . . . . . . . . . . . . . . . . . . . . . 6
4.2. Request for Publication . . . . . . . . . . . . . . . . . 6
4.3. Initial RFC Editor Review . . . . . . . . . . . . . . . . 6
4.4. Review and Evaluation . . . . . . . . . . . . . . . . . . 7
4.5. Additional Reviews . . . . . . . . . . . . . . . . . . . . 7
4.6. Document Rejection . . . . . . . . . . . . . . . . . . . . 7
4.7. Final Decision and Notification . . . . . . . . . . . . . 8
4.8. Final Editing and Publication . . . . . . . . . . . . . . 8
5. Formal IESG Review . . . . . . . . . . . . . . . . . . . . . . 8
6. The Editorial Review Board . . . . . . . . . . . . . . . . . . 9
7. Status and Availability of Reviews . . . . . . . . . . . . . . 10
7.1. Posted Reviews . . . . . . . . . . . . . . . . . . . . . . 10
7.2. Rejected Documents . . . . . . . . . . . . . . . . . . . . 11
7.3. Documents Approved for Publication . . . . . . . . . . . . 11
8. Intellectual Property Rights . . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. IAB Members at the Time of Approval . . . . . . . . . 15
There is a long-standing tradition in the Internet community, predating the IETF by many years, of use of the RFC Series to publish materials that are not rooted in the IETF standards process and its review and approval mechanisms. These documents, known as "Independent Submissions", serve a number of important functions for the Internet community, both inside and outside of the community of active IETF participants. This document discusses the Independent Submission model and some reasons why it is important. It then describes editorial and processing norms that can be used for Independent Submissions as the community goes forward into new relationships between the IETF community and its primary technical publisher.
互联网社区有一个悠久的传统，比IETF早了很多年，即使用RFC系列发布不属于IETF标准流程及其审查和批准机制的材料。这些文件被称为“独立提交”，为互联网社区提供了许多重要功能，包括活跃IETF参与者社区内外的功能。本文讨论了独立提交模型及其重要性的一些原因。然后描述了在IETF社区与其主要技术出版商之间建立新关系时，可用于独立提交的编辑和处理规范。
To understand the perspective of this document, it is important to remember that the RFC Editor function predates the creation of the IETF. As of the time of this writing, the RFC Series goes back 38 years [RFC2555], while the IETF is celebrating its 21st anniversary. All of the documents that were published before the IETF was created, and for some years thereafter, would be considered Independent Submissions today. As the IETF evolved, the Internet Architecture Board (IAB) and then the IETF itself chose to publish IETF documents as RFCs while fully understanding that the RFC Editor function was an independent publication mechanism. Other decisions were possible: e.g., the IETF could have decided to create its own publication series. It was felt that there was considerable value in continuing to publish the IETF work in the same series as the one used to publish the basic protocols for the Internet.
要理解本文档的观点，重要的是要记住RFC编辑器功能早于IETF的创建。截至本文撰写之时，RFC系列可追溯到38年前[RFC2555]，而IETF正在庆祝其21周年。在IETF创建之前以及之后几年内发布的所有文件今天都将被视为独立提交的文件。随着IETF的发展，互联网体系结构委员会（IAB）和IETF本身选择将IETF文档发布为RFC，同时充分理解RFC编辑器功能是一种独立的发布机制。其他决定也是可能的：例如，IETF可以决定创建自己的出版物系列。人们认为，继续将IETF的工作与用于发布互联网基本协议的工作放在同一系列中，具有相当大的价值。
This document describes what have historically been referred to as "Independent Submissions". That term is distinguished from those IETF and IAB community documents that originate from formal groups -- the IAB, IRTF, and IETF Working Groups -- and from submissions submitted to the Internet Engineering Steering Group (IESG) for Standards-Track, Informational, or Experimental processing. Documents produced by individuals, rather than IETF WGs or others IETF-affiliated groups, but submitted for publication via the IESG under Area Director sponsorship, are known as "individual submissions".
本文件描述了历史上被称为“独立意见书”的内容。该术语与源自正式小组（IAB、IRTF和IETF工作组）的IETF和IAB社区文件以及提交给互联网工程指导小组（IESG）进行标准跟踪、信息或实验处理的提交文件不同。由个人而非IETF工作组或其他IETF附属团体制作的文件，但在区域总监的赞助下通过IESG提交以供发布，称为“个人提交文件”。
For convenience and obvious historical reasons, the editor and publisher of documents that are not processed through the IETF is known below as the "RFC Editor". The RFC Editor will typically be an organization of one or more senior people and associated editorial staff, and the term is used collectively below. That term is not
出于方便和明显的历史原因，未通过IETF处理的文档的编辑和发布者称为“RFC编辑器”。RFC编辑通常是由一名或多名高级人员和相关编辑人员组成的组织，以下统称该术语。这个术语不是
intended to predict the future, either in terms of who does the job or what they, or the document series, are called.
旨在预测未来，无论是根据谁做的工作或他们做了什么，或是文件系列，都被称为。
This document complements the discussion and guidelines in [RFC4714], which focuses on Standards-Track documents. It takes a somewhat stronger view than the discussions that led to that document, starting from the belief that Independent Submissions are most valuable if they are, in fact, independent of the IETF process. From the perspective of the IETF, Independent Submissions are especially important as checks on the IETF processes even though such checks are not the only, or even a common, reason for them. That role is compromised if IETF-related entities are able to block or deprecate such documents to a degree beyond that needed to avoid difficulties with the standards process.
本文件补充了[RFC4714]中的讨论和指南，其重点是标准跟踪文件。它采取了比导致该文件的讨论更强烈的观点，从独立提交最有价值的信念开始，如果它们实际上独立于IETF过程。从IETF的角度来看，独立提交作为对IETF过程的检查尤其重要，尽管此类检查不是IETF过程的唯一原因，甚至不是常见原因。如果IETF相关实体能够阻止或弃用此类文档的程度超过避免标准过程困难所需的程度，则该角色将受到损害。
When the RFC Series was fairly new, RFCs were used to publish general papers on networking as well as the types of documents we would describe as standards today. Those roles also developed as part of the early design and development of the ARPANET, long before anyone dreamt of the IETF and when the distinction between, e.g., Standards and Informational documents was less precisely drawn. In more recent years, Independent Submissions have become important for multiple reasons, some of them relatively new. They include:
当RFC系列相当新的时候，RFC被用来发布关于网络的一般性论文，以及我们今天描述为标准的文档类型。这些角色也作为ARPANET早期设计和开发的一部分发展起来，早在任何人梦想IETF之前，以及当标准和信息文档之间的区别不太精确时。近年来，独立提交的文件由于多种原因变得重要，其中一些相对较新。这些措施包括：
o Discussion of Internet-related technologies that are not part of the IETF agenda.
o 讨论不属于IETF议程的互联网相关技术。
o Introduction of important new ideas as a bridge publication venue between academia and IETF engineering.
o 介绍重要的新思想，作为学术界和IETF工程之间的桥梁。
o Informational discussions of technologies, options, or experience with protocols.
o 关于技术、选项或协议经验的信息性讨论。
o Informational publication of vendor-specific protocols.
o 供应商特定协议的信息发布。
o Critiques and discussions of alternatives to IETF Standards-Track protocols. The potential for such critiques provides an important check on the IETF's standards processes and should be seen in that light.
o 对IETF标准跟踪协议替代方案的评论和讨论。这种批评的可能性为IETF的标准过程提供了一个重要的检查，应该从这个角度来看待。
o Documents considered by IETF Working Groups but not standardized. While many documents of this type are still published in the IETF document stream (see [RFC4844], Section 5.1.1) as Informational or
o IETF工作组审议但未标准化的文件。尽管许多此类文件仍在IETF文件流中发布（见[RFC4844]，第5.1.1节），作为信息或
Experimental RFCs, the Independent Submission path has traditionally been open to them as well. However, because of their intimate connection to the IETF Standards Process and WG activities and the consequent sensitivity to exact statements of relationships and to timing, there is reason to believe that such documents should normally be published via the IETF document stream. In any event, these documents are published for the historical record.
作为实验性的RFC，独立提交路径传统上也对它们开放。然而，由于其与IETF标准过程和工作组活动的密切联系，以及由此产生的对精确关系声明和时间安排的敏感性，有理由相信此类文件通常应通过IETF文件流发布。无论如何，这些文件都是为了历史记录而出版的。
o Satirical materials.
o 讽刺材料。
o Meeting notes and reports (RFC 21 [RFC0021] is the earliest; RFC 1109 [RFC1109] is probably the most important).
o 会议记录和报告（RFC 21[RFC0021]是最早的；RFC 1109[RFC1109]可能是最重要的）。
o Editorials (the best example is IEN 137 [IEN137], not an RFC).
o 社论（最好的例子是IEN137[IEN137]，而不是RFC）。
o Eulogies (RFC 2441 [RFC2441]).
o 悼词（RFC22441[RFC2441]）。
o Technical contributions (e.g., RFC 1810 [RFC1810]).
o 技术贡献（如RFC 1810[RFC1810]）。
o Historically, RFC Editor and, at least prior to the handoff between the Informational Sciences Institute (ISI) and the Internet Corporation for Assigned Names and Numbers (ICANN) and the June 2000 MOU [RFC2860], Internet Assigned Numbers Authority (IANA) Policy Statements (e.g., RFC 2223 [RFC2223] and RFC 1591 [RFC1591]).
o 从历史上看，至少在信息科学研究所（ISI）和互联网名称和数字分配公司（ICANN）以及2000年6月谅解备忘录[RFC2860]移交之前，互联网分配号码管理局（IANA）政策声明（如RFC 2223[RFC2223]和RFC 1591[RFC1591]）。
It should be clear from the list above that, to be effective, the review and approval process for Independent Submissions should be largely independent of the IETF. As an important principle that has been applied historically, the RFC Editor seeks advice from the IESG about possible relationships and conflicts with IETF work. Any submission that constitutes an alternative to, or is in conflict with, an IETF Standard or proposal for Standards-Track adoption must clearly indicate that relationship. The IESG may identify such conflicts as part of its review.
从上面的列表中可以清楚地看到，为了有效，独立提交的审查和批准过程应该在很大程度上独立于IETF。作为历史上应用过的一项重要原则，RFC编辑向IESG咨询与IETF工作可能存在的关系和冲突。任何构成IETF标准替代方案或与IETF标准或标准轨道采用提案冲突的提交文件必须明确指出这种关系。IESG可将此类冲突确定为其审查的一部分。
The specific procedures to be followed in review are described in Section 4 and Section 5.
第4节和第5节介绍了审查中应遵循的具体程序。
Independent Submissions are submitted directly to the RFC Editor. They must first be posted as Internet-Drafts (I-Ds), so the submission is typically simply a note requesting that the RFC Editor consider a particular Internet-Draft for publication. The process is described in [RFC2223]. Further information can be found in the working draft of an update of that document [RFC2223BIS].
独立提交直接提交给RFC编辑器。它们必须首先被发布为Internet草稿（i-DS），所以提交通常只是一个注释，要求RFC编辑器考虑特定的因特网草案以供发布。[RFC2223]中描述了该过程。更多信息见该文件更新工作草案[RFC2223BIS]。
Any document that meets the requirements of this specification, of [RFC2223] and its successors, and of any intellectual property or other conditions that may be established from time to time, may be submitted to the RFC Editor for consideration as an Independent Submission. However, the RFC Editor prefers that documents created through IETF processes (e.g., working group output) be considered by the IESG and submitted using this path only if a working group or the IESG declines to publish it. In the latter cases, the review process will be more efficient if the authors provide a history of consideration and reviews of the document at the time of submission.
任何符合本规范、[RFC2223]及其后续文件、任何知识产权或其他不时确定的条件要求的文件，可作为独立提交文件提交给RFC编辑考虑。但是，RFC编辑器倾向于IESG考虑通过IETF流程创建的文档（例如，工作组输出），并且仅当工作组或IESG拒绝发布时，才使用此路径提交。在后一种情况下，如果作者在提交文件时提供文件审议和审查的历史记录，审查过程将更加有效。
In general, the steps in the review process are identified in the subsections below. Any of them may be iterated and, at the discretion of the RFC Editor, steps after the first may be taken out of order. In addition, the IESG review, as discussed in Section 5, must take place before a final decision is made on whether to publish the document.
一般来说，审查过程中的步骤在下面的小节中确定。它们中的任何一个都可以被迭代，并且根据RFC编辑器的判断，第一个步骤之后的步骤可能会被打乱顺序。此外，如第5节所述，IESG审查必须在最终决定是否发布文件之前进行。
The author(s) or editor(s) of a document post it as an Internet-Draft.
文档的作者或编辑将其作为互联网草稿发布。
After the normal opportunity for community review and feedback provided by the submission of the I-D and the I-D repository announcement thereof, the author or editor sends a request for consideration for publication to the RFC Editor at rfc-editor@rfc-editor.org. That request should note any community discussion or reviews of the document that have occurred before submission, as well as the desired document category (Informational or Experimental, as discussed in RFC 2026 [RFC2026], Section 4.2).
在提交I-D和I-D存储库公告提供社区审查和反馈的正常机会后，作者或编辑向RFC的RFC编辑发送考虑出版的请求-editor@rfc-editor.org。该请求应注明提交前发生的任何社区讨论或文件审查，以及所需的文件类别（信息性或实验性，如RFC 2026[RFC2026]第4.2节所述）。
If the document requires any IANA allocations, authors should take care to check the assignment policy for the relevant namespace, since some assignment policies (e.g., "IETF Consensus") cannot be used by Independent Submissions. See RFC 2434 [RFC2434] for more information.
如果文档需要任何IANA分配，作者应注意检查相关命名空间的分配策略，因为一些分配策略（如“IETF共识”）不能由独立提交使用。有关更多信息，请参阅RFC 2434[RFC2434]。
RFC Editor staff performs an initial check on the document to determine whether there are obvious issues or problems and to decide on the sequencing of other steps.
RFC编辑人员对文档进行初步检查，以确定是否存在明显的问题，并决定其他步骤的顺序。
At any time during the process, the RFC Editor may make general and/or specific suggestions to the author on how to improve the editorial quality of the document and note any specific violations of the rules. The author will be expected to make the suggested updates, submit a new version, and inform the RFC Editor. This may be repeated as often as necessary to obtain an acceptable editorial quality.
在RFC编辑过程中，可能会对任何违反RFC的行为提出具体的建议，以及如何提高RFC编辑的质量。作者应进行建议的更新，提交新版本，并通知RFC编辑。为了获得可接受的编辑质量，可以根据需要重复此操作。
The RFC Editor arranges for one or more reviews of the document. This may include Editorial Board (see Section 6) reviews or reviews by others. Unsolicited reviews from parties independent of the author are welcome at any time.
RFC编辑器安排对文档进行一次或多次审阅。这可能包括编辑委员会（见第6节）的审查或其他人的审查。任何时候都欢迎独立于作者的各方主动提供评论。
At minimum, the author of every document shall receive a written summary of the review(s). Reviewer anonymity is discussed in Section 7. The RFC Editor may also share reviews with the Editorial Board.
每份文件的作者至少应收到审查的书面摘要。第7节讨论了评审员匿名性。RFC编辑也可以与编辑委员会分享评论。
An author rebuttal to some aspect of a review, followed by a healthy technical dialog among the author and the reviewer(s), is fully appropriate. Consensus followed by document revision is the desired outcome.
作者对评论的某些方面进行反驳，然后在作者和评论人之间进行健康的技术对话，这是完全合适的。达成共识后再修订文件是理想的结果。
The RFC Editor is expected to consider all competent reviews carefully, and in the absence of some unusual circumstance, a preponderance of favorable reviews should lead to publication.
RFC编辑器预计会仔细考虑所有合格的评论，并且在没有一些异常情况下，优势评论的优势应该导致出版。
If the author is dissatisfied with one or more review(s), the author may request that the RFC Editor solicit additional reviews. In exceptional circumstances, the author may request that the IAB review the document. Such requests to the IAB, and any reviews the IAB chooses to perform, will occur according to procedures of the IAB's choosing. The IAB is not required to initiate a review or comply with a request for one: a request to the IAB for a review is not an appeal process.
如果作者对一篇或多篇评论不满意，作者可以要求RFC编辑征求更多评论。在特殊情况下，作者可要求IAB审查该文件。对IAB的此类请求以及IAB选择执行的任何审查将根据IAB选择的程序进行。IAB无需启动审查或遵守审查请求：向IAB提出的审查请求不是上诉程序。
If any stage of the review process just described leads to the conclusion that the document is not publishable, the RFC Editor may reject the document. Such rejection would normally be based on the conclusion that the submission does not meet the technical or editorial standards of the RFC Series or is not relevant to the areas that the series covers.
如果上述审查过程的任何阶段导致文件不可发布的结论，RFC编辑可能会拒绝该文件。此类拒绝通常基于以下结论：提交的内容不符合RFC系列的技术或编辑标准，或者与该系列所涵盖的领域无关。
If a document is rejected by the RFC Editor, the author may request an additional review from the IAB, as described below, but the IAB is not obligated to perform that review, nor is the RFC Editor obligated to publish it, even with a favorable IAB review.
如果RFC编辑拒绝了文件，作者可以要求IAB进行额外审查，如下所述，但IAB没有义务进行审查，RFC编辑也没有义务发布该文件，即使IAB进行了有利的审查。
In all cases, the ultimate decision to publish or not publish, and with what text, rests with the RFC Editor.
在所有情况下，发布或不发布以及使用何种文本的最终决定权在于RFC编辑器。
The RFC Editor will communicate the final decision to the author and the Editorial Board. For a rejection, there will be a summary of the reason(s) for the action.
RFC编辑将把最终决定传达给作者和编辑委员会。对于拒绝，将提供行动原因的摘要。
Information about any IESG-requested publication delay or request to not publish a document will be posted to the RFC Editor Web site to supplement document status information.
有关IESG请求发布延迟或请求不发布文档的信息将发布到RFC编辑器网站，以补充文档状态信息。
Once a document is approved for publication, it is handled in a fashion similar to other RFCs, with principles about priorities worked out with the IAB as appropriate.
一旦文件被批准发布，它将以类似于其他RFC的方式进行处理，并酌情与IAB制定优先顺序原则。
At an appropriate time in the review process, normally after the RFC Editor has made a tentative decision to publish, the document is forwarded to the IESG for evaluation with a relatively short timeout. If the nature of the document persuades the RFC Editor or the IESG that the interests of the community or efficiency in the publication process would be better served by a different schedule, then that schedule should be followed. For example, if it appears to the RFC Editor that it is likely that the IESG will wish to take the document over and assign it to a working group, it may be better to ask for the IESG review prior to incurring the delays associated with other reviews or significant editorial work.
在审查过程中的适当时间，通常在RFC编辑做出发布的临时决定后，将文档转发给IESG进行评估，超时时间相对较短。如果文件的性质使RFC编辑或IESG相信，不同的时间表更能满足社区利益或出版过程中的效率，则应遵循该时间表。例如，如果RFC编辑认为IESG可能希望接管该文件并将其分配给一个工作组，则最好在引起与其他审查或重大编辑工作相关的延迟之前，请求IESG审查。
The IESG evaluation is not a technical one. Instead, it covers the issues listed in RFC 3932 [RFC3932] or its successors, presumably from the perspective outlined above in Section 1.2. That is, the evaluation should focus exclusively on conflicts or confusion with IETF process and attempts to subvert ("end run") working group activities.
IESG评估不是技术评估。相反，它涵盖了RFC 3932[RFC3932]或其继任者中列出的问题，可能是从上述第1.2节中概述的角度出发。也就是说，评估应专门关注与IETF过程的冲突或混淆，以及颠覆（“结束运行”）工作组活动的企图。
At the time the document is forwarded to the IESG, the RFC Editor posts an indication on its Web site that the document is under IESG review and that comments on conflicts can be sent to the IESG with
在将文件转发给IESG时，RFC编辑在其网站上发布一条指示，表明该文件正在IESG审查中，有关冲突的评论可通过以下方式发送给IESG：
copies to the RFC Editor. Additional mechanisms may be developed from time to time to inform a community that a document is entering formal prepublication review. Comments not directly related to IETF procedures or conflicts may be sent directly to the author(s) and RFC Editor.
复制到RFC编辑器。可能会不时开发其他机制，以告知社区文件正在进入正式的出版前审查。与IETF程序或冲突不直接相关的评论可直接发送给作者和RFC编辑。
In addition to the IESG review for conflict with IETF work, individuals in the IESG or in the broader IETF community are free to review a draft and, if they have comments of any kind --including the extreme case of believing that the proposal is damaging to the Internet as a whole-- these comments should be directed to the author(s) and the RFC Editor.
除了IESG审查与IETF工作的冲突外，IESG或更广泛的IETF社区中的个人可以自由审查草案，如果他们有任何意见，包括认为提案对整个互联网造成损害的极端情况，这些意见应直接提交给作者和RFC编辑器。
If the IESG, after completing its review, identifies issues, it may recommend explanatory or qualifying text for the RFC Editor to include in the document if it is published.
如果IESG在完成审查后发现了问题，则可能会建议RFC编辑器在文件中包含解释性或限定性文本（如果已发布）。
If the IESG concludes that publication of the document should be delayed for a reasonable period of time because its untimely publication could cause confusion or other harm with proposals under consideration for standardization, the RFC Editor will grant that request. The current agreement between the RFC Editor and the IESG on requested delays is expected to continue. That agreement permits the IESG to ask for a delay of up to six months and, if necessary, to renew that request twice, for a total possible delay of 18 months.
如果IESG认为文件的发布应推迟一段合理的时间，因为其发布不及时可能会导致与正在考虑的标准化提案的混淆或其他损害，RFC编辑将批准该请求。RFC编辑和IESG之间关于请求延迟的当前协议预计将继续。该协议允许IESG请求最多6个月的延迟，如有必要，可将该请求延长两次，总共可能延迟18个月。
If the IESG concludes that the document should not be published as an RFC, it will request that the RFC Editor not publish and provide appropriate justification for that request. The RFC Editor will consider the request to not publish the document.
如果IESG认为该文件不应作为RFC发布，它将要求RFC编辑不发布，并为该请求提供适当的理由。RFC编辑器将考虑不发布文档的请求。
The RFC Editor or the author may request that the IAB review the IESG's request to delay or not publish the document and request that the IAB provide an additional opinion. Such a request will be made public via the RFC Editor Web site. As with the IESG review itself, the IAB's opinion, if any, will be advisory. And, as with author requests for an IAB technical review (see Section 4.5), the IAB is not obligated to perform this type of review and may decline the request.
RFC编辑或作者可要求IAB审查IESG延迟或不发布文件的请求，并要求IAB提供补充意见。此类请求将通过RFC编辑器网站公开。与IESG审查本身一样，IAB的意见（如有）将是咨询性的。而且，与作者提出的IAB技术审查请求一样（见第4.5节），IAB没有义务进行此类审查，可能会拒绝该请求。
The RFC Editor appoints and maintains the Editorial Review Board, which, much like the editorial boards of professional journals and publishers, provides the RFC Editor with both advice and reviews of particular proposed publications and general and strategic policy advice. The membership list of the Editorial Review Board is public and can be found at http://www.rfc-editor.org/edboard.html.
RFC编辑任命并维护编辑评审委员会，该委员会与专业期刊和出版商的编辑委员会非常相似，为RFC编辑提供建议和对特定拟定出版物的评审以及一般和战略政策建议。编辑评审委员会的成员名单是公开的，可以在http://www.rfc-editor.org/edboard.html.
Editorial Board members serve at the pleasure of the RFC Editor. From time to time, the RFC Editor will solicit suggestions for new appointees from the IAB and other sources and will seek IAB comments on those to be appointed. The RFC Editor will also solicit IAB comments on the effectiveness of the review process and the quality of documents being published and criteria applied. However, to ensure the independence of the Independent Submission process, the final decision to appoint (or not appoint) Editorial Board members rests with the RFC Editor.
编辑委员会成员的服务是RFC编辑的荣幸。RFC编辑将不时征求IAB和其他来源对新任命人员的建议，并征求IAB对拟任命人员的意见。RFC编辑还将征求IAB对审查过程的有效性、所发布文件的质量以及所采用标准的意见。然而，为了确保独立提交过程的独立性，任命（或不任命）编辑委员会成员的最终决定权在于RFC编辑。
The RFC Editor will conduct the reviews discussed above with the intent of balancing fairness to authors, transparency of the review process to the general community, protection of reviewers from possible retaliation or undue pressure, and the interest of the community in having any significant dissents from published documents available to the community with the same degree of scrutiny that the original documents received. To this end, reviews and information about reviewers will be made public under the following circumstances. In special cases in which other considerations apply, the RFC Editor may adopt special provisions after reviewing the circumstances and proposed action with the IAB.
RFC编辑将进行上述审查，目的是平衡对作者的公平性、审查过程对一般社区的透明度、保护审查人员免受可能的报复或不当压力，以及社区的利益，即通过与原始文件相同的审查程度，向社区提供对已发布文件的任何重大异议。为此，在下列情况下，将公开审查和有关审查员的信息。在其他考虑因素适用的特殊情况下，RFC编辑可在与IAB审查情况和拟议行动后采用特殊规定。
Any reviewer participating in the process outlined in this document does so on the condition of giving consent to handling of the reviews as outlined in this section. In special cases, individual arrangements may be worked out in advance with the RFC Editor.
参与本文件所述过程的任何审查员均须同意处理本节所述审查。在特殊情况下，可以提前与RFC编辑制定单独的安排。
As described in Section 4.4, all reviews will be shared with the document authors (with possible editing to remove any extreme language). The names of the reviewers will normally accompany these reviews, but reviewers will be granted anonymity upon request to the RFC Editor. The RFC Editor will in any case forward any author rebuttal messages to the reviewer.
如第4.4节所述，所有审查将与文件作者共享（可能进行编辑以删除任何极端语言）。评审员的姓名通常会随这些评审一起提供，但在RFC编辑要求时，评审员将被授予匿名权。RFC编辑在任何情况下都会将任何作者反驳信息转发给评审员。
Nothing in this section or the subsections below precludes private communications between reviewers, the Editorial Board, and the RFC Editor; such communications will remain confidential.
本节或以下小节中的任何内容均不排除审稿人、编辑委员会和RFC编辑之间的私人沟通；此类通信将保持机密。
Once a final accept or reject decision has been made on a document, the RFC Editor may choose to post the full set of reviews (and author rebuttals, if any) associated with a document, if doing so would be in the best interest of the community. The author may request earlier posting of reviews and rebuttals, to inspire additional unsolicited reviews, for example. The names of the reviewers will
一旦对文档做出最终接受或拒绝决定，RFC编辑可以选择发布与文档相关的全套评论（以及作者反驳，如果有的话），如果这样做符合社区的最佳利益。例如，作者可能会要求提前发布评论和反驳，以激发更多未经请求的评论。评审员的姓名将被删除
accompany their reviews, except for a reviewer who requested anonymity.
随同他们的评论，但要求匿名的评论人除外。
The author will be notified in advance of the intent to post the final reviews. The author may then request that the document be withdrawn and the reviews kept private. However, such an author request must be timely, generally within 14 days of the notification of intent to post.
将提前通知作者发布最终评论的意图。然后，作者可以要求撤回该文件，并将审查保密。但是，此类作者请求必须及时，通常在发布意向通知后的14天内。
If the RFC Editor rejects a document, the author has the following options for recourse.
如果RFC编辑器拒绝文档，则作者有以下追索选项。
o Request one or more additional reviews (Section 4.5) followed by a reconsideration.
o 要求进行一次或多次附加审查（第4.5节），然后进行重新审议。
o Request an IAB review (Section 4.5, Section 4.6) followed by a reconsideration.
o 请求IAB审查（第4.5节，第4.6节），然后重新考虑。
o Request that the reviews be published on the RFC Editor Web site.
o 要求在RFC编辑器网站上发布评论。
In considering whether to make review materials public for documents
accepted for publication, the RFC Editor is expected to note that the
best way to comment on or dissent from an RFC is generally another
RFC; that reviews critical of a document are not themselves reviewed;
that the review and refutation process is necessarily fragmentary;
and that a reviewer who feels strongly about a subject about which a
review has already been written often would not need to do
significant additional work to produce an RFC-format document from
that review.
In considering whether to make review materials public for documents
accepted for publication, the RFC Editor is expected to note that the
best way to comment on or dissent from an RFC is generally another
RFC; that reviews critical of a document are not themselves reviewed;
that the review and refutation process is necessarily fragmentary;
and that a reviewer who feels strongly about a subject about which a
review has already been written often would not need to do
significant additional work to produce an RFC-format document from
that review.
The following material was extracted from the relevant sections of BCP 78 [RFC3978] [RFC4748] in order to get all Independent Submission information for technical publications produced under the auspices of the IETF, the IETF Administrative Support Activity (IASA) or the IETF Trust, or the Internet Society (ISOC) into a single place and to initialize the process of separating discussions of Independent Submissions from those about Standards-Track or other IETF documents. Note that the text that follows uses the term "RFC Editor Contribution" to describe the same type of document referred to as an "Independent Submission" elsewhere in this document. The RFC Editor
以下材料摘自BCP 78[RFC3978][RFC4748]的相关章节，以获取IETF、IETF行政支持活动（IASA）或IETF信托基金或互联网协会（ISOC）赞助下编制的技术出版物的所有独立提交信息将独立提交的讨论与关于标准跟踪或其他IETF文件的讨论分开的过程初始化。请注意，以下文本使用术语“RFC编辑器贡献”来描述本文件其他地方称为“独立提交”的同一类型的文件。RFC编辑器
may change these provisions from time to time after obtaining the advice and consent of the IETF Trust in the RFC Editor's capacity as the formal publisher of RFCs.
在获得IETF信托基金的建议和同意后，RFC编辑可以作为RFC的正式出版商，不时修改这些规定。
By submission of an RFC Editor Contribution, each person actually submitting the RFC Editor Contribution, and each named co-Contributor, is deemed to agree to the following terms and conditions, and to grant the following rights, on his or her own behalf and on behalf of the organization the Contributor represents or is sponsored by (if any) when submitting the RFC Editor Contribution.
通过提交RFC编辑贡献，实际提交RFC编辑贡献的每个人和每个指定的共同贡献者被视为同意以下条款和条件，并代表其本人和贡献者所代表或赞助的组织（如有）授予以下权利提交RFC编辑器贡献时。
a. For Internet-Drafts that are expected to be submitted as RFC Editor Contributions: To the extent that an RFC Editor Contribution or any portion thereof is protected by copyright and other rights of authorship, the Contributor, and each named co-Contributor, and the organization he or she represents or is sponsored by (if any) grant an irrevocable, non-exclusive, royalty-free, world-wide right and license to the IETF Trust and the IETF under all intellectual property rights in the RFC Editor Contribution for at least the life of the Internet-Draft, to copy, publish, display, and distribute the RFC Editor Contribution as an Internet-Draft.
a. 对于预期作为RFC编辑贡献提交的互联网草稿：在RFC编辑贡献或其任何部分受版权和其他作者权利保护的情况下，贡献者和每个指定的共同贡献者，以及他或她所代表或赞助的组织（如有）授予不可撤销的授权，根据RFC编辑器贡献中的所有知识产权，IETF信托基金和IETF拥有非排他性、免版税的全球权利和许可，至少在互联网草稿的整个生命周期内，以互联网草稿的形式复制、发布、显示和分发RFC编辑器贡献。
b. For an RFC Editor Contribution submitted for publication as an RFC, and to the extent described above, the Contributor, each named co-Contributor, and the organizations represented above grant the same license to those organizations and to the community as a whole to copy, publish, display, and distribute the RFC Editor Contribution irrevocably and in perpetuity and, also irrevocably and in perpetuity, grant the rights listed below to those organizations and entities and to the community:
b. 对于作为RFC提交发布的RFC编辑器贡献，在上述范围内，贡献者、每个指定的共同贡献者和上述代表的组织向这些组织和整个社区授予相同的许可证，以复制、发布、显示，并不可撤销地和永久地分发RFC编辑器贡献，同时也不可撤销地和永久地将下列权利授予这些组织和实体以及社区：
A. to prepare or allow the preparation of translations of the RFC into languages other than English,
A.准备或允许准备将RFC翻译成英语以外的语言，
B. unless explicitly disallowed in the notices contained in an RFC Editor Contribution, to prepare derivative works (other than translations) that are based on or incorporate all or part of the RFC Editor Contribution, or comment upon it. The license to such derivative works shall not grant the IETF Trust, the IETF, or other party preparing a derivative work any more rights than the license to the original RFC Editor Contribution, and
B.除非RFC编辑贡献中包含的通知明确禁止，否则准备基于或包含全部或部分RFC编辑贡献的衍生作品（翻译除外），或对其进行评论。此类衍生作品的许可不得授予IETF信托、IETF或其他准备衍生作品的一方比原始RFC编辑器贡献的许可更多的权利，以及
C. to reproduce any trademarks, service marks, or trade names that are included in the RFC Editor Contribution solely in connection with the reproduction, distribution, or
C.复制RFC编辑器贡献中包含的任何商标、服务标志或商号，仅与复制、分发或
publication of the RFC Editor Contribution and derivative works thereof as permitted by this paragraph. Any entity reproducing RFC Editor Contributions will, as a condition of permission of such reproduction, preserve trademark and service mark identifiers used by the Contributor of the RFC Editor Contribution, including (TM) and (R) where appropriate.
出版本段允许的RFC编辑贡献及其衍生作品。任何复制RFC编辑器贡献的实体将保留RFC编辑器贡献贡献者使用的商标和服务标记标识符，包括（TM）和（R）（如适用），作为允许此类复制的条件。
D. The Contributor grants the IETF Trust and the IETF, permission to reference the name(s) and address(es) of the Contributor(s) and of the organization(s) s/he represents or is sponsored by (if any).
D.贡献者授予IETF信托和IETF引用贡献者和其代表或赞助的组织（如有）的名称和地址的权限。
This document specifies an RFC Editor (and, indirectly, IETF) administrative and publication procedure. It has no specific security implications.
本文件规定了RFC编辑器（以及间接的IETF）管理和发布程序。它没有具体的安全含义。
Special thanks are due to Bob Hinden and Craig Partridge, who made several suggestions for improved text in earlier versions of this document, and to Stewart Bryant, Scott Bradner, Brian Carpenter, Vint Cerf, Leslie Daigle, and Olaf Kolkman, who made a number of useful suggestions about the organization and content of subsequent versions. We also express our appreciation to the IETF and Scott Bradner, Editor, for the material extracted from BCP 78 [RFC3978] and used in Section 8.
特别感谢Bob Hinden和Craig Partridge，他们为改进本文档早期版本的文本提出了一些建议，并感谢Stewart Bryant、Scott Bradner、Brian Carpenter、Vint Cerf、Leslie Daigle和Olaf Kolkman，他们对后续版本的组织和内容提出了许多有用的建议。我们还感谢IETF和编辑Scott Bradner从BCP 78[RFC3978]中提取并在第8节中使用的材料。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997.
[RFC2223]Postel，J.和J.Reynolds，“RFC作者须知”，RFC 2223，1997年10月。
[RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents: Procedures", BCP 92, RFC 3932, October 2004.
[RFC3932]Alvestrand，H.，“IESG和RFC编辑文件：程序”，BCP 92，RFC 3932，2004年10月。
[RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3978, March 2005.
[RFC3978]Bradner，S.，“IETF在贡献中的权利”，BCP 78，RFC 3978，2005年3月。
[RFC4748] Bradner, S., "RFC 3978 Update to Recognize the IETF Trust", BCP 78, RFC 4748, October 2006.
[RFC4748]Bradner，S.，“RFC 3978更新以确认IETF信任”，BCP 78，RFC 4748，2006年10月。
[IEN137] Cohen, D., "On Holy Wars and a Plea for Peace", IEN 137, April 1980, <ftp://ftp.rfc-editor.org/in-notes/ien/ien137.txt>.
[IEN137]Cohen，D.，“关于圣战和和平的呼吁”，IEN137，1980年4月<ftp://ftp.rfc-editor.org/in-notes/ien/ien137.txt>.
[RFC0021] Cerf, V., "Network meeting", RFC 21, October 1969.
[RFC0021]Cerf，V.，“网络会议”，RFC 21，1969年10月。
[RFC1109] Cerf, V., "Report of the second Ad Hoc Network Management Review Group", RFC 1109, August 1989.
[RFC1109]Cerf，V.，“第二特设网络管理审查小组的报告”，RFC1109，1989年8月。
[RFC1591] Postel, J., "Domain Name System Structure and Delegation", RFC 1591, March 1994.
[RFC1591]Postel，J.，“域名系统结构和授权”，RFC15911994年3月。
[RFC1810] Touch, J., "Report on MD5 Performance", RFC 1810, June 1995.
[RFC1810]Touch，J.，“MD5性能报告”，RFC1810，1995年6月。
[RFC2223BIS] Reynolds, J., Ed. and R. Braden, Ed., "Instructions to Request for Comments (RFC) Authors", Work in Progress, August 2004.
[RFC2223BIS]Reynolds，J.，Ed.和R.Braden，Ed.，“征求意见（RFC）作者的说明”，正在进行的工作，2004年8月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[RFC2441] Cohen, D., "Working with Jon Tribute delivered at UCLA, October 30, 1998", RFC 2441, November 1998.
[RFC2441]Cohen，D.，“与Jon一起在加州大学洛杉矶分校工作，1998年10月30日”，RFC 24411998年11月。
[RFC2555] Braden, R., Reynolds, J., Crocker, S., Cerf, V., Feinler, J., and C. Anderson, "30 Years of RFCs", RFC 2555, April 1999.
[RFC2555]Braden，R.，Reynolds，J.，Crocker，S.，Cerf，V.，Feinler，J.，和C.Anderson，“RFC的30年”，RFC 25551999年4月。
[RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority", RFC 2860, June 2000.
[RFC2860]Carpenter，B.，Baker，F.和M.Roberts，“关于互联网分配号码管理局技术工作的谅解备忘录”，RFC 28602000年6月。
[RFC4714] Mankin, A. and S. Hayes, "Requirements for IETF Technical Publication Service", RFC 4714, October 2006.
[RFC4714]Mankin，A.和S.Hayes，“IETF技术出版服务的要求”，RFC 4714，2006年10月。
[RFC4844] Daigle, L., Ed. and IAB, "The RFC Series and RFC Editor", RFC 4844, July 2007.
[RFC4844]Daigle，L.，Ed.和IAB，“RFC系列和RFC编辑器”，RFC 48442007年7月。
Bernard Aboba Loa Andersson Brian Carpenter Leslie Daigle Elwyn Davies Kevin Fall Olaf Kolkman Kurtis Lindqvist David Meyer David Oran Eric Rescorla Dave Thaler Lixia Zhang
Bernard Aboba Loa Andersson Brian Carpenter Leslie Daigle Elwyn Davies Kevin Fall Olaf Kolkman Kurtis Lindqvist David Meyer David Oran Eric Rescorla Dave Thaler Lixia Zhang
Authors' Addresses
作者地址
John C Klensin (editor) 1770 Massachusetts Ave, #322 Cambridge, MA 02140 USA
美国马萨诸塞州剑桥322号马萨诸塞大道1770号约翰·C·克伦星（编辑），邮编：02140
Phone: +1 617 491 5735
EMail: john-ietf@jck.com
Phone: +1 617 491 5735
EMail: john-ietf@jck.com
Dave Thaler (editor) One Microsoft Way Redmond, WA 98052 USA
Dave Thaler（编辑）美国华盛顿州雷德蒙微软一路98052号
Phone: +1 425 703 8835
EMail: dthaler@microsoft.com
Phone: +1 425 703 8835
EMail: dthaler@microsoft.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
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, THE IETF TRUST 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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 currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。