摘要

  • RFC 5226 中的指定专家只受托回答某一项分配是否应当发生；专家不是命名空间所有者，IANA 不是政策作者，邮件列表的参与者也不会因为发过言而获得决策授权。
  • 现行后继文件 RFC 8126 把这份授权写得更完整：申请材料、判断标准、拒绝理由、利益冲突与回避、替补、条目变更权、所审版本以及正常申诉路径都应当可见。
  • 一个被分配的代码点只能证明特定版本的申请在特定时刻通过了特定程序；它不能证明产品安全、实现完成、部署发生或运行效果良好。

一封只有抬头、没有正文的任命书

设想一个用于检验制度的虚构场景。某协议创建新注册表，只写下一句“Expert Review”。IESG 任命了一位经验丰富的工程师。第一份申请到达后，专家要求威胁模型、两个独立实现以及不会过快耗尽稀缺区间的证明。每一项要求都可能很有工程价值。但创建注册表的文件从未规定这些材料；数月后，另一位申请者面对的清单又不一样。

这里不需要出现恶意，程序已经产生问题。第一位申请者无法在投入之前知道举证责任，第二位申请者也无法确认自己会受到同样对待。机构完成了“找谁审”的任命，却没有完成“依据什么审”的授权。

RFC 5226 于 2008 年 5 月作为 BCP 26 发布。它最重要的克制之一，是明确 IANA 并不创造分配政策；IANA 执行的是其他主体制定并通过 RFC 公布的政策。纯文本版本 可以完整追踪这条委托链。Datatracker 页面、RFC Editor 状态页、文件历史与勘误索引还说明一个时间事实：RFC 5226 已是历史文件，2017 年由 RFC 8126 取代。

因此，真正的问题不是“这位专家是否值得尊重”，而是制度能否回答：专家有权要求哪些材料、什么缺陷足以拒绝、审的是哪个版本、冲突如何处理、结论如何被挑战。

一行记录周围其实站着四种角色

注册表把复杂制度压缩为一行，容易让人误以为所有权力都在同一个地方。实际上，定义 RFC 确定命名空间、申请字段、审查方式、条目格式和初始保留值。IANA 接收申请并记录结果。对于 IETF 流的注册表，IESG 任命专家并在必要时更换。专家协调技术审查，就特定分配给出建议。申诉程序再约束这项委托。

IANA 的协议注册作者指南要求作者指明准确的注册表、规范引用和所需字段；协议注册申请页面要求申请人先确认相应程序。Datatracker 对IANA review 状态的说明则展示了文件处理中的一个操作环节。这些界面很重要，但它们不应悄悄成为未公开的实质规则。

把角色混为一谈会造成三种权力漂移。操作方会被当成政策作者；专家的个人偏好会被当成规范要求；开放讨论会被包装成授权来源。审计时应把三个问题分开：谁制定规则，谁管理请求，谁作出技术建议。

工作组不能永久值班

为什么不让邮件列表长期决定？因为讨论能够汇集知识，却未必能够结束。IANA 既不能监视每个列表，也不应替社区判断何时已经形成明确结论。工作组还会解散，而注册表可能继续使用几十年。

RFC 2418交代了工作组的生命周期。RFC 7282所说的粗略共识，是认真处理技术反对意见，而不是点人数。RFC 3935把对互联网运行有用的工程工作放在 IETF 使命的中心。这些文件都没有把已经关闭的工作组、最响亮的发言者或一次表决变成永久法院。

指定专家解决的是“如何得到一个明确答复”。IANA 把可识别的申请交给审查者；审查者可以咨询相关专家、公共列表、仍在运行或已经关闭的工作组社区，然后交回一项清楚的建议。专家更像审查协调者，而不必假装掌握所有知识。

但这种授权很窄：它只覆盖“依注册表规则是否应分配”。专家不会因此拥有整个命名空间，也不会获得认证产品、批准部署或评价运营结果的权力。

“专家审查”是路线名称，不是判断公式

最关键的一句话不是“由专家审查”，而是“专家按照以下标准审查”。

RFC 5226 已要求专家能向 IETF 社区解释自己的决定，并强调审查不应秘密进行，也不应赋予不受质疑的权力。理想情况下，标准应随协议一同记录。如果文件没有提供具体标准，则倾向于分配：除非存在有说服力的拒绝理由。

现行后继文件 RFC 8126把这套约束写得更加直接。纯文本要求说明申请者必须提供的信息、专家应当评估的事项以及拒绝原因。Datatracker 版本、状态记录、历史页面和勘误页共同保存了它作为当前 BCP 26 的文献状态。

合理拒绝理由有边界。例如，可用代码点非常稀缺；文档含糊到无法判断互操作性；扩展严重违背基础协议架构或安全模型；它会伤害已部署系统；或者它与 IETF 的活跃工作冲突并造成互操作风险。个人审美、对申请者的印象或临时提高的门槛不能冒充这些理由。

这意味着，模糊文件并没有给专家“为了安全可以多做一点”的无限空间。恰恰相反，标准越含糊，严格拒绝的授权基础越弱。如果制度确实需要两套实现、公开安全分析或使用证明，就应在第一位申请者出现之前公布。

