独特的IETF：互联网标准产生机制揭秘-中国教育和科研计算机网CERNET

资讯

校园信息化

技术

资源与应用

产品与装备

信息服务

首页 > 教育信息化 > 专题报道 > 互联网技术探究

独特的IETF：互联网标准产生机制揭秘

2022-10-10 中国教育网络

　　中国作为世界大国和网民最多的国家，更需要积极参与IETF，培养大量互联网人才。

2019年IETF会议

　　最近，IETF新成立一个工作组——SAVNET（互联网自治域内和自治域间的源地址验证）工作组，这也是我国科研人员首次在IETF的路由域发起成立工作组。

　　IETF是全世界最重要的互联网技术标准机构。它的使命是通过出版高质量的技术文档（RFC文档），影响人们设计、运行、使用和管理互联网的方式，使互联网能更好地运作。

　　IETF的研究从大方向上主要分为应用、互联、运行、路由、安全和传输6个领域，其中路由领域是技术难度最大的领域之一。此次SAVNET工作组的成立有两个层面的意义：第一，研究方向看得准。对科学研究来说，提出一个好问题，就意味着新的价值。从发起BOF小组到成立正式的工作组，SAVNET只历经三个多月，非常顺利，这说明工作组要解决的问题得到了IETF的广泛认同。第二，标志着我国在路由安全和安全可信的下一代互联网体系结构方向上，已处于国际领先地位。

　　IETF工作组的形成

　　以SAVNET为例，我们来看看IETF的工作组是如何成立的。

　　工作组的形成，一般要经历如下流程：先是有意愿建立新工作组的人向研究课题所属领域主席提出申请，经互联网工程指导委员会（IESG）和互联网体系结构委员会（IAB）批准后，召开BOF小组讨论会(Birds Of a Feather，即“志同道合”之意)。

　　在BOF小组会议中，讨论并确定研究问题的内容、范围及期望取得的成绩。如果参会人员普遍认为该研究具有一定价值，那么BOF领头人可以提出申请，经IESG和IAB同意后正式成立工作组。

　　BOF会议的目的可以是讨论工作组成立与否，也可以仅单纯讨论某个问题。BOF会议能否举行由IETF的相关领域负责人决定，一般针对某个话题的BOF会议最多不超过两次，如果没有达成共识则必须放弃。

　　工作组的成立，源头都是一个待解决的问题，而这也是工作组的意义所在——把有价值的问题抛出来，让大家集中精力、全力以赴进行研究。

　　这里还有一个思维上的差异，清华大学李星教授在2013~2015年间担任IETFIAB的委员，他提到，在创建工作组之后，中国工程师往往在问题描述阶段就想给出Solutions（解决方案）；但是IETF的模式是大家对于问题描述有了共识之后，再竞争解决方案。各个参与者竞相提出自己的解决方案，然后选择最有“共识”的那一个。所以，这也充分体现了标准的竞争性。李星教授表示，“必要时协作，可能时就竞争。经过竞争打拼出来的标准才具备生命力。”当一个工作组完成工作组宪章中的所有“里程碑”文档后，工作组就可以宣告使命的完成。

　　当然，工作组成立后，也可能在不断实践中发现成立时提出的问题无法解决。但这种发现也有特定的价值。正因为一次次的碰壁与不停地尝试，才会有少数的道路被打通。当IETF的主席问，IETF能为互联网做点什么时，有位工程师回答：“在IETF开发的1000个解决方案中，有一个是有用的。”而这一个有用的，就是真正解决了大问题的方案。

　　从草案到RFC

　　那么，IETF的标准是如何产生的？经历了怎样的过程才能成为有效、确定的标准呢？

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

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

　　工作组是产生RFC的首要途径，通常要经历以下几个流程：（1）个人提交草案；（2）工作组认领草案；（3）工作组反复迭代讨论；（4）工作组“最后询问（Last Call）”；（5）IETF“最后询问”；（6）IESG内部讨论；（7）IESG批准；（8）获得RFC编号；（9）RFC文字编辑；（10）正式发布。

