RFC8729：The RFC Series and RFC Editor，February 2020
梗概
本文档描述了 RFC 系列和 RFC 编辑器功能的框架，这些功能结合了有组织的社区参与和问责制的原则，随着互联网技术社区的发展，这已成为必要，从而使 RFC 系列能够继续履行其职责。本文档废弃了 RFC 4844。
本备忘录的状态
本文档不是 Internet Standards Track 规范；它是为了信息目的而发布的。
本文档是互联网架构委员会 (Internet Architecture Board，IAB) 的产品，代表 IAB 认为有价值的信息，可提供永久记录。它代表了互联网架构委员会 (IAB) 的共识。IAB 批准发布的文件不适合任何级别的 Internet 标准；请参阅 RFC 7841 的第 2 节。
有关本文档当前状态、任何勘误以及如何提供反馈的信息，请访问 https://www.rfc-editor.org/info/rfc8729。
版权声明
版权所有 (c) 2020 IETF Trust 和确定为文档作者的人员。版权所有。
本文档受 BCP 78 和 IETF Trust 的与 IETF 文档相关的法律规定 (https://trustee.ietf.org/license-info) 约束，在本文档发布之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
1、 简介
第一个征求意见 (Request for Comments，RFC) 文档于 1969 年 4 月发布，作为设计和构建我们现在所知的互联网的努力的一部分。从那时起，RFC 系列一直是致力于记录 Internet 技术规范的档案系列，包括 Internet 研究和工程社区的一般贡献以及标准文档。
正如第一篇《RFC的30年 ([RFC2555])》的历史所描述的那样，创建 RFC 系列的目的是捕捉作为（我们现在所知道的）互联网设计基础的研究和工程思想。随着互联网工程任务组 (Internet Engineering Task Force，IETF) 正式成立以进行互联网标准的讨论和文档编制，IETF 文档已成为 RFC 系列的很大一部分（但不是全部）。
随着 IETF 的成长和庆祝自己 30 年的历史，其对输出档案出版的要求发生了变化并变得更加严格。也许最重要的是，IETF 必须能够定义（基于其自己的公开共识讨论流程和领导方向）并对其发布流程进行调整。
与此同时，整个互联网工程和研究社区已经发展壮大，并要求所有支持它的组织更加开放和负责。这个社区比以往任何时候都更需要一个 RFC 系列得到支持（在操作和原则方面），以便在以下方面取得平衡：
* 专家实施；
* 明确的管理和方向——整个 RFC 系列的运营和演进（无论是否源自 IETF）；
* 适当的社区投入和活动审查。
过去，对于在何处以及如何解决贡献团体（例如 IETF、互联网架构委员会 (IAB) 或独立个人）特有的 RFC 问题，存在着混淆，因此有时会产生紧张。社区参与与 RFC 编辑器控制之间的关系并不总是很清楚；根据问题的不同，IAB、互联网工程指导小组 (Internet Engineering Steering Group，IESG) 或整个社区的参与程度可能有所不同。处理 RFC 系列范围内的问题也有类似的问题——在哪里以在整个系列中平衡的方式讨论和解决它们。
例如，已经有关于 IETF 生成文档的知识产权 (Intellectual Property Rights，IPR) 的讨论，但不清楚何时或如何抽象这些讨论中与 RFC 系列的其余部分相关的部分。对标签的讨论（一般是 RFC，特别是 IETF 文档，或其某些组合）通常必须应用于整个 RFC 系列或根本不适用。如果没有一个商定的框架来管理 RFC 系列，就很难以非两极分化的方式进行这些讨论——要么是 IETF 规定了 RFC 系列其余部分的现实，要么是 RFC 系列对文档施加了不适当的限制来自 IETF。
作为其章程的一部分（参见附录 A），IAB 对 RFC 编辑负责。认识到 IETF 的需求以及一般 Internet 工程和研究社区不断发展的需求，IAB 支持 RFC 系列的未来，该系列将继续满足其为描述 Internet 的技术研究和工程文档提供档案系列的原始任务。
通过本文档，IAB 为 RFC 系列和 RFC 编辑器功能提供了框架，其特定目的是确保以符合 RFC 系列的既定目的和当今现实的方式维护和支持 RFC 系列互联网研究和工程社区。该框架描述了 RFC 的现有“流程”，绘制了已经定义实施的现有流程文档的路线图，并提供了如何通过讨论和未来的文档修订来发展该框架及其支持部分的明确方向。
具体而言，本文档提供了 RFC 系列的简要章程，描述了 RFC 编辑器、IAB 和 IETF 管理支持活动 (IETF Administrative Support Activity，IASA) 在管理 RFC 系列的框架中的作用，并讨论了对 RFC 系列的输入流程来自它所服务的各个选区的 RFC 系列。
2、 RFC系列任务
RFC 系列是致力于记录 Internet 技术规范的档案系列，包括 Internet 研究和工程社区的一般贡献以及标准文档。
任何人都可以通过 Internet 免费获得 RFC。
3、 角色和职责
由于本文档列出了支持 RFC 系列任务的框架，因此本节将审查已经和将要参与持续支持任务的实体的更新角色和职责。
3.1、 RFC编辑器
最初，只有一个人担任 RFC 系列的编辑（RFC Editor）。任务增加了，现在的工作需要几位专家的有组织的活动，因此出现了 RFC Editors，或 RFC Editor 组织。随着时间的推移，可能会有多个组织共同承担 RFC 系列所需的工作。为简单起见，并且不试图预测如何在它们之间细分角色，本文档将这一专家和组织集合称为“RFC 编辑器”。
RFC 编辑器是专业的技术编辑器和系列编辑器，负责支持 RFC 系列的使命。因此，RFC 编辑器是根据定义的流程处理 RFC 系列编辑管理的实施者。此外，RFC 编辑有望成为讨论编辑、发布和归档 RFC 政策的专家和主要推动者。
3.2、 IAB
在此模型中，IAB 的作用是确保 RFC 系列任务为创建它的整个社区得到适当的履行。IAB 在组织上没有全面的出版或编辑专业知识。因此，IAB 的作用侧重于确保原则得到满足，适当的机构和社区得到适当的通知和咨询，并且 RFC 编辑拥有执行其职责范围内的材料所需的一切。
IAB 负责批准 RFC 编辑的任命并批准 RFC 编辑遵循的一般政策。
3.3、 运营监督
作为 IETF 行政支持活动 (IASA) 的一部分，IETF 管理有限责任公司 (IETF Administration Limited Liability Company，IETF LLC) 负责 IETF、IAB 和互联网研究任务组 (Internet Research Task Force，IRTF) [RFC8711] 的行政和财务事务。IASA 的任务是为 RFC 编辑提供资金。IASA 通过 IETF 执行董事对 RFC 编辑进行合同和财务监督。此外，如 [RFC8728] 第 3.1 节所述，RFC 系列监督委员会 (RFC Series Oversight Committee，RSOC) 受 IAB 授权，负责确保 RFC 系列以透明和负责任的方式运行，包括设计和执行RFC 系列编辑器选择过程。
IETF 执行董事与 IAB 合作确定合适的人员或实体，以履行 [RFC8728] 中定义的 RFC 生产中心和 RFC 发布者角色的职责。
IETF 执行董事与选定的个人或实体建立适当的合同协议，以执行满足为各种 RFC 输入流程定义的技术发布要求的工作（参见第 5.2 节）。IETF 执行董事可以为管理目的定义额外的操作要求和政策，以满足各个社区定义的要求。
IETF 管理有限责任公司委员会批准 RFC 编辑器活动的运营预算，IETF 执行董事为 RFC 编辑器活动建立和管理必要的运营协议。
3.4、 政策监督
IAB 监控现行政策及其实施的有效性，以确保 RFC 编辑活动满足本文档中引用的编辑管理和文档发布需求。如果出现严重不符合项，IAB 可以主动或应 IETF 管理有限责任公司委员会的要求，要求 IETF 执行董事更改或终止并重新协商 RFC 编辑活动的安排。
4、 框架
通过上面概述的 RFC 系列任务，本文档描述了一个框架，用于支持：
* RFC 系列的操作实现，
基于：
* 公共流程和定义文件，
其中有：
* 明确更新和变更的责任和机制。
一般来说，RFC Editor 负责 RFC 系列的操作实施。如第 3.3 节所述，IETF 执行董事负责监督这一运营角色。
流程和定义文档详述如下，包括各个流程文档（维护和更新）的责任。RFC 编辑与适当的社区合作，以确保流程文档反映当前的要求。IAB 的职责是验证是否已寻求适当的社区意见，以及任何更改都适当地说明了社区要求。
活动分为三类，第四类是系列范围的规则和指南，用于实施 RFC 系列以支持其使命：
* 文件审批。
* 文件的编辑、处理和出版。
* 归档和索引文档并使其可访问。
* 系列规则和指南。
4.1、 文件审批
RFC 系列任务隐含地要求对文档进行审查和批准以接受该系列。
4.1.1、 定义
第 5.1 节描述了今天作为 RFC 发布到 RFC 编辑器中的不同文档流程。虽然可能有批准文档作为 RFC 的一般政策（以确保 RFC 系列的一致性），但也有为每个流程中的文档批准定义的政策。一般来说，每个流程都有不同的审批机构。当前定义在第 5.1 节中进行了编目。
4.1.2、 运营实施
每个流程都有自己的书面批准流程。RFC 编辑负责批准其中一个流程（独立提交流程，参见第 5.1.4 节）中的文件，并与其他批准机构合作，以确保批准的文件顺利进入下一阶段，最终发布和存档作为 RFC。
4.1.3、 流程变更
有时，可能需要更改任何给定流程的审批流程，甚至添加或删除流程。当 RFC 编辑、IAB、负责给定文档流程的机构或社区确定存在一般需要解决的问题以供 RFC 批准或按流程批准流程解决时，可能会发生这种情况。
在此框架中，一般方法是 IAB 将与 RFC 编辑器和其他各方合作以获取社区意见，并将验证任何更改是否适当地考虑了社区要求。
4.1.4、 现有的审批流程文件
描述每个流程的批准过程的现有文件在第 5.1 节中有详细说明。
4.2、 文件的编辑、处理和发布
制作和维护连贯、编辑良好的文档系列需要专业技能和主题专业知识。这是 RFC 编辑器的职责。尽管如此，由 RFC 系列服务的社区和由各个 RFC 流程服务的社区都有帮助定义系列性质的要求。
4.2.1、 定义
RFC 系列的一般和流程特定要求记录在社区批准的文件中（在下面的第 5.2 节中列出）。
使要求可操作所需的任何特定接口、数字或具体值都是 IASA 和 RFC 编辑器之间协议的主题（例如，合同、工作说明、服务水平协议等）。
4.2.2、 运营实施
RFC 编辑负责确保 RFC 的编辑、处理和发布以符合相应文档中规定的要求的方式进行。RFC 编辑与 IASA 合作，提供有关这些操作的定期报告和反馈。
4.2.3、 流程变更
有时，可能需要更改任何给定流程或一般 RFC 系列的要求。当 RFC 编辑、IAB、给定文档流程的批准机构或社区确定存在需要针对 RFC 或每个流程的要求解决的问题时，可能会发生这种情况。
在此模型中，一般方法是 IAB 将与 RFC 编辑器合作以获取社区意见，并通过验证对社区要求的适当考虑来批准更改。
4.2.4、 现有流程文件
描述流程的现有要求的文件在第 5.2 节中有详细说明。
4.3、 存档、索引和可访问性
归档、索引和使 RFC 系列可访问的活动可以通过一般文档系列编辑中的特定主题专业知识提供信息。让他们了解整个社区的要求也很重要。只要 RFC 系列要保持连贯性，就应该对所有流程中的 RFC 进行统一的归档和索引，以及访问结果文档的通用方法。
4.3.1、 定义
原则上，应该有一个社区共识文件，描述 RFC 系列的归档、索引和可访问性要求。在实践中，我们继续使用自系列开始以来由有能力的 RFC 编辑器构建的档案。
存档、索引和可访问性操作的任何具体具体要求是 IASA 和 RFC 编辑器之间协议的主题（例如，合同、工作说明、服务水平协议等）。
4.3.2、 运营实施
RFC 编辑器负责确保 RFC 档案和索引得到适当维护，并且生成的文档可供任何希望通过 Internet 访问的人使用。RFC 编辑与 IASA 合作进行定期报告和反馈。
4.3.3、 流程变更
如果社区提议更改 RFC 存档和索引或可访问性的要求，IAB 将与 RFC 编辑器合作以获取社区意见，并将通过验证对社区要求的适当考虑来批准更改。
4.3.4、 现有流程文件
没有适用的流程文件。
4.4、 系列范围的指导方针和规则
RFC 系列的风格和内容可以通过文档系列编辑中的主题专业知识来塑造。他们还从使用社区的要求中获悉。只要 RFC 系列要保持连贯性，所有流程中的 RFC 就应该有统一的样式和内容。这包括但不限于可接受的语言、引用的使用和版权规则。
4.4.1、 定义
原则上，应该有一个社区共识文件（或一组文件）来描述 RFC 系列的内容要求。在实践中，有些确实存在，但有些需要审查，随着时间的推移可能需要更多。
4.4.2、 运营实施
RFC 编辑负责确保 RFC 系列指南在 RFC 系列中得到维护。
4.4.3、 流程变更
当需要对系列范围的定义进行添加或更改时，IAB 将与 RFC 编辑器和流程利益相关者合作，以获取社区意见和审查。IAB 将通过验证对社区要求的适当考虑来批准更改。
4.4.4、 现有流程文件
现有的全系列规则和指南文件包括：
* RFC 格式指南 [RFC7322]，
* RFC 中非 ASCII 字符的使用 [RFC7997]，
* 版权和知识产权规则[RFC5378]，
* 规范参考 [RFC3967] [RFC4897]、[RFC8067]。
5、 RFC 流程
各种贡献者为 RFC 系列提供输入。这些贡献者来自几个不同的社区，每个社区都有自己定义的流程来批准将由 RFC 编辑器发布的文档。这不是什么新鲜事。然而，随着时间的推移，各种社区和文件要求已经增长和分离。为了在讨论集体需求集时促进和谐，在他们自己的空间中识别每个需求是有用的——它们在这里被称为“流程”。
请注意，通过识别单独的流程，无意将它们分开或破坏它们作为一个系列的管理。相反，情况恰恰相反——通过澄清组成部分，更容易让它们一起工作，而不会在讨论各种需求时有时会出现摩擦。
下面的小节确定了当今存在的流程。没有立即创建新流程的期望，最好不要创建新流程。流程的创建和围绕 RFC 系列的一般更改的所有策略在上面的第 4 节中讨论。
5.1、 RFC 审批流程
每个流程的文档（或要求）审批流程由定义流程的社区定义。IAB 负责验证是否已寻求适当的社区意见，并且更改与 RFC 系列任务和此总体框架一致。
RFC 编辑器应在确定的流程之一中进行适当的审查和批准后发布传递给它的所有文档。
5.1.1、 IETF 文件流程
IETF 文件流程包括 IETF WG 文件以及由 IESG 区域主管赞助的“个人提交”。作为 IETF 标准流程的一部分发布的任何文档都必须遵循此流程——没有其他流程可以批准标准跟踪 RFC 或最佳当前实践 (Best Current Practice，BCP) RFC。
IETF 流程中文档的批准定义为
* IETF 标准流程 [RFC2026]（及其后续）。
* 用于赞助个人提交的 IESG 流程 [赞助商]。
通过更新 IETF 标准流程文件，对该流程的批准流程进行了更改。
5.1.2、 IAB 文件流程
IAB 定义了它在其流程中批准文档的流程。与上述一致，IAB 希望作为 IETF 标准跟踪（标准或 BCP）的一部分发布的任何文件均须遵守第 5.1.1 节中提到的批准流程。
IAB 流程中文档的审查和批准过程在
* IAB 审查和批准其文件的流程 [RFC4845]。
5.1.3、 IRTF 文件流程
IRTF 被特许为 IAB 的一项活动。经 IAB 批准，IRTF 可以发布和更新其自己的非 IETF 标准跟踪文件的发布流程。
IRTF 流程中文档的审查和批准过程在
* IRTF 研究组 RFC [RFC5743]。
5.1.4、 独立投稿流程
RFC 系列一直服务于比 IETF 更广泛的互联网技术社区。“独立提交”流程被定义为提供对上述流程范围之外的文件的审查和（可能的）批准。
一般而言，此流程中的文件的批准属于 RFC 编辑的权限，并且 RFC 编辑从 IESG 寻求其审查的输入。
独立提交流程中审查和批准文件的流程由
* RFC 独立提交流程 [RFC5744] 中的权限处理程序，
* 独立提交编辑器模型 [RFC8730]，
* 独立提交给 RFC 编辑器 [RFC4846]，
* IESG 和 RFC 编辑器文档：程序 [RFC5742]。
5.2、 RFC 技术出版物要求
Internet 工程和研究社区不仅发展壮大，而且变得更加多样化，有时甚至要求更高。作为一个标准制定组织，IETF 的出版要求超出了学术期刊的要求。IAB 与 IANA 分配的相互依赖性与 IETF 流程不同。因此，既需要对每个流程的发布要求进行编纂，又需要在合理的范围内努力协调它们。
因此，预计每个文档流程背后的努力社区将概述其技术发布要求。
作为 RFC 编辑器监督的一部分，IAB 必须同意这些要求与 RFC 编辑器活动的一部分一致并可实施。
5.2.1、 IETF 文件
该流程的要求在 [RFC4714] 中定义。
5.2.2、 IAB 文件
尽管它们是为 IETF 标准流程开发的，但 IAB 已在 [RFC4714] 中为其流程确定了适用的要求。此外，与 IAB 流程的 IPR 相关的过程在 [RFC5745] 中被捕获。
如果 IAB 选择定义其他要求，则他们应尽量少偏离这些要求（以努力保持由一个技术出版商合理管理的集体技术出版要求）。
5.2.3、 IRTF 文件
IRTF 已在 [RFC5743] 中为其流程确定了适用的要求。
如果 IRTF 选择定义其他要求，则他们应尽量少偏离这些要求（努力保持由一个技术出版商合理管理的集体技术出版要求）。
5.2.4、 独立提交
独立流程的程序和过程在[RFC4846]和[RFC8730]中描述。
尽管它们是为 IETF 标准流程开发的，但 RFC 编辑器已在 [RFC4714] 中确定了独立提交流程的适用要求。此外，[RFC5744] 中记录了与独立提交流程的 IPR 相关的程序。
如果 RFC 编辑器选择定义其他要求，则他们应尽量减少偏离这些要求（努力保持由一个技术出版商合理管理的集体技术出版要求）。
6、 安全考虑
文件发布过程必须防止引入未经批准的更改。由于 RFC 编辑器维护出版物的索引，因此必须有足够的安全措施来防止这些已发布的文档被外部方更改。需要保护 RFC 文档的存档、重新创建 RFC 文档所需的任何源文档以及任何相关的原始文档（例如勘误表、工具以及某些早期项目的非机器可读原始文档），以防失败存储介质和其他类似的灾难。
7、 自 RFC 4844 以来的变化
第 3.3、3.4 和 4 节已更新以与 IETF 管理支持活动 (IASA) 的重组保持一致。在新结构下，IETF LLC 执行与 IASA 相关的任务，这些任务以前分配给 IETF 行政主管和互联网协会。
许多参考资料已更新以指向最新的文件。
为了反映 RFC 4884 中提供的框架 10 年的使用情况，进行了少量编辑更改。例如，RFC 4844 说，“......本文档列出了一个修订后的框架......”，现在更合适的说法是， “……本文件规定了框架……”。
8、 参考资料
[RFC1358] Chapin, L., "Charter of the Internet Architecture Board (IAB)", RFC 1358, DOI 10.17487/RFC1358, August 1992, <https://www.rfc-editor.org/info/rfc1358>. [RFC1601] Huitema, C., "Charter of the Internet Architecture Board (IAB)", RFC 1601, DOI 10.17487/RFC1601, March 1994, <https://www.rfc-editor.org/info/rfc1601>. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, <https://www.rfc-editor.org/info/rfc2026>. [RFC2555] Editor, RFC. and et. al., "30 Years of RFCs", RFC 2555, DOI 10.17487/RFC2555, April 1999, <https://www.rfc-editor.org/info/rfc2555>. [RFC2850] Internet Architecture Board and B. Carpenter, Ed., "Charter of the Internet Architecture Board (IAB)", BCP 39, RFC 2850, DOI 10.17487/RFC2850, May 2000, <https://www.rfc-editor.org/info/rfc2850>. [RFC3967] Bush, R. and T. Narten, "Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level", BCP 97, RFC 3967, DOI 10.17487/RFC3967, December 2004, <https://www.rfc-editor.org/info/rfc3967>. [RFC4714] Mankin, A. and S. Hayes, "Requirements for IETF Technical Publication Service", RFC 4714, DOI 10.17487/RFC4714, October 2006, <https://www.rfc-editor.org/info/rfc4714>. [RFC4845] Daigle, L., Ed. and Internet Architecture Board, "Process for Publication of IAB RFCs", RFC 4845, DOI 10.17487/RFC4845, July 2007, <https://www.rfc-editor.org/info/rfc4845>. [RFC4846] Klensin, J., Ed. and D. Thaler, Ed., "Independent Submissions to the RFC Editor", RFC 4846, DOI 10.17487/RFC4846, July 2007, <https://www.rfc-editor.org/info/rfc4846>. [RFC4897] Klensin, J. and S. Hartman, "Handling Normative References to Standards-Track Documents", BCP 97, RFC 4897, DOI 10.17487/RFC4897, June 2007, <https://www.rfc-editor.org/info/rfc4897>. [RFC5378] Bradner, S., Ed. and J. Contreras, Ed., "Rights Contributors Provide to the IETF Trust", BCP 78, RFC 5378, DOI 10.17487/RFC5378, November 2008, <https://www.rfc-editor.org/info/rfc5378>. [RFC5742] Alvestrand, H. and R. Housley, "IESG Procedures for Handling of Independent and IRTF Stream Submissions", BCP 92, RFC 5742, DOI 10.17487/RFC5742, December 2009, <https://www.rfc-editor.org/info/rfc5742>. [RFC5743] Falk, A., "Definition of an Internet Research Task Force (IRTF) Document Stream", RFC 5743, DOI 10.17487/RFC5743, December 2009, <https://www.rfc-editor.org/info/rfc5743>. [RFC5744] Braden, R. and J. Halpern, "Procedures for Rights Handling in the RFC Independent Submission Stream", RFC 5744, DOI 10.17487/RFC5744, December 2009, <https://www.rfc-editor.org/info/rfc5744>. [RFC5745] Malis, A., Ed. and IAB, "Procedures for Rights Handling in the RFC IAB Stream", RFC 5745, DOI 10.17487/RFC5745, December 2009, <https://www.rfc-editor.org/info/rfc5745>. [RFC7322] Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322, DOI 10.17487/RFC7322, September 2014, <https://www.rfc-editor.org/info/rfc7322>. [RFC7997] Flanagan, H., Ed., "The Use of Non-ASCII Characters in RFCs", RFC 7997, DOI 10.17487/RFC7997, December 2016, <https://www.rfc-editor.org/info/rfc7997>. [RFC8067] Leiba, B., "Updating When Standards Track Documents May Refer Normatively to Documents at a Lower Level", BCP 97, RFC 8067, DOI 10.17487/RFC8067, January 2017, <https://www.rfc-editor.org/info/rfc8067>. [RFC8711] Haberman, B., Hall, J., and J. Livingood, "Structure of the IETF Administrative Support Activity, Version 2.0", BCP 101, RFC 8711, DOI 10.17487/RFC8711, February 2020, <https://www.rfc-editor.org/info/rfc8711>. [RFC8728] Kolkman, O., Ed., Halpern, J., Ed., and R. Hinden, Ed., "RFC Editor Model (Version 2)", RFC 8728, DOI 10.17487/RFC8728, February 2020, <https://www.rfc-editor.org/info/rfc8728>. [RFC8730] Brownlee, N., Ed. and R. Hinden, Ed., "Independent Submission Editor Model", RFC 8730, DOI 10.17487/RFC8730, February 2020, <https://www.rfc-editor.org/info/rfc8730>. [SPONSOR] IESG, "Guidance on Area Director Sponsoring of Documents", IESG Statement, March 2007, <http://www.ietf.org/iesg/statement/ad-sponsoring-docs.html>.
附录 A、 IAB 章程和 RFC 编辑器回顾
通过本文档，IAB 在 RFC 系列和 RFC 编辑器方面的角色正在调整，以更直接地与 RFC 编辑器合作，并提供监督以确保 RFC 系列任务原则和社区的意见得到适当解决。
本节概述了 IAB 相对于 RFC 编辑器的作用，因为它已在可追溯到 1992 年的 IAB 章程 RFC 中提出。本节的重点是 IAB 的作用历来是实质性的——无论是应该直接负责 RFC 系列的编辑管理（大约 1992 年，附录 A.1），或任命 RFC 编辑组织和批准一般政策（大约 2000 年，附录 A.3）。
A.1、 1992年
[RFC1358] 描述：
[IAB 的] 职责应包括：
[...]
(2) 征求意见稿 (RFC) 文件系列的编辑管理和出版，它构成了互联网标准和互联网研究和工程界相关贡献的档案出版系列。
A.2、 1994年
[RFC1601] 描述：
[IAB 的] 本章程规定的职责包括：
(d) RFC 系列和 IANA
IAB 负责评论请求 (RFC) 文档系列的编辑管理和发布，并负责管理各种 Internet 分配的编号。
它详细说明为：
2.4 RFC 系列和分配的编号
RFC 系列构成了 Internet 标准和 Internet 研究和工程社区的其他贡献的档案发布渠道。IAB 将选择一名 RFC 编辑，负责 RFC 系列的编辑管理和出版。
A.3、 2000年
最新的 IAB 章程 [RFC2850] 描述：
(d) RFC 系列和 IANA
RFC Editor 执行 IETF“征求意见稿”(RFC) 文档系列的编辑管理和发布，这是 IETF 的永久文档存储库。RFC 系列构成了 Internet 标准和 Internet 研究和工程社区的其他贡献的档案发布渠道。任何人都可以通过 Internet 免费获得 RFC。IAB 必须批准任命一个组织担任 RFC 编辑以及 RFC 编辑遵循的一般政策。
