IETF的运行方式

互联网工程任务组IETF的研究从大方向上主要分为应用、一般领域、互联、运行、路由、安全和传输等领域。

IETF的组织架构由三部分组成：互联网体系结构委员会（IAB）、互联网工程指导委员会（IESG）以及涵盖了互联网各领域的工作组（Working Group）。

标准制定的工作由工作组承担，它们专注于互联网路由、传输、应用等领域。标准制定的工作大都通过所设立的邮件组完成。此外，IETF每年还会召开3次为期一周的会议，帮助工作组完成任务，并促进工作组之间的交流。

IESG的主要职责是接收各个工作组的报告，对报告进行审查，然后对其所提出的相关标准和建议提出指导性的意见。

IAB是IETF的顶层委员会，主要由探讨与互联网结构有关问题的互联网研究员组成，参与建立各种与互联网有关的组织，如互联网数字分配机构（IANA）、互联网工程指导委员会（IESG）和互联网研究指导组（IRSG）。

通过定期召开会议、频繁发布RFC的方式，IETF打造了互联网的技术规范。

RFC的形成过程

可以说，如果一项技术想要成为全世界软件开发商、硬件制造商以及网络运营商自愿实施的标准和遵守的规范，那么成为RFC是它的必经之路。

一般来说，IETF标准的相关文档包括互联网草案（Internet Draft）和RFC。草案是供IETF讨论的文档，是对互联网问题的描述和解决方案。RFC可被视为草案的最终版，具有特定的编号。

草案可由任何个人或工作组提交，但只有6个月的生命周期（可以不断更新）。需要注意的是，草案并不等同于标准、论文或正式报告，大多数草案也不会成为RFC。RFC才是互联网正式的文档。已发布的RFC即使有错误也不能更改，只能发布“错误订正”或用另一个RFC将其废除或取代。

工作组是产生RFC的首要途径，通常要经历以下几个流程：个人提交草案，工作组认领草案，工作组反复迭代讨论，工作组最后询问，IESG内部讨论，IESG批准，获得RFC编号，RFC文字编辑，正式发布。

其中最大的难点是工作组认领草案。RFC7221对工作组主席考虑是否认领草案提供了具体建议，包括：

1. 草案必须符合工作组目前的章程或只需对章程作简单修改。
2. 草案的目的应该明确。
3. 草案应该是有用的。
4. 文档的写作质量应足以作为进一步工作的基础。
5. 不应有强烈的技术异议。
6. 相关知识产权信息的披露都应是可接受的。
7. 不与IETF中的其他工作冲突。

产生RFC的第二条途径则针对没有相应工作组的文档，需要经过领域主席个人提交到IESG。

以上两条途径都要提交到IESG进行讨论，IESG再进行IETF范围内的最后询问。在多次反馈、修改，得到所有IESG成员的认可后，草案就可以送交RFC编辑部，授予RFC编号，进行文字编辑和格式协定，最终作为RFC发布。

产生RFC的第三条途径是针对非IETF提交的RFC，同样也没有经过工作组，而是个人直接提交文档至编辑部，并与后者进行讨论，考虑内容和编辑细节，与此同时，RFC编辑部和IESG直接交换意见，RFC形成后，由RFC编辑部直接发布。

从个人提交草案到工作组草案，再到IESG、RFC编辑部，直到最终成为RFC发布，整个过程最快也要2年以上，有时则需5年。从草案到标准，全程记录邮件收发并公开会议记录。

成为RFC作者象征着互联网技术界的荣誉和责任，但RFC定义的技术和标准能否在互联网中大规模得到应用，才是更大的挑战。

来源：《中国教育网络》2024年9月刊

整理：陈茜

声明：本文来自中国教育网络，稿件和图片版权均归原作者所有。所涉观点不代表东方安全立场，转载目的在于传递更多信息。如有侵权，请联系rhliu@skdlabs.com，我们将及时按原作者或权利人的意愿予以更正。