IETF组织结构与会议

　　在IETF的发展过程中，IETF的组织结构也不断地变化。目前IETF的组织结构如图1所示。

图1 IETF的组织结构

　　互联网协会(Internet Society，ISOC)是一个非营利的社团组织，有超过80个团体会员和超过2万8千名个人会员。互联网协会是IETF的法人。

　　互联网体系结构委员会(Internet Architecture Board，IAB)负责对互联网的体系结构进行监督审查，对IESG、IETF、IRTF和ISOC的运营进行监管。IAB也负责确认批准IESG的成员，对IETF的标准制定过程进行监管。IAB还负责IETF与其他国际标准化组织之间的协调工作，如电气与电子工程师学会(Instituteof Electrical and Electronics Engineers，IEEE)、万维I网联盟(World Wide Web Consortium，W3C)、国电信联盟(International Telecommunication Union，ITU)、国际标准化组织(International Organization for Standardization，ISO)等。

　　互联网研究任务组(Internet Research Task Force，IRTF)专注于互联网上的长期问题。

　　互联网号码分配局(Internet Assigned Numbers Authority，IANA)是互联网名称与数字地址分配委员会(Internet Corporationfor Assigned Names and Numbers，ICANN)的一个部门，负责监督全球IP地址和自治域系统号码分配、域名系统(Domain Name System，DNS)和根域名服务器的管理以及互联网协议相关符号和参数的分配和注册ICANN是基于全球多利益攸关方(Multi-stakeholder)模型的国际性非营利组织。

　　征求意见稿是由互联网工程任务组(IETF)发布的一系列标准备忘录，以编号排定。RFC文件是由互联网协会(ISOC)赞助发行，由IAB领导，RFC编辑部直接负责。

　　IETF行政支持(IETF Administrative Support，IASA)提供支持IETF标准流程所需的管理结构。

　　IETF行政总监（IETF Administrative Director，LAD）负责日常业务监督。

