Internet Engineering Task Force (IETF) H. Alvestrand
Request for Comments: 5742 Google
BCP: 92 R. Housley
Obsoletes: 3932 Vigil Security
Updates: 2026, 3710 December 2009
Category: Best Current Practice
ISSN: 2070-1721
Internet Engineering Task Force (IETF) H. Alvestrand
Request for Comments: 5742 Google
BCP: 92 R. Housley
Obsoletes: 3932 Vigil Security
Updates: 2026, 3710 December 2009
Category: Best Current Practice
ISSN: 2070-1721
IESG Procedures for Handling of Independent and IRTF Stream Submissions
IESG处理独立和IRTF流提交的程序
Abstract
摘要
This document describes the procedures used by the IESG for handling documents submitted for RFC publication from the Independent Submission and IRTF streams.
本文件描述了IESG处理独立提交和IRTF流中提交供RFC发布的文件所使用的程序。
This document updates procedures described in RFC 2026 and RFC 3710.
本文件更新了RFC 2026和RFC 3710中描述的程序。
Status of This Memo
关于下段备忘
This memo documents an Internet Best Current Practice.
本备忘录记录了互联网最佳实践。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关BCP的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5742.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5742.
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括《信托法律条款》第4.e节中所述的简化BSD许可文本，并且提供BSD许可中所述的代码组件时不提供任何担保。
RFC 4844 [N1] defines four RFC streams. When a document is submitted for publication, the review that it receives depends on the stream in which it will be published. The four streams defined in RFC 4844 are:
RFC 4844[N1]定义了四个RFC流。提交文档以供发布时，它收到的审阅取决于将在其中发布文档的流。RFC 4844中定义的四个流是：
- The IETF stream - The IAB stream - The IRTF stream - The Independent Submission stream
- IETF流-IAB流-IRTF流-独立提交流
The IETF is responsible for maintaining the Internet Standards Process, which includes the requirements for developing, reviewing and approving Standards Track and BCP RFCs. These RFCs, and any other IETF-generated Informational or Experimental documents, are reviewed by appropriate IETF bodies [N2] and published as part of the IETF stream.
IETF负责维护互联网标准流程，包括制定、审查和批准标准跟踪和BCP RFC的要求。这些RFC和任何其他IETF生成的信息或实验文件由适当的IETF机构[N2]审查，并作为IETF流的一部分发布。
Documents published in streams other than the IETF stream might not receive any review by the IETF for such things as security, congestion control, or inappropriate interaction with deployed protocols. Generally, there is no attempt for IETF consensus or IESG approval. Therefore, the IETF disclaims, for any of the non-IETF stream documents, any knowledge of the fitness of those RFCs for any purpose.
在IETF流以外的流中发布的文档可能不会收到IETF对安全性、拥塞控制或与已部署协议的不当交互等方面的任何审查。一般来说，没有IETF共识或IESG批准的尝试。因此，对于任何非IETF流文件，IETF不承认这些RFC适用于任何目的的任何知识。
IESG processing described in this document is concerned only with the last two categories, which comprise the Independent Submission stream and the IRTF stream, respectively [N1].
本文件中描述的IESG处理仅涉及最后两类，分别包括独立提交流和IRTF流[N1]。
Following the approval of RFC 2026 [N2] and prior to the publication of RFC 3932 [I1], the IESG reviewed all Independent Submission stream documents before publication. This review was often a full-scale review of technical content, with the Area Directors (ADs) attempting to clear points with the authors, stimulate revisions of the documents, encourage the authors to contact appropriate working groups (WGs), and so on. This was a considerable drain on the resources of the IESG, and because this was not the highest priority task of the IESG members, it often resulted in significant delays.
在RFC 2026[N2]获得批准后以及RFC 3932[I1]发布之前，IESG在发布之前审查了所有独立提交流文件。该审查通常是对技术内容的全面审查，区域主任（ADs）试图与作者澄清观点，鼓励修改文件，鼓励作者联系适当的工作组（WG），等等。这对IESG的资源造成了相当大的消耗，而且由于这不是IESG成员的最高优先任务，因此常常导致重大延误。
In March 2004, the IESG decided to make a major change in this review model, with the IESG taking 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 AD chooses to review the technical
2004年3月，IESG决定对该审查模式进行重大修改，IESG只负责检查IETF工作与提交文件之间的冲突。征求技术审查被视为RFC编辑的责任。如果单个广告选择审查技术报告
content of the document and finds issues, that AD will communicate these issues to the RFC Editor, and they will be treated the same way as comments on the documents from other sources.
该广告将向RFC编辑传达这些问题，并将以与其他来源的文档评论相同的方式处理这些问题。
Prior to 2006, documents from the IRTF were treated as either IAB submissions or Independent Submissions via the RFC Editor. However, the Internet Research Steering Group (IRSG) has established a review process for the publication of RFCs from the IRTF stream [I2]. Once these procedures are fully adopted, the IESG will be responsible only for checking for conflicts between the work of the IETF and the documents submitted, but results of the check will be reported to the IRTF. These results may be copied to the RFC Editor as a courtesy.
在2006年之前，IRTF的文件通过RFC编辑器被视为IAB提交的文件或独立提交的文件。然而，互联网研究指导小组（IRSG）已经为IRTF流中RFC的发布建立了审查流程[I2]。一旦这些程序被完全采用，IESG将只负责检查IETF的工作与提交的文件之间的冲突，但检查结果将报告给IRTF。出于礼貌，可将这些结果复制到RFC编辑器。
This document describes only the review process done by the IESG when the RFC Editor or the IRTF requests that review. The RFC Editor will request the review of Independent Submission stream documents, and the IRTF will request review of IRTF stream documents. 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 as part of the Independent Submission stream, or the IESG may suggest that a document submitted to the IETF is better suited for submission to the RFC Editor as part of Independent Submission stream, but these interactions are not described in this memo.
本文件仅描述了当RFC编辑器或IRTF请求审查时，IESG所做的审查过程。RFC编辑器将要求审查独立提交流文件，IRTF将要求审查IRTF流文件。文档编辑器和IESG之间还有许多其他交互，例如，广告可能建议作者提交文档作为IETF内工作的输入，而不是作为独立提交流的一部分提交给RFC编辑器，或者IESG可能建议，提交给IETF的文件更适合作为独立提交流的一部分提交给RFC编辑器，但本备忘录中未描述这些交互。
For the convenience of the reader, this document includes description of some actions taken by the RFC Editor, the IAB, and the IRSG. The inclusion of these actions is not normative. Rather, these actions are included to describe the overall process surrounding the normative IESG procedures described in this document. No RFC Editor, IAB, or IRSG procedures are set by this document.
为方便读者，本文件包括RFC编辑器、IAB和IRSG采取的一些措施的说明。纳入这些行动是不规范的。更确切地说，包括这些行动是为了描述围绕本文件中所述的IESG规范程序的总体过程。本文件未设置RFC编辑器、IAB或IRSG程序。
RFC 3932 provided procedures for the review of Independent Submission stream submissions. With the definition of procedures by the IRSG for the IRTF stream, it has become clear that similar procedures apply to the review by the IESG of IRTF stream documents.
RFC 3932提供了审查独立提交流提交的程序。随着IRSG对IRTF流程序的定义，很明显，类似程序适用于IESG对IRTF流文件的审查。
The IAB and the RFC Editor have made updates to the formatting of the title page for all RFCs [N3]. With these changes, the upper left hand corner of the title page indicates the stream that produced the RFC. This label replaces some of the information that was previously provided in mandatory IESG notes on non-IETF-stream documents.
IAB和RFC编辑器已对所有RFC的标题页格式进行了更新[N3]。通过这些更改，标题页的左上角表示生成RFC的流。该标签取代了之前在非IETF流文档的强制性IESG注释中提供的一些信息。
The IESG may request the inclusion of an IESG note in an Independent Submission or IRTF stream document to explain the specific relationship, if any, to IETF work. In case there is a dispute about
IESG可要求在独立提交文件或IRTF流文件中包含IESG注释，以解释与IETF工作的具体关系（如有）。以防关于
the content of the IESG note, this document provides a dispute resolution process.
在IESG说明的内容中，本文件提供了争议解决流程。
The review of Independent Submissions by the IESG was prescribed by RFC 2026 [N2], Section 4.2.3. The procedure described in this document is compatible with that description.
RFC 2026[N2]第4.2.3节规定了IESG对独立提交文件的审查。本文件中描述的程序与该说明一致。
The procedures developed by the IRTF for documents created by the Research Groups also include review by the IESG [I2].
IRTF为研究小组创建的文件制定的程序还包括IESG的审查[I2]。
The IESG Charter (RFC 3710 [I5], Section 5.2.2) describes the review process that was employed in Spring 2003 (even though the RFC was not published until 2004); with the publication of RFC 3932 [I1], the procedure described in RFC 3710 was no longer relevant to documents submitted via the RFC Editor. The publication of this document further updates Section 5.2.2 of RFC 3710, now covering both the IRTF and the Independent Submission streams.
IESG章程（RFC 3710[I5]，第5.2.2节）描述了2003年春季采用的审查过程（尽管RFC直到2004年才公布）；随着RFC 3932[I1]的发布，RFC 3710中描述的程序不再与通过RFC编辑器提交的文件相关。本文件的发布进一步更新了RFC 3710第5.2.2节，目前涵盖了IRTF和独立提交流。
The RFC Editor reviews Independent Submission stream submissions for suitability for publication as RFCs. As described in RFC 4846 [I3], 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 4846[I3]所述，RFC编辑器要求IESG审查文件是否与IETF标准流程或IETF社区中完成的工作存在冲突。
Similarly, documents intended for publication as part of the IRTF stream are sent to the IESG for review for conflicts with the IETF standards process or work done in the IETF community [I2].
类似地，拟作为IRTF流的一部分发布的文件被发送给IESG，以审查是否与IETF标准流程或IETF社区中完成的工作存在冲突[I2]。
The IESG review of these Independent Submission and IRTF stream documents results in one of the following five types of conclusion, any of which may be accompanied by a request to include an IESG note if the document is published.
IESG对这些独立提交文件和IRTF流文件的审查得出以下五种结论中的一种，其中任何一种结论都可能随附一份请求，要求在文件发布时包含IESG注释。
1. The IESG has concluded that there is no conflict between this document and IETF work.
1. IESG得出结论，本文件与IETF工作之间不存在冲突。
2. The IESG has concluded that this work is related to IETF work done in WG <X>, but this relationship does not prevent publishing.
2. IESG得出结论，这项工作与在WG<X>中完成的IETF工作有关，但这种关系并不妨碍发布。
3. The IESG has concluded that publication could potentially disrupt the IETF work done in WG <X> and recommends not publishing the document at this time.
3. IESG得出结论认为，发布可能会中断在WG<X>中完成的IETF工作，建议目前不要发布该文件。
4. The IESG has concluded that this document violates IETF procedures for <Y> and should therefore not be published without IETF review and IESG approval.
4. IESG得出结论，本文件违反了IETF的<Y>程序，因此未经IETF审查和IESG批准，不得发布。
5. The IESG has concluded 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 RFC headers and boilerplate [N3] is intended to describe the relationship of the document to the IETF standards process. In exceptional cases, when the relationship of the document to the IETF standards process might be unclear, the IESG may request the inclusion of an IESG note to clarify the relationship of the document to the IETF standards process. Such a note is likely to include pointers to related IETF RFCs. The dispute resolution process in Section 4 is provided to handle situations in which the IRSG or RFC Editor is concerned with the content of the requested IESG note.
RFC标题和样板文件[N3]旨在描述文件与IETF标准过程的关系。在例外情况下，当文件与IETF标准过程的关系可能不明确时，IESG可要求包含IESG注释，以澄清文件与IETF标准过程的关系。此类注释可能包括指向相关IETF RFC的指针。第4节中的争议解决程序用于处理IRSG或RFC编辑关注所请求的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 Review, Standards Action, or IESG Approval (as these terms are defined in RFC 5226 [I6]), and for the case where there is a proposed change or extension to an IETF protocol that was not anticipated by the original authors and that may be detrimental 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 5226[I6]中定义的这些术语）的行动（如注册新的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 IETF 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将为作者提供机会，要求将其作为广告赞助的个人文件出版，该文件需接受IETF的全面审查，包括可能指派给工作组或拒绝。重新定向到完整的IESG审查路径并不能保证IESG会接受工作项，甚至不能保证IESG会给予它任何特定的优先级；这是IESG将考虑该文件的保证。
The IESG will normally complete review within four weeks of notification by the RFC Editor or IRTF. 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 that WG and, in the case of a possible conflict with an IANA registration procedure, the IANA expert for that registry.
IESG通常会在RFC编辑或IRTF通知后四周内完成审查。在可能发生冲突的情况下，IESG可联系工作组或工作组主席，征求外界对发布文件是否有害于工作组工作的意见，如果与IANA注册程序可能发生冲突，则可联系该注册处的IANA专家。
If the IESG does not find any conflict between an Independent Submission and IETF work, then the RFC Editor is responsible for judging the technical merits for that submission, including considerations of possible harm to the Internet. If the IESG does not find any conflict between an IRTF submission and IETF work, then
如果IESG未发现独立提交与IETF工作之间存在任何冲突，则RFC编辑负责判断该提交的技术优点，包括考虑可能对互联网造成的危害。如果IESG未发现IRTF提交和IETF工作之间存在任何冲突，则
the IRSG is responsible for judging the technical merits for that submission, including considerations of possible harm to the Internet.
IRSG负责判断该提交文件的技术价值，包括考虑可能对互联网造成的危害。
The RFC Editor, in agreement with the IAB, shall manage mechanisms for appropriate technical review of Independent Submissions. Likewise, the IRSG, in agreement with the IAB, shall manage mechanisms for appropriate technical review of IRTF submissions.
RFC编辑应与IAB达成一致，管理对独立提交文件进行适当技术审查的机制。同样，IRSG应与IAB达成一致，管理IRTF提交的适当技术审查机制。
Experience has shown that the IESG and the RFC Editor have worked well together regarding publication recommendations and IESG notes. Where questions have arisen, they have been quickly resolved when all parties become aware of the concerns. However, should a dispute ever arise, a third party can assist with resolution. Therefore, this dispute procedure has an informal dialogue phase followed by an arbitration phase if the matter remains unresolved.
经验表明，IESG和RFC编辑在出版建议和IESG注释方面合作良好。当出现问题时，当所有各方都意识到这些问题时，问题很快就得到解决。但是，如果发生争议，第三方可以协助解决。因此，该争议程序有一个非正式对话阶段，如果问题仍未解决，则随后是仲裁阶段。
If the IESG requests the inclusion of an IESG note and the IRSG or the RFC Editor intends to publish the document without the requested IESG note, then they must provide a clear and concise description of the concerns to the IESG before proceeding. A proposal for alternate IESG note text from the IRSG or the RFC Editor is highly encouraged.
如果IESG要求包含IESG注释，且IRSG或RFC编辑打算在不包含IESG注释的情况下发布文件，则他们必须在继续之前向IESG提供清晰、简洁的问题描述。强烈建议IRSG或RFC编辑提供替代IESG注释文本。
If the IESG does not want the document to be published without the requested IESG note, then the IESG must initiate an informal dialogue. The dialogue should not take more than six weeks. This period of time allows the IESG to conduct an IETF Last Call concerning the content of the requested IESG note (and not on the document as a whole) to determine community consensus if desired. At the end of the dialogue, the IESG can reaffirm the original IESG note, provide an alternate IESG note, or withdraw the note altogether. If an IESG note is requested, the IRSG or the RFC Editor must state whether they intend to include it.
如果IESG不希望在没有要求的IESG说明的情况下发布文件，则IESG必须发起非正式对话。对话不应超过六周。这段时间允许IESG就所请求的IESG说明（而不是整个文件）的内容进行IETF最后呼叫，以确定社区共识（如果需要）。在对话结束时，IESG可以重申原始IESG注释，提供备用IESG注释，或完全撤销注释。如果要求提供IESG注释，IRSG或RFC编辑必须说明是否打算将其包括在内。
If dialogue fails to resolve IRSG or RFC Editor concerns with the content of a requested IESG note and they intend to publish the document as an RFC without the requested IESG note, then the IESG can formally ask the IAB to provide arbitration. The IAB is not obligated to perform arbitration and may decline the request. If the IAB declines, the RFC Editor decides whether the IESG note is included. If the IAB accepts, the IAB review will occur according to procedures of the IAB's own choosing. The IAB can direct the inclusion of the IESG note, direct the withdrawal of the IESG note, or leave the final decision to the RFC Editor. Unlike the IAB reviews specified in RFC 4846 [I3], if the IAB directs the inclusion
如果对话未能解决IRSG或RFC编辑对请求的IESG注释内容的担忧，并且他们打算在没有请求的IESG注释的情况下将文件作为RFC发布，则IESG可以正式请求IAB提供仲裁。IAB没有义务执行仲裁，可能会拒绝该请求。如果IAB拒绝，RFC编辑将决定是否包含IESG注释。如果IAB接受，IAB审查将根据IAB自己选择的程序进行。IAB可以指示包含IESG注释，指示撤销IESG注释，或将最终决定权留给RFC编辑。与RFC 4846[I3]中规定的IAB审查不同，如果IAB指示纳入
or withdrawal the IESG note, the IAB decision is binding, not advisory.
或撤回IESG说明，IAB的决定具有约束力，而非咨询性。
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:
被拒绝的替代旁路：
As a WG is working on a solution to a problem, a participant decides to ask for Independent Submission stream publication of a solution that the WG has rejected. Publication of the document will give the publishing party an RFC number 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）之后出版。
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 adopted by the WG.
注：一般来说，IESG对向社区提供被拒绝的替代品没有问题；这些出版物可以对技术文献作出有价值的贡献。但是，有必要避免与工作组采用的备选方案混淆。
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 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.
2003年，发表了一份关于实验性RFC的提案，该提案希望将IP报头的“片段偏移”部分的高位重新用于其他目的。IANA没有考虑这些位的用途，但该标准为它们定义了特定的含义。IESG得出结论，该实验的实现有可能导致难以调试的互操作性问题，建议不要在RFC系列中发布该文档。RFC编辑接受了这一建议。
The RFC series is one of many available publication channels; this document takes no position on the question of which documents are appropriate for publication in the RFC Series. That is a matter for discussion in the Internet community.
RFC系列是许多可用的出版渠道之一；本文件对哪些文件适合在RFC系列中发布的问题不持任何立场。这是互联网社区讨论的问题。
In its capacity as the body that approves the general policy followed by the RFC Editor (see RFC 2850 [I4]), the IAB has reviewed this proposal and supports it as an operational change that is in line with the respective roles of the IESG, IRTF, and RFC Editor. The IAB continues to monitor discussions within the IETF about potential adjustments to the IETF document publication processes and recognizes that the process described in this document, as well as other general IETF publication processes, may need to be adjusted to align with any changes that result from such discussions.
作为批准RFC编辑遵循的一般政策的机构（参见RFC 2850[I4]），IAB审查了该提案，并支持该提案，作为符合IESG、IRTF和RFC编辑各自角色的运营变更。IAB继续监控IETF内部关于IETF文件发布流程潜在调整的讨论，并认识到本文件中描述的流程以及其他一般IETF发布流程可能需要调整，以适应此类讨论产生的任何变化。
The process change described in this memo has no direct bearing on the security of the Internet.
本备忘录中描述的流程变更与互联网安全没有直接关系。
RFC 3932 was a product of the IESG in October 2004, and it was reviewed in the IETF, by the RFC Editor, and by the IAB. Special thanks for the development of RFC 3932 go to (in alphabetical order) Scott Bradner, Brian Carpenter, Paul Hoffman, John Klensin, Eliot Lear, Keith Moore, Pete Resnick, Kurt Zeilenga, and all other IETF community participants who provided valuable feedback.
RFC 3932是IESG于2004年10月推出的产品，并在IETF、RFC编辑和IAB中进行了审查。特别感谢RFC 3932的开发（按字母顺序），请联系Scott Bradner、Brian Carpenter、Paul Hoffman、John Klesins、Eliot Lear、Keith Moore、Pete Resnick、Kurt Zeilenga和所有其他提供了宝贵反馈的IETF社区参与者。
This update to RFC 3932 was the product of the IESG in July and August of 2008, and it was reviewed in the IETF, by the RFC Editor, by the IRSG, and by the IAB. Special thanks for the development of this update go to (in alphabetical order) Jari Arkko, Ran Atkinson, Leslie Daigle, Lars Eggert, Aaron Falk, Sam Hartman, John Klensin, Olaf Kolkman, and Andy Malis.
RFC 3932的更新是IESG于2008年7月和8月发布的，并在IETF、RFC编辑、IRSG和IAB中进行了审查。特别感谢（按字母顺序）Jari Arkko、Ran Atkinson、Leslie Daigle、Lars Eggert、Aaron Falk、Sam Hartman、John Klesins、Olaf Kolkman和Andy Malis开发此更新。
[N1] Daigle, L., Ed., and Internet Architecture Board, "The RFC Series and RFC Editor", RFC 4844, July 2007.
[N1]Daigle，L.，Ed.，和互联网架构委员会，“RFC系列和RFC编辑器”，RFC 48442007年7月。
[N2] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[N2]Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[N3] Daigle, L., Ed., and O. Kolkman, Ed., "RFC Streams, Headers, and Boilerplates", RFC 5741, December 2009.
[N3]Daigle，L.，Ed.，和O.Kolkman，Ed.，“RFC流、标题和样板”，RFC 57412009年12月。
[I1] Alvestrand, H., "The IESG and RFC Editor Documents: Procedures", BCP 92, RFC 3932, October 2004.
[I1]Alvestrand，H.，“IESG和RFC编辑文件：程序”，BCP 92，RFC 3932，2004年10月。
[I2] Falk, A., "Definition of an Internet Research Task Force (IRTF) Document Stream", RFC 5743, December 2009.
[I2]Falk，A.“互联网研究工作队（IRTF）文件流的定义”，RFC 5743，2009年12月。
[I3] Klensin, J., Ed., and D. Thaler, Ed., "Independent Submissions to the RFC Editor", RFC 4846, July 2007.
[I3]Klensin，J.，Ed.，和D.Thaler，Ed.，“向RFC编辑提交的独立意见”，RFC 48462007年7月。
[I4] Internet Architecture Board and B. Carpenter, Ed., "Charter of the Internet Architecture Board (IAB)", BCP 39, RFC 2850, May 2000.
[I4]互联网架构委员会和B.Carpenter，Ed.，“互联网架构委员会（IAB）章程”，BCP 39，RFC 2850，2000年5月。
[I5] Alvestrand, H., "An IESG charter", RFC 3710, February 2004.
[I5]Alvestrand，H.，“IESG宪章”，RFC 3710，2004年2月。
[I6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[I6]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
Authors' Address
作者地址
Harald Alvestrand EMail: harald@alvestrand.no
Harald Alvestrand电子邮件：harald@alvestrand.no
Russell Housley EMail: housley@vigilsec.com
Russell Housley电子邮件：housley@vigilsec.com