Network Working Group H. Alvestrand
Request for Comments: 3932 October 2004
BCP: 92
Updates: 3710, 2026
Category: Best Current Practice
Network Working Group H. Alvestrand
Request for Comments: 3932 October 2004
BCP: 92
Updates: 3710, 2026
Category: Best Current Practice
The IESG and RFC Editor Documents: Procedures
IESG和RFC编辑器文档：过程
Status of this Memo
本备忘录的状况
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
本文件规定了互联网社区的最佳现行做法，并要求进行讨论和提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
This document describes the IESG's procedures for handling documents submitted for RFC publication via the RFC Editor, subsequent to the changes proposed by the IESG at the Seoul IETF, March 2004.
本文件描述了IESG在2004年3月首尔IETF上提出变更后，处理通过RFC编辑器提交RFC发布的文件的程序。
This document updates procedures described in RFC 2026 and RFC 3710.
本文件更新了RFC 2026和RFC 3710中描述的程序。
There are a number of different methods by which an RFC is published, some of which include review in the Internet Engineering Task Force (IETF), and some of which include approval by the Internet Engineering Steering Group (IESG):
发布RFC有许多不同的方法，其中一些包括互联网工程任务组（IETF）的审查，一些包括互联网工程指导小组（IESG）的批准：
o IETF Working Group (WG) to Standards Track: Includes WG consensus, review in the IETF, IETF Last Call, and IESG approval
o IETF工作组（WG）对标准的跟踪：包括工作组共识、IETF中的审查、IETF最后一次呼叫和IESG批准
o IETF WG to Experimental/Informational: Includes WG consensus, review in the IETF, and IESG approval
o IETF工作组到实验/信息：包括工作组共识、IETF审查和IESG批准
o Area Director (AD) sponsored to Standards Track: Includes review in the IETF, IETF Last Call, and IESG approval
o 赞助标准跟踪的区域主管（AD）：包括IETF中的审查、IETF最后一次呼叫和IESG批准
o AD Sponsored Individual to Experimental/Informational: Includes some form of review in the IETF and IESG approval
o 广告赞助个人到实验/信息：在IETF和IESG批准中包括某种形式的审查
o Documents for which special rules exist
o 存在特殊规则的文件
o RFC Editor documents to Experimental/Informational
o RFC编辑器文档到实验/信息
This memo is only concerned with the IESG processing of the last category.
本备忘录仅涉及最后一个类别的IESG处理。
Special rules apply to some documents, including documents from the Internet Architecture Board (IAB), April 1st RFCs, and republication of documents from other standards development organizations. The IESG and the RFC Editor keep a running dialogue, in consultation with the IAB, on these other documents and their classification, but they are outside the scope of this memo.
特殊规则适用于某些文件，包括来自互联网体系结构委员会（IAB）的文件、4月1日的RFC以及来自其他标准开发组织的文件的重新发布。IESG和RFC编辑与IAB协商，就这些其他文件及其分类保持持续对话，但它们不在本备忘录的范围内。
For the last few years, the IESG has reviewed all RFC Editor documents (documents submitted by individuals to the RFC Editor for RFC publication) before publication. In 2003, this review was often a full-scale review of technical content, with the ADs attempting to clear points with the authors, stimulate revisions of the documents, encourage the authors to contact appropriate working groups and so on. This was a considerable drain on the resources of the IESG, and since this is not the highest priority task of the IESG members, it often resulted in significant delays.
在过去几年中，IESG在出版前审查了所有RFC编辑文件（个人提交给RFC编辑进行RFC出版的文件）。2003年，这一审查通常是对技术内容的全面审查，广告试图与作者澄清观点，鼓励修改文件，鼓励作者联系适当的工作组等等。这对IESG的资源造成了相当大的消耗，而且由于这不是IESG成员的最高优先任务，因此常常导致重大延误。
In March 2004, the IESG decided to make a major change in this review model. The new review model will have the IESG take responsibility ONLY for checking for conflicts between the work of the IETF and the documents submitted; soliciting technical review is deemed to be the responsibility of the RFC Editor. If an individual IESG member chooses to review the technical content of the document and finds issues, that member will communicate these issues to the RFC Editor, and they will be treated the same way as comments on the documents from other sources.
2004年3月，IESG决定对这一审查模式进行重大修改。新的审查模式将使IESG仅负责检查IETF工作与提交文件之间的冲突；征求技术审查被视为RFC编辑的责任。如果个别IESG成员选择审查文件的技术内容并发现问题，该成员将向RFC编辑传达这些问题，并将以与其他来源的文件评论相同的方式处理这些问题。
Note: This document describes only the review process done by the IESG when the RFC Editor requests that review. There are many other interactions between document editors and the IESG for instance, an AD may suggest that an author submit a document as input for work within the IETF rather than to the RFC Editor, or the IESG may suggest that a document submitted to the IETF is better suited for submission to the RFC Editor but these interactions are not described in this memo.
注：本文档仅描述了当RFC编辑器请求审查时，IESG完成的审查过程。文档编辑器和IESG之间还有许多其他交互。例如，广告可能建议作者提交文档作为IETF内工作的输入，而不是RFC编辑器，或者IESG可能建议提交给IETF的文件更适合提交给RFC编辑，但本备忘录中未描述这些交互。
The review of independent submissions by the IESG was prescribed by RFC 2026 [1] section 4.2.3. The procedure described in this document is compatible with that description.
RFC 2026[1]第4.2.3节规定了IESG对独立提交文件的审查。本文件中描述的程序与该说明一致。
RFC 3710 [4] section 5.2.2 describes the spring 2003 review process (even though the RFC was published in 2004); with the publication of this document, the procedure described in RFC 3710 is no longer relevant to documents submitted via the RFC Editor.
RFC 3710[4]第5.2.2节描述了2003年春季审查过程（尽管RFC于2004年发布）；随着本文件的发布，RFC 3710中描述的程序不再适用于通过RFC编辑器提交的文件。
The RFC Editor reviews submissions for suitability for publications as RFC. Once the RFC Editor thinks a document may be suited for RFC publication, the RFC Editor asks the IESG to review the documents for conflicts with the IETF standards process or work done in the IETF community.
RFC编辑审查提交的出版物是否适合RFC。一旦RFC编辑认为某个文档适合RFC发布，RFC编辑会要求IESG审查该文档是否与IETF标准流程或IETF社区中完成的工作存在冲突。
The review is initiated by a note from the RFC Editor specifying the document name, the RFC Editor's belief about the document's present suitability for publication, and (if possible) the list of people who have reviewed the document for the RFC Editor.
评审由RFC编辑的注释发起，说明文件名称、RFC编辑对文件目前是否适合出版的看法，以及（如果可能）为RFC编辑评审过文件的人员名单。
The IESG may return five different responses, any of which may be accompanied by an IESG note to be put on the document if the RFC Editor wishes to publish.
IESG可能会返回五种不同的回复，如果RFC编辑希望发布，其中任何一种回复都可能附有一份IESG注释，放在文档上。
1. The IESG has not found any conflict between this document and IETF work.
1. IESG未发现本文件与IETF工作之间存在任何冲突。
2. The IESG thinks that this work is related to IETF work done in WG <X>, but this does not prevent publishing.
2. IESG认为这项工作与在WG<X>中完成的IETF工作有关，但这并不妨碍发布。
3. The IESG thinks that publication is harmful to the IETF work done in WG <X> and recommends not publishing the document at this time.
3. IESG认为发布对在WG<X>中完成的IETF工作有害，建议此时不要发布该文件。
4. The IESG thinks that this document violates IETF procedures for <X> and should therefore not be published without IETF review and IESG approval.
4. IESG认为本文件违反了IETF的<X>程序，因此未经IETF审查和IESG批准，不得发布。
5. The IESG thinks that this document extends an IETF protocol in a way that requires IETF review and should therefore not be published without IETF review and IESG approval.
5. IESG认为，本文件以需要IETF审查的方式扩展IETF协议，因此未经IETF审查和IESG批准，不得发布。
The last two responses are included respectively, for the case where a document attempts to take actions (such as registering a new URI scheme) that require IETF consensus or IESG approval (as these terms are defined in RFC 2434 [2]), and for the case where an IETF protocol is proposed to be changed or extended in an unanticipated way that may be harmful to the normal usage of the protocol, but where the protocol documents do not explicitly say that this type of extension requires IETF review.
对于文件试图采取需要IETF协商一致或IESG批准（如RFC 2434[2]中定义的这些术语）的行动（如注册新的URI方案）的情况，分别包括最后两个响应，对于提议以可能有害于协议正常使用的意外方式更改或扩展IETF协议的情况，但协议文件未明确说明此类扩展需要IETF审查。
If a document requires IETF review, the IESG will offer the author the opportunity to ask for publication as an AD-sponsored individual document, which is subject to full IESG review, including possible assignment to a WG or rejection. Redirection to the full IESG review path is not a guarantee that the IESG will accept the work item, or even that the IESG will give it any particular priority; it is a guarantee that the IESG will consider the document.
如果文件需要IETF审查，IESG将为作者提供机会，要求将其作为广告赞助的个人文件出版，该文件需接受IESG的全面审查，包括可能指派给工作组或拒绝。重新定向到完整的IESG审查路径并不能保证IESG会接受工作项，甚至不能保证IESG会给予它任何特定的优先级；这是IESG将考虑该文件的保证。
The IESG will normally have review done within 4 weeks from the RFC Editor's notification. In the case of a possible conflict, the IESG may contact a WG or a WG chair for an outside opinion of whether publishing the document is harmful to the work of the WG and, in the case of a possible conflict with an IANA registration procedure, the IANA expert for that registry.
IESG通常会在收到RFC编辑通知后的4周内进行审查。在可能发生冲突的情况下，IESG可联系工作组或工作组主席，征求外界对发布文件是否有害于工作组工作的意见，如果可能与IANA注册程序发生冲突，则可联系该注册处的IANA专家。
Note that if the IESG has not found any conflict between a submission and IETF work, then judging its technical merits, including considerations of possible harm to the Internet, will become the responsibility of the RFC Editor. The IESG assumes that the RFC Editor, in agreement with the IAB, will manage mechanisms for additional technical review.
请注意，如果IESG未发现提交与IETF工作之间存在任何冲突，则RFC编辑应负责判断其技术优点，包括对互联网可能造成的危害的考虑。IESG假设RFC编辑在与IAB达成一致的情况下，将管理额外技术审查的机制。
One of the following IESG notes will be sent to the RFC Editor for all documents, with a request for placement either in or immediately following the "Status of this Memo" section of the finished RFC, unless the IESG decides otherwise:
除非IESG另有决定，否则将向RFC编辑发送以下IESG注释之一，并请求将其放置在已完成RFC的“本备忘录状态”部分中或紧随其后：
1. For documents that specify a protocol or other technology, and that have been considered in the IETF at one time:
1. 对于指定协议或其他技术的文件，以及曾在IETF中考虑过的文件：
The content of this RFC was at one time considered by the IETF, and therefore it may resemble a current IETF work in progress or a published IETF work. This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this RFC should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information.
IETF曾考虑过本RFC的内容，因此它可能类似于当前正在进行的IETF工作或已发布的IETF工作。本RFC不适用于任何级别的互联网标准。IETF不承认本RFC适用于任何目的的任何知识，特别注意到，发布决定并非基于IETF对安全、拥塞控制或与已部署协议的不当交互等事项的审查。RFC编辑已自行决定发布本文件。本RFC的读者应谨慎评估其实施和部署价值。有关更多信息，请参阅RFC 3932。
2. For documents that specify a protocol or similar technology and are independent of the IETF process:
2. 对于指定协议或类似技术且独立于IETF流程的文件：
This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information.
本RFC不适用于任何级别的互联网标准。IETF不承认本RFC适用于任何目的的任何知识，特别注意到，发布决定并非基于IETF对安全、拥塞控制或与已部署协议的不当交互等事项的审查。RFC编辑已自行决定发布本文件。本文档的读者在评估其实施和部署价值时应谨慎。有关更多信息，请参阅RFC 3932。
3. For documents that do not specify a protocol or similar technology:
3. 对于未指定协议或类似技术的文件：
This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and notes that the decision to publish is not based on IETF review apart from IESG review for conflict with IETF work. The RFC Editor has chosen to publish this document at its discretion. See RFC 3932 for more information.
本RFC不适用于任何级别的互联网标准。IETF不承认任何关于本RFC适用于任何目的的知识，并指出，除了IESG审查与IETF工作的冲突外，发布决定并非基于IETF审查。RFC编辑已自行决定发布本文件。有关更多信息，请参阅RFC 3932。
This section gives a couple of examples where delaying or preventing publication of a document might be appropriate due to conflict with IETF work. It forms part of the background material, not a part of the procedure.
本节给出了几个示例，其中由于与IETF工作冲突，延迟或阻止文档的发布可能是适当的。它是背景材料的一部分，而不是程序的一部分。
Rejected Alternative Bypass: A WG is working on a solution to a problem, and a participant decides to ask for publication of a solution that the WG has rejected. Publication of the document will give the publishing party an RFC number to refer to before the WG is finished. It seems better to have the WG product published first, and have the non-adopted document published later, with a clear disclaimer note saying that "the IETF technology for this function is X".
拒绝替代旁路：工作组正在研究问题的解决方案，参与者决定要求发布工作组拒绝的解决方案。文件的发布将为发布方提供一个RFC编号，以便在工作组完成之前参考。最好先发布工作组产品，然后再发布未采用的文档，并附上明确的免责声明，声明“用于此功能的IETF技术是X”。
Example: Photuris (RFC 2522), which was published after IKE (RFC 2409).
例如：Photuris（RFC 2522），在IKE（RFC 2409）之后出版。
Inappropriate Reuse of "free" Bits: In 2003, a proposal for an experimental RFC was published that wanted to reuse the high bits of the "fragment offset" part of the IP header for another purpose. No IANA consideration says how these bits can be repurposed, but the standard defines a specific meaning for them. The IESG concluded
不适当地重用“空闲”位：2003年，发表了一份关于实验性RFC的提案，该提案希望将IP报头“片段偏移”部分的高位用于其他目的。IANA没有考虑这些位的用途，但该标准为它们定义了特定的含义。IESG得出结论
that implementations of this experiment risked causing hard-to-debug interoperability problems and recommended not publishing the document in the RFC series. The RFC Editor accepted the recommendation.
该实验的实现有可能导致难以调试的互操作性问题，建议不要在RFC系列中发布该文档。RFC编辑接受了这一建议。
Note: in general, the IESG has no problem with rejected alternatives being made available to the community; such publications can be a valuable contribution to the technical literature. However, it is necessary to avoid confusion with the alternatives the working group did adopt.
注：一般来说，IESG对向社区提供被拒绝的替代品没有问题；这些出版物可以对技术文献作出有价值的贡献。然而，有必要避免与工作组确实采用的备选方案相混淆。
The RFC series is one of many available publication channels; this document takes no position on the question of which documents the RFC series is appropriate for. That is a matter for discussion in the IETF community.
RFC系列是许多可用的出版渠道之一；本文件不涉及RFC系列适用于哪些文件的问题。这是IETF社区讨论的问题。
In its capacity as the body that approves the general policy followed by the RFC Editor (see RFC 2850 [3]), the IAB has reviewed this proposal and supports it as an operational change that is in line with the respective roles of the IESG and RFC Editor. The IAB continues to monitor the range of organized discussions within the IETF about potential adjustments to the IETF document publication processes (e.g., NEWTRK working group) and recognizes that the process described in this document, as well as other general IETF publication processes, may need to be adjusted in the light of the outcome of those discussions.
作为批准RFC编辑遵循的一般政策的机构（见RFC 2850[3]），IAB审查了该提案，并将其作为符合IESG和RFC编辑各自角色的运营变更予以支持。IAB继续监控IETF内部关于IETF文件发布流程（如NEWTRK工作组）潜在调整的有组织讨论范围，并认识到本文件中描述的流程以及其他一般IETF发布流程，可能需要根据这些讨论的结果进行调整。
The process change described in this memo has no direct bearing on the security of the Internet.
本备忘录中描述的流程变更与互联网安全没有直接关系。
This document is a product of the IESG, and all its members deserve thanks for their contributions.
本文件是IESG的产品，其所有成员的贡献值得感谢。
This document has been reviewed in the IETF and by the RFC Editor and the IAB; the IAB produced the text of section 6. Special thanks go to John Klensin, Keith Moore, Pete Resnick, Scott Bradner, Kurt Zeilenga, Eliot Lear, Paul Hoffman, Brian Carpenter, and all other IETF community members who provided valuable feedback on the document.
本文件已由IETF、RFC编辑和IAB审查；IAB提供了第6节的文本。特别感谢John Klensin、Keith Moore、Pete Resnick、Scott Bradner、Kurt Zeilenga、Eliot Lear、Paul Hoffman、Brian Carpenter和所有其他IETF社区成员，他们对该文件提供了宝贵的反馈。
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[1] Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[2] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[3] Internet Architecture Board and B. Carpenter, Ed., "Charter of the Internet Architecture Board (IAB)", BCP 39, RFC 2850, May 2000.
[3] 互联网架构委员会和B.Carpenter，Ed.，“互联网架构委员会（IAB）章程”，BCP 39，RFC 2850，2000年5月。
[4] Alvestrand, H., "An IESG charter", RFC 3710, February 2004.
[4] Alvestrand，H.，“IESG宪章”，RFC 3710，2004年2月。
Author's Address
作者地址
Harald Alvestrand
哈拉尔·阿尔韦斯特兰
EMail: harald@alvestrand.no
EMail: harald@alvestrand.no
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
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 IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关IETF文件中权利的IETF程序信息，请参见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编辑功能的资金目前由互联网协会提供。