　　互联网工作指导组（Internet Engineering Steering Group IESG)负责组织IETF的工作组(Working Group，WG，每个工作组都有一个指定主席(或者若干副主席)。

　　领城(area)是工作组按主题的集合。每个领域都有一个领域主任(Area Director，AD)，大多数领域还有两个副领域主任，AD任命工作组主席。AD和IETE主席构成互联网工程指导组（IESG），负责IETF的整体运作。

　　IETF的领域也在不断演进，目前的领域构成如图2所示。

图2 IETF的领域划分

　　每个领域下有若干个工作组。IETF的具体工作在工作组中进行。来自世界各国的网络工程师在自己感兴趣的领域自愿地组合在一起，通过电子邮件讨论组开展工作。IETF工作组主要开发IETF详细说明和指导方针，其中很多详细说明最终成为了标准，以RFC的形式发布。

　　IETF可以说是IAB，IASA，RFC编辑部，IAD，IESG和各个领域和下属工作组的集合。

　　建立新工作组

　　领域主任（AD）、个人或团体都可以是新工作组的发起人。建立新工作组的具体步骤是，首先要向研究课题所属领域的AD提出申请，经IESG/IAB批准后即可建立兴趣小组(BirdsofaFeather，BoF)，讨论并确定该项技术的主题、内容、范围及期望取得的里程碑。如果BoF认为有必要深入研究，则由BoF的牵头人提出成立工作组的申请，并由IESG和IAB审批。工作组的建立流程如图3所示。

图3 工作组的创立流程

　　参加IETF会议

　　IETF没有会籍，任何人都可以注册和参加IETF会议。IETF每年组织召开3次会议，其惯例是春季在北美、夏季在欧洲、秋季在亚太地区召开。值得指出的是IETF会议的主要目的是交流，会议上做出的决议也可能会在电子邮件讨论组中被推翻。工作组没有正式的投票规则，而是依赖于大致共识。RFC7283指出：“特别是IETF应该不接受‘多数统治’的理念。这就是为什么我们的决策仪式是‘哼唱’而不是投票”（In particular，the IETF is supposed not to be run by a “majority rule” philosophy. This is why we engage in rituals like “humming” instead of voting）。

　　IETF从创立至今，已经举行了107次会议，作为一个技术性很强的研究团体，发展之快、规模之大、工作效率之高，可以说是非常成功的。从第1届到第98届IETF会议参会人数如图4所示。

图4 历届IETF会议的参会规模

　　值得注意的是，从第37届会议（1996年7月）到第57届会议（2003年7月），参会人数达到一个高峰，其间正是2000年前后互联网泡沫的时间，之后参会人数趋于稳定。此外，从第91届会议开始，正式统计了远程参会的人数。随着网络音频和视频应用的发展，远程参会为发展中国家提供了更加经济有效参与IETF的途径。

IETF互联网标准制定规则与现状

　　IETF标准相关的文档包括互联网草案（Internet-Draft，I-D）和征求意见稿。

　　互联网草案

　　任何人都可以提交互联网草案。一篇草案的生命周期为6个月。草案可以在互联网上免费下载。草案是供IETF讨论的文档，不能把草案看作标准、论文或正式的报告。大多数草案并不会成为IETF的RFC。

　　互联网草案的命名惯例为：

　　个人提交的草案：draft-提交人姓名-工作组名称-题目-版本号。

　　工作组草案：draft-ietf-工作组名称-题目-版本号。

　　如果需要在其他互联网草案中引用互联网草案的内容，必须标注为工作进行时（work in progress）。注意当一个互联网草案成为RFC时，其规范引用（Normative References）部分是不能有互联网草案的，仅可以在参考引用（Informative References）部分中使用标注为“工作进行时”的互联网草案。

　　征求意见稿

　　RFC是互联网标准以及IESG、IAB和IRTF等机构发布文档的正式渠道，每个RFC有唯一的编号，RFC可以在互联网上免费下载。RFC的发布由LAB领导，由RFC编辑部直接负责。每篇RFC都有ASCII文本格式。ASCII文本版本是最权威的，它必须是对所描述标准最完整和最精确的详细说明，包括所有必要的图表和图解。

　　RFC分为不同的类型，最重要的是标准RFC，包括最佳实践(Best Current Practices，BCP)、建议标准(Proposed Standard，PS)、草案标准(draft standard，DS)、互联网标准(Internet standard，STD)。

　　STD是互联网标准的最终形式。它的演化进程是从建议标准到草案标准再到互联网标准。由于技术的飞速发展，而从PS到DS到STD的流程相对漫长，因此目前全世界的互联网实际上是基于建议标准(PS)运行的。注意应始终检查RFC的当前状态，然后再作技术决策，因为新的RFC可能会更新(update)或废弃(obsolete)旧的RFC。

　　非标准类RFC包括：信息类(Informational)、试验类(Experimental)、历史类(Historical)。

　　有三个途径能够使互联网草案演进成RFC

　　第一个途径是经过IETF领域下的工作组。以个人名义提交的草案必须属于该工作组宪章（charter）所规定的里程碑(milestone)。经过邮件讨论组和IETF会议中的讲解和辩论，可以寻求工作组的采纳(adoption)，在取得“采纳”的大致共识后，则可成为该工作组的草案。然后经过若干次IETF会议(一般3到5次)和可能的中‘间会议(interim meeting)，以及大量的电子邮件讨论组的讨论，可以进入工作组最后询问(WG last call)，之后可以提交IESG。

　　第二个途径是对于没有相应工作组的文档，经过领域主席(AD)个人提交到IESG。

　　上述两个途径都要提交到互联网工程指导组IESG讨论。IESG首先进行IETF范围内的最后询问，经过多次反馈和修改，得到所有的IESG的成员认可后(no comment)，即可批准。

　　之后将送交RFC编辑部，授予RFC编号，进行文字编辑和格式协定，最终成为RFC发布。

　　从个人提交的草案到工作组草案，到IESG，到RFC编辑部，到最终成为RFC发布，这个过程最快也要2年以上，有时候需要5年，相关流程如图5所示。

图5 IETF文档提交流程

　　第三个途径是针对非IETF提交的RFC，其流程如图6所示。

图6 非IETF文档提交流程

　　如果不同意IETF的任何决议，是可以上诉的。第一级上诉提交到工作组主席，如无法解决则可提交到领域主任(AD)，如仍无法解决则可提交到互联网工程指导组(IESG)，如还无法解决则可提交到体系结构委员会(IAB)。

　　截止到2017年7月3日，IETF已经发布了8000余篇RFC。其时间分布如图7所示。

图7 IETF已发布RFC的时间分布图

　　在这些RFC中，标准系列有263个最佳实践(BCP)，108个互联网标准(STD)，141个草案标准(DS)，3246个建议标准(PS)。非标准系列RFC有2577个信息类（Informational），486个试验类(Experimental)，297个历史类(Historic)，888个未分类(早期的RFC)。其分布如图8所示。

图8 IETF已发布RFC的类型分布图

　　从发布者来看，5585个RFC由IETF发布，67个由IRTF发布，104个由IAB发布，317个是独立提交而发布的，如图9所示。

图9 已发布RFC的发布者分布图

　　从领域来看，有569个RFC是应用领域(app)，有564个是实时应用和基础设施领域(rai)，有109个是实时应用领域(Ort)，有524个是传输层领域(tsv)，有887个是互联网领域（int），有827个是路由领域(rtg)，有503个是安全领域(sec)，有614个是运行管理领域(ops)，有27个是通用领域(gen)。按目前领域分类归并后的分布如图10所示。

图10 已发布RFC的所属领域分布图

　　随着以Linux为代表的开放源码运动越来越广泛和深入的发展，特别是软件定义网络和云计算的发展，参与IETF的志愿者们也在思考RFC标准和开放源码的关系。越来越多的网络协议标准具有开放源码的发布，在Github等网站供下载。

　　IETF近年来力推IETF黑客松(IETFHackathon)目。黑客松又称“编程马拉松”，其灵魂是合作地编写程序和应用。IETF黑客松是标准和开源的结合，其意义在于：通过黑客松开发活动产生的可运行代码，可以促进对IETF标准的完善和改进。

　　IETF关注的是互联网分层模型之间的互操作性(不是一致性)。由于不具备稳定性和规范性，开放的源程序和文档是无法取代RFC标准的。

　　本文节选自2018年1月15日中国计算机学会所发布的《CCF2016-2017中国计算机科学技术发展报告》中“互联网最新研究方向与互联网工程任务组（IETF）”一文的第2部分“IETF组织结构”，作者：李星，徐明伟，崔勇，李贺武，毕军，杨芫，李琦，段海新。

　　参考文献

[1] 许静芳，等. 互联网工程任务组聚焦的前沿技术. 北京：人民邮电出版社出版，2006.

[2] About the IETF [ OL]. https://www.Ietf.org/about/.

[3] Internet Engineering Task Force [OL]. https://em.wikipedia.org/Wiki/Internet_Engineering_ Task _ Force.

[4] P Hoffman. The Tao of IETF： A Novice's Guide to the Internet Engineering Task Force [ OL]. The Internet Society, 2006. https：//tools, ietf. org/rfcmarkup? doc = fyi17.

[5] IESG agenda [ OL]. https：//datatracker. ietf. org/iesg/agenda/.

[6] RFC Editor [ OL] https：// www. rfc-editor, org/.

[7] Document Search [ OL], https ：//datatracker. ietf. org/doc/.

[8] IETF document statistics (active I-Ds) [ OL]. http：//Www..arkko..com/tools/stas/

[9] IETF Meeting Proceedings [ 0L]. https ::〃www. ietf. org/meeting/proceedings. html.

[10] Areas [ OL]. https：//www. ietf. org/iesg/area. html.

[11] Area Overview Tutorials [ OL]. https：//www. ietf. org/edu/area- overview- tutorials. html#art.

[12] Sameer G Kulkarni, Wei Zhang, Jinho Hwang, et al. NFVnice：Dynamic Backpressure and Scheduling for NFV Service Chains [ C] //Proceedings of the 2017 conference on ACM SIGCOMM 2017 Conference. ACM, 2017.

[13] Pamela Zave, Ronaldo A Ferreira, X Kelvin Zou, et al. Dynamic Service Chaining with Dysco[C]// Proceedings of the 2017 conference on ACM SIGCOMM 2017 Conference. ACM, 2017.

[14] Hartert R, Vissicchio S, Schaus P, et al. A Declarative and Expressive Approach to Control Forwarding Paths in Carrier- Grade Networks [ C]//Proceedings of the 2017 conference on ACM SIGCOMM 2017 Conference. ACM, 2017.

[15] Steven Gay，Renaud Hartert，Stefano Vissicchio. Expect the Unexpected Sub-Second Optimization for Segment Routing[C]//IEEE INFOCOM 2017-The 36th Annual IEEE International Conference on. IEEE, 2017：1-9.

[16] Aubry F, Lebrun D, Vissicchio S, et al. Scmon：Leveraging segment routing to improve network monitoring [ C] //1HEE INFOCOM 2016- The 35th Annual IEEE International Conference on. IEEE, 2016:1-9.?

[17] Kim H S, Pack J, Bahk S. Transmission Power Control in IPv6 Routing Protocol for Low-Power Wireless Network[C]//SenSys. 2016: 334-335.

[18] Yu Sang, Bo Ji, Gagan R Gupta, et al. Provably Efficient Algorithms for Joint Placement and Allocation of Virtual Network Functions [C]//UEEE INFOCOM 2017-The 36th Annual IEEE International Conference on. IEEE, 2017:1-9.

[19] Ye Z, Cao X, Wang J, et al. Joint topology design and mapping of service function chains for efficient, scalable, and reliable network functions virtualization [ J]- IEEE Network, 2016, 30(3) : 81-87.

[20] Jingyuan Fan, Chaowen Guan, Yangming Zhao, et al. Availability-aware Mapping of Service Function Chains] C]//IEEE INFOCOM 2017-The 36th Annual IEEE International Conference on. IEEE, 20!7: 1-9.

[21] Yang Wang, Zhenyu Li, Gaogang Xie, et al. Enabling Automatic Composition and Verification of Service Function Chain [ C] //Quality of Service (IWQoS), 2017 IEEE/ACM 25th International Symposium on. IEEE, 2017 :1-10.

[22] Ying Zhang, Wenfei Wu, Sujata Banerjee, et al. SLA-Verifier: Stateful and Quantitative Verification for Service Chaining [ C] //EE INFOCOM 2017 -The 36th Annual IEEE International Conference on. IEEE, 2017: 1-9.