没有理由的“通过”也无法长期使用

队列只需要一个是或否，制度记忆却需要更完整的对象。可辩护的记录至少应当说明：申请的精确版本、收到的证据、适用标准的版本、咨询过程、冲突披露以及建议理由。

版本尤其容易丢失。对版本 N 的认可不等于对后来 N+1 的空白授权。如果行为、安全属性或语义有实质改变，原来的结论可能已经不再附着于同一个对象。RFC 8126 明确承认专家审查发生在一个时间点，并针对某个文件版本；重要修改可能需要重新审查。

理由记录也保护专家本人。没有它，每次接受都可能被解释为偏袒，每次拒绝都可能被描述为阻挠。有了它，社区才能判断争议究竟来自资源稀缺、文档不清、互操作损害、安全模型冲突，还是未经授权的个人偏好。

一个便于核查的“五联单”可以绑定：申请版本、提交证据、标准版本、含冲突状态的理由化建议，以及注册表动作与后续变更历史。这是 Daniel Kade/BTW 的分析框架，不是 RFC 规定的数据结构。它的目的，是在人员更替后仍然保留决定的来路。

回避不是对专业能力的不信任

技术圈越小，最了解问题的人越可能同时拥有利益关系。他可能撰写了申请规范、公开推动过某个方案，或服务于受影响的实现者。沉默不会消除冲突，只会让冲突难以辨认。

RFC 8126 要求有冲突的专家回避。若专家池全部存在冲突，应请求临时专家；负责的 Area Director 可以任命临时人员或直接处理审查。专家失联时可以替换，由 IESG 任命的专家也可由 IESG 移除。

多人专家组同样需要出口。如果意见不一，应向 IANA 交付一项统一、清楚的建议，而不是让登记操作方在技术争论中裁判。僵局需要由任命方处理。

最后还有申诉。RFC 2026所定义的正常路径先到 IESG，必要时再到 IAB。申诉并不是对专家的侮辱；它证明专家建议处在更大的委托结构中，而非个人不可触碰的领地。

分配发生之后，变更权才开始重要

申请结束后，注册表行还会继续存在。联系人需要更改，引用需要更新，条目可能被标为废弃或过时。RFC 8126 因而建议在 First Come First Served、Expert Review、Specification Required 等政策下记录变更控制者。

首次取得代码点的人不一定有权多年后重新定义它；首次审查的人也不会自动成为所有后续编辑的所有者。变更权必须明确，历史则应保留。即使条目过时，注释通常也比删除更有协调价值，因为历史能阻止旧值被误认为从未使用。

RFC 7120处理进行中工作的临时早期分配。临时坐标让实现者能够实验，却不把尚未完成的标准化包装成最终批准。临时、永久、废弃、过时是制度状态，不是装饰标签。

相似标签交付的证明并不相同

RFC 5226 继承并修订了 RFC 2434的政策词汇。这些名称不能被排列成一条简单的“质量等级”。

First Come First Served 没有实质技术审查，只确认申请完整且不重复。Expert Review 增加一位按公布标准工作的指定审查者。Specification Required 还要求一份稳定、永久公开、足以让他人独立实现互操作的规范。RFC Required 要求 RFC，但若未进一步限制，可以涵盖不同文档流和状态。IETF Review 则要求经过 IESG 路径的 IETF 流 RFC。

所以，Expert Review 分配不是产品证书；RFC Required 不必然表示 IETF 标准；IETF Review 也不能证明已有部署或互操作。每一种程序只能证明自己的窄事实。

Lu Heng 的论述为这种克制提供了更广的制度坐标。《The Multi-Stakeholder Mirage》区分参与和授权。《Minimum Initial Specification》主张共同层只写最低限度，把后续选择留给掌握现场信息的人。《When the Bookkeeper Auditions for Olympus》警惕记录者把操作职位抬升为最高权力。《Running-Code Primacy》则把规范、注册符号、实现和实际运行结果分开。

指定专家在这些边界内最有价值：能够防止冲突与有害扩展，又不会把一个协调岗位夸大成对下游世界的统治。

来源

  1. RFC 5226
  2. RFC 5226 纯文本
  3. Datatracker 上的 RFC 5226
  4. RFC 5226 状态
  5. RFC 5226 历史
  6. RFC 5226 勘误
  7. RFC 8126
  8. RFC 8126 纯文本
  9. Datatracker 上的 RFC 8126
  10. RFC 8126 状态
  11. RFC 8126 历史
  12. RFC 8126 勘误
  13. IANA 协议注册作者指南
  14. IANA 协议注册申请
  15. Datatracker IANA Review 状态
  16. RFC 7120
  17. RFC 2026
  18. RFC 2418
  19. RFC 2434
  20. RFC 3935
  21. RFC 7282
  22. Lu Heng — The Multi-Stakeholder Mirage
  23. Lu Heng — Minimum Initial Specification
  24. Lu Heng — When the Bookkeeper Auditions for Olympus
  25. Lu Heng — Running-Code Primacy