认识互联网工程任务组（IETF）

共同规范帮助独立建造的系统彼此协作。规范是否有用，取决于人们能否实现并测试它们。

你的浏览器可以打开一家位于世界另一端、由某家公司运营的网站。浏览器、服务器以及它们之间的网络，可能来自不同供应商。它们之所以能够协同工作，其中一个原因是工程师已经约定了各自系统交换信息的方式。

互联网工程任务组，即 IETF，制定了许多这样的技术规范。它的工作帮助独立建造的系统彼此协作。这引出了一个有用的问题：共同规则如何让全球网络成为可能，同时又让参与者保持独立？

IETF 实际上做什么

IETF 自己的介绍把它描述为一个开放的标准社区。人们以个人身份参与，包括通过工作组邮件列表参与。他们研究技术问题、讨论提案，并制定其他人可以实现的规范。如果你要寻找该组织的官方网站，这个链接会带你到那里。

可以把规范想成一套共享的说明。不同公司可以据此建造自己的产品，然后检查这些产品是否能够协同工作。规范的价值，在于让跨越组织边界的通信成为可能。

RFC 是文档，不会自动成为标准

许多读者第一次接触 IETF，是从一个 RFC 编号开始的。RFC 是 Request for Comments（征求意见稿）的缩写，这是一个用于已发布文档系列的历史名称。正如IETF 的 RFC 指南所说明的，这个系列包括标准、当前最佳实践、实验性工作和信息性文档，也包括来自 IETF 之外其他发布渠道的出版物。

在说“标准要求这样做”之前，应当检查文档的状态，以及后来的文档是否更新或取代了它。一项提案成为已发布的 RFC，本身并不会把其中每一个想法都变成普遍要求。

共识应当如何形成

IETF 的传统把工程判断与实际运行的实现经验结合起来。它对粗略共识的解释强调要考虑技术反对意见，包括少数意见。数支持者的人数，不能代替对设计问题本身作出回答。

IETF 的使命声明还作出了一个重要区分：标准描述如何一致地完成某件事；IETF 并不会因此强制要求或监督人们使用它。采用会赋予规范实际影响力；仅仅发布文档，并不会赋予一个组织支配互联网的权力。

Lu Heng 划出的边界

在讨论“运行中的代码优先”的第 65 号笔记中，Lu Heng 借助这一工程传统，质疑区域互联网注册机构所声称的权威。他批评的是：当管理编号资源记录的工作变成对依赖这些记录的网络施加权力时，会发生什么。

这个区别很重要：编写协议规范，与管理运营商的地址记录，是不同的职能。开放的技术讨论可以产生有用的工程成果。但在 Lu Heng 的论证中，它不能凭空获得治理那些并未授权它扮演这一政治角色的运营商的权力。

他提出的方向，是建立一套网络能够自行核验的协调系统。共享记录和少量共同规则可以防止重复使用，确立谁控制哪些资源，并保护安全。例如，参与者可以根据公开规则核对地址转移，而不必依赖注册机构的酌情批准。

运营商今后的选择，应通过它们运行的代码以及它们采用的变更来作出。选择不兼容的规则，可能限制哪些网络能够彼此协作；他的提议让这一边界保持可见，而不是把分歧转化为行政惩罚。

为什么要在危机之前弄清这个区别

当网络依赖某个机构的认可时，恰恰在连续性最重要的时刻，替换这种依赖会变得困难。Lu Heng 主张尽早把可核验的记录和独立验证写进设计，使协作能够经受住某个机构的失灵或被控制。

下一个问题很具体：运营商应当能够依赖什么，而协调机构永远不应取得什么权力？可以从较短的第 72 号笔记《唯一性协调权利法案》开始。