2025年12月16日，在中国教育和科研计算机网CERNET第三十一届学术年会上，曾任IESG应用领域主管、IAB成员、APEX工作组主席，现IETF申诉委员会成员Pete Resnick作了题为《互联网工程任务组（IETF）及其伙伴机构：简介与内部信息》的特邀报告。

　　他介绍了互联网工程任务组（IETF）的历史、职能和组成结构，IETF的伙伴机构——互联网研究任务组（IRTF），IRTF的工作机制，IETF与IRTF当前的重点工作，以及如何参与IETF和IRTF的工作，以下是Pete Resnick报告的具体内容。

　　IETF的历史

　　1986年，IETF成立了。最初是由美国互联网活动委员会发起的，受到了美国联邦政府的资助。后来，互联网架构议题被分离了出来，专门进行早期的互联网工程研发。

　　1986年1月16日，IETF在美国圣地亚哥召开了首次会议。在21位与会者中，部分人至今仍活跃在IETF组织中，其中就包括了来自哈尔滨，当时在麻省理工学院的博士生张丽霞。

　　1992年，IETF正式建立标准制定流程，不再依赖美国联邦政府资助，并将原“互联网活动委员会”更名为“互联网架构委员会”，会议的频次由每年四次调整为三次。

　　2010年，IETF第79届会议在中国北京举办，这是IETF第一次来中国大陆召开会议；而IETF第125届会议将于明年3月在深圳举办，这也将是IETF第二次来到中国大陆。

　　IETF的组织架构

　　IETF的主要工作单元是工作组（Working Groups）。每个工作组需要遵循章程以明确工作范围、目标和现实，各工作组设有主席，负责组织协调工作。IETF的工作组隶属不同的技术领域，目前共设有7个领域，134个工作组。

　　IETF的7个技术领域包括应用与实时领域（ART）、通用领域（GEN）、互联网领域（INT）、运营与管理领域（OPS）、路由领域（RTG）、安全领域（SEC）、Web与传输领域（WIT）。每个技术领域都设有1~3名领域主管，负责工作组的设立与章程的制定、任命与管理工作组主席，协调工作组成员和工作组主席之间的争议，以及对本领域所有文档进行最终技术审查等工作。所有的领域主管共同参与对IETF文档的审批工作。

　　互联网工程指导组（IESG）由全体技术领域主管组成，负责发布IETF范围的最终征询。IESG对所有IETF文档与工作组章程拥有最终审批权，每两周举行一次正式的远程电话会议，并受理针对工作组及IESG决议的上诉。IETF主席同时兼任通用领域主管与IESG主席。

　　互联网架构委员会（IAB）独立于IETF，由12名成员及IETF主席组成，负责监督IETF的流程与治理、任命或确认社区内其他职务，并负责举办技术研讨会、撰写技术指导性文件等工作。

　　IETF社区的其他组成部分

　　互联网研究任务组（IRTF）专注于长期、前沿的互联网技术研究。IRTF的主席由IAB任命，下设研究组，其生命周期比工作组更长，主要以信息类与实验性文档形式产出学术论文，并不制定正式标准。

　　IRTF每年举办ACM/IRTF应用网络研究研讨会，并设有年度“应用网络研究奖”，奖金1000美元，获奖者可于应用网络研究研讨会（ANRW）进行学术报告。

　　最早的RFC（互联网标准文档）始于1969年，被称为征求意见稿（Request for Comments），最初是ARPANET项目的工作笔记，也是历史上首个在线发布的文献系列。虽然现在仍沿用“Request for Comments”之名，但已不再只是“征求意见稿”的字面意思了。

　　RFC分为IETF标准类文档，IETF最佳实践类文档，IETF、IRTF及IAB的信息类文档，IETF与IRTF的试验类文档及其他类别。这些文档系列由RFC编辑中心负责维护，并承担最终文稿的文字编校以及收录全部文档的官方网站的运营工作。

　　每届IETF会议前的周六和周日都会举行黑客马拉松（Hackathon），主要目标为实施与测试IETF协议，并将结果反馈至相关工作组。黑客马拉松为技术人员提供交流平台，吸引新参与者，起到了促进开源和推动学术合作的作用。任何人都可以参与黑客马拉松，每个项目由一位负责人带领，项目成果在周一的IETF会议中进行展示。

　　IETF的工作机制

　　IETF的所有文档最初都以“互联网草案（I-D）”的形式发布，在工作组完成技术任务后，互联网草案将经历多轮评审，各方一致批准后才会正式成为RFC。全部文档（I-D、RFC、章程等）都由IETF Datatracker统一归档，可公开查询。

