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对工作组主席考虑是否认领草案提供了具体建议，包括：
草案必须符合工作组目前的章程或只需对章程作简单修改。
草案的目的应该明确。
草案应该是有用的。
文档的写作质量应足以作为进一步工作的基础。
不应有强烈的技术异议。
相关知识产权信息的披露都应是可接受的。
不与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月刊
整理：陈茜
声明：本文来自中国教育网络，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