　　其中最大的难点是工作组认领草案。那么，哪些个人草案能入IETF的法眼？RFC7221对工作组主席是否考虑认领某一草案提供了具体建议：

　　1.草案必须符合工作组目前的章程，或者只需对章程作简单修改。

　　2.草案的目的应该明确。

　　3.草案应该是有用的。

　　4.文档的写作质量应足以作为进一步工作的基础。

　　5.不应有强烈的技术异议。

　　6.相关知识产权信息的披露都应是可接受的。

　　7.该工作不应与IETF中其他工作冲突。

　　2020年，一个在两年中不断更换工作组提交草案的作者写信给IETF，抱怨说，他提交的草案非常好，只是自己不是程序员，无法验证其中的想法，就没有工作组认领，并且得不到IETF的重视。IETF则回信说，建议他先证明这些提议是可以实现的，写文档说明草案的工作原理。同时建议他倾听和处理别人的意见，尤其是被他人多次提出和讨论的问题。从这一故事中，可见IETF对草案的基本要求之一就是可操作。

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

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

　　从个人提交草案到工作组草案，再到IESG、RFC编辑部，直到最终成为RFC发布，整个过程最快也要2年以上，有时则需5年。从草案到标准，全程记录邮件收发并公开会议记录。“如果你要在互联网上做点事，就要做到透明开放，就得经得起考验。”李星教授说。

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

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

　　李星教授将标准的价值总结为几条：第一，解决的问题很重要；第二，技术要简洁优雅；第三，可以逐步地部署；第四，实现代码的使用不受限制。最后，要取代已有标准，该技术必须值得部署实施，例如一项新技术若仅能改善10%的性能就难以成为RFC。

　　IETF的“哼哼”原则

　　与国际电信联盟等相关组织不同，IETF的参与主体是工程师个人，不代表其所在国家或企业，而这也是IETF的活力所在。

　　IETF有一句格言：“我们拒绝国王、总统和选举。我们相信大致共识和可运行的程序。”对于IETF来说，“你是谁并不重要，只要得到大多数人的赞同，或者代码成为可运行的程序，你的标准就有可能成为整个互联网的标准”。

　　“大致共识和可以运行的程序”，也就是在实践中可以行得通的方案，李星教授认为，这一思想相当于“实践是检验真理的唯一标准”。

　　IETF也不用投票方式进行表决，他们采用“哼哼”声。IETF互联网国际标准RFC6531第一作者姚健康博士分享他的工作体验时说到：IETF开会时，参会者通常穿着带有IETF标识的T恤，有的穿着短裤，或者边讨论边织毛衣。表决时通常不举手，鼻子里哼哼两声就表示同意。所以一个技术方案通过与否，往往取决于“哼哼”声的大小。而我们也能看出，“哼哼原则”本质上是实用与开放原则，表现了IETF秉持的“大致共识”的理念。

　　在IETF的会议和邮件讨论组中，不管你是知名的互联网技术专家、位居高职的管理者，还是初出茅庐的技术新人，大家都是平等的，谁都有机会排队到麦克风前去陈述自己的观点，关键在于你的观点是否靠谱。

　　最后，对我国科研人员来说，参与IETF十分重要。中国作为一个世界大国和网民最多的国家，更需要积极参与IETF，培养大量互联网人才，在未来的技术研究和政策制定中占据主动地位，贡献中国方案。

　　虽然近几年有越来越多的中国科学家和企业界代表参与IETF，但总体来看，还不够。李星教授总结说，参与IETF的工作，第一，要解决真实问题；第二，要聚焦关键问题；第三，要全局考虑；第四，要通过邮件交流、交朋友，鼓励年轻人参与;最后，还要乐在其中！

　　作者：王雅静

　　责编：项阳

　　特别声明：本站注明稿件来源为其他媒体的文/图等稿件均为转载稿，本站转载出于非商业性的教育和科研之目的，并不意味着赞同其观点或证实其内容的真实性。如转载稿涉及版权等问题，请作者在两周内速来电或来函联系。