　　IETF的具体工作流程如下：工作组主席为每份草案指定一名文档编辑全程负责文稿技术内容与进度。工作组技术研讨在专用的邮件列表开展，工作组可在全体会议期间集会，却不作最终决议。邮件列表持续讨论直至形成共识，由主席研判确认后将文档报送领域主管。领域主管对工作组文档进行全面技术审查，审查通过后发起最终征询，并将文档提交IESG评估。IESG在例行远程会议（telechat）中集体审议并确认结论，最终正式批准。

　　IETF的独特之处

　　IETF与其他标准组织有所不同，主要体现在以下几个方面。一、IETF的标准不含实施细则，并不是“一致性”规范，而是自愿采用。二、IETF不设会员身份，成员以个人身份参与。三、IETF不举行投票，依靠“基本共识”决策。四、IETF不在会议现场做出决议。

　　与多数标准组织将实现要求纳入标准有所不同，IETF原则上不提供实现指导。仅规定网络交互行为，用户界面与配置选项通常属标准范围之外，即便使用“必须（MUST）”“应当（SHOULD）”等强制性措辞，RFC2119也明确指出，“这类措辞要谨慎、节制，仅在确保互通或防范潜在危害时才可使用，绝不能借其向实现者强加非互通所必需的特定方法。”IETF认为，实现固然重要，但并不属于标准本身。

　　IETF以互通为本，不求一致，不同于其他标准组织大多将一致性置于核心。IETF只关注独立实现能否互通，“必须/应当/可以”等强制性词汇只服务于互通需求，遵循自愿原则，使用这些词语的意义仅仅在于“若期望互通，请依此施行”。

　　IETF没有设置会员机制。参会者不等于会员，且不设会费，参会无需签署任何协议。任何个人都可以直接参与IETF，并且仅以个人身份出席，不代表所在公司或机构。在IETF中，公司或政府不享有表决权。IETF的参与权完全开放，任何人都能平等发声，且意见权重相同。

　　与多数标准组织均在会场举行正式投票不同，IETF的决策并不是在现场做出的。这也是由于IETF没有会员制度，参与完全开放，因此难以界定谁有表决权。IETF的目标在于获得最佳技术方案，而投票往往只能产生“最受欢迎”的结果。且会场决策也存在弊端，因为并非所有人都能亲赴IETF会议。IETF预留充分的时间供各方就异议展开讨论，意见通常以邮件列表留言或会场发言的形式提交。IETF主席与领域主管在邮件列表上形成最终决策，不依赖现场投票。

　　IETF基本共识的决策模式力求让各方广泛认同，并对无理阻碍保留否决权。所有异议都要被充分回应并审议，但未必全被采纳，衡量的标准不是人数，而是待解决问题的数量，且牵头人要判断异议是否已妥善解决。实时讨论中达成的共识并不是最终决议，每份文档都要获得整个IETF的基本共识，而即使绝对多数成员达成的共识也不等同于基本共识。也正因如此，基本共识被视为IETF的最佳方案。

　　值得关注的工作方向

　　在IETF的134个工作组中，有几个工作组尤为值得关注。

　　人工智能偏好（AIPREF）工作组隶属Web与互联网传输（WIT）领域。AIPREF工作组旨在设计一种机制，用于声明网站数据如何被AI使用，其功能类似“robots.txt”，但复杂度更高，且争议颇多，例如何既表达“请勿使用我的数据”，又能实现“用户辅助”功能？

　　域名密钥识别邮件（DKIM）工作组近期已重新立项，旨在强化反垃圾邮件机制。DKIM工作组制定了新协议，支持在多个转发跳点中对邮件进行签名；为了防范回复攻击，可对预期收件人进行签名；为了防止退信垃圾邮件，还支持对退信地址进行签名；并允许检测转发过程中的轻微修改（如经转发器等）。

　　IRTF还成立了互联网去中心化研究组（DINRG）。这个工作组致力于探究互联网中心化的成因，量化中心化程度并评估其社会影响，研发去中心化系统与应用程序，并记录研究成果。在上届会议中，有关AWS与Cloudflare服务中断及其网络级影响的回顾报告尤为精彩。

　　成为IETF的一员

　　在报告的最后，Pete Resnick呼吁广大网络运维人员、开发者、研究人员共同参与IETF的工作。

　　对于网络运维人员而言，可以寻找正在制定所用协议的IETF工作组，开始阅读感兴趣的工作组互联网草案，并加入邮件列表结合实践经验提出建议，并在线上或现场参会。

　　对于开发者而言，可以关注刚开始研究的工作组课题，现场或远程参加黑客松，加入编码项目。

　　对于研究人员而言，可以寻找与研究方向相符的IRTF研究组，线上或线下参加会议，并向应用网络研究研讨会（ANRW）投稿论文。