摘要

  • RFC 8126 为 IANA 管理的协议注册表规定了十种登记政策；其中 Private Use 与 Experimental Use 两类，IANA 根本不记录任何取值。
  • 异议一侧的时钟是固定的：必须在决定公开后两个月内启动上诉。裁决一侧的时钟是敞开的：「合理的期间」，没有统一期限，而「可预期」被定义为不出现意外步骤，不是承诺若干天内出结果。
  • IAB 可以撤销 IESG 的决定、恢复原状，却不能作出属于 IESG 权限的决定，所审阅的条文也没有明示授权它命令完成登记。而 IESG 恰恰是任命、并可自行裁量撤换被质疑专家的一方。

先从一份申请说起，而不是先讲原则。有人想把某个取值写进 IANA 管理的协议注册表。注册表、字段名称和适用政策是三件不同的事，IANA 自己的指引把话说明白了：页面显示修订日期为 2026 年 7 月 13 日，同一注册表内的不同区段可以采用不同的登记程序，因此仅凭注册表名称不能确定规则（IANA, Guidance for RFC Authors）。同一页面要求申请人指明确切的注册表并提交所要求的字段信息，并提醒该注册表的引用 RFC 可能要求一份模板，包含注册表页面上根本看不到的字段。

谁真正作出决定，由文件而非惯例定下。2020 年 2 月发布的 IAB 信息性文件 RFC 8722 把注册表运营方的职责定位于按 RFC 定义的准则和程序、以及适用的注册表政策来登记参数，遇到歧义应提交澄清（RFC 8722, §2.1）。同一文件把技术判断从运营方肩上移开：「the Registry Operator will seek and follow technical guidance exclusively from the IESG」，技术评估一般而言不属于运营方的职责（RFC 8722, §2.3）。注册表运营机构本身的任命或终止属于 IAB 与 IETF LLC 共同处理，这与任命具体专家是两回事（RFC 8722, §2.2）。

政策菜单是一个封闭的十项集合。2017 年 6 月发布的 RFC 8126 列出 Private Use、Experimental Use、Hierarchical Allocation、First Come First Served、Expert Review、Specification Required、RFC Required、IETF Review、Standards Action 与 IESG Approval（RFC 8126, §§4.1–4.10）。其中两类按设计保持沉默：Private Use 与 Experimental Use 的取值，IANA 一概不记录。Specification Required 在 Expert Review 之上加了一道文件门槛——永久、可公开获取、清晰且技术上站得住脚、足以支撑独立互操作的规范，并不要求必须是 RFC（RFC 8126, §4.6）。

注册表若已公布准则，专家就照准则办。若无准则，RFC 8126 要求专家评估文件的完整性、互操作性与冲突情况，并在没有重大反对意见时推定予以登记（RFC 8126, §§5.1–5.3）。拒绝有明确列举的理由：资源稀缺、文件不清、有害的架构或部署影响、与 IETF 工作存在有害冲突，除此之外没有列出其他理由（RFC 8126, §5.3）。

接下来是时钟。1996 年 10 月发布、至今仍是程序兜底的 RFC 2026 这样写，也是这个意思：「All appeals must be initiated within two months of the public knowledge of the action or decision to be challenged」（RFC 2026, §6.5.4）。同一节要求裁决者遵守程序、在「合理的期间」内作出决定并告知，却不提供任何统一的固定期限。IAB 关于 IANA 注册表运行的原则换了个说法讲同一件事：可预期的处理指的是不出现意外步骤，而不是保证专家决定落在预先规定的天数之内（RFC 8720, §3.1）。把这两条并排读，浮现出一种表面上的不对称：有怨的一方被计时，执笔的一方没有被给出任何数字。至于这是否出于刻意起草，本文不认定。

链条从拒绝发生的地方开始。RFC 8126 把针对登记决定的异议先引向 IESG、再引向 IAB，并对涉及专家组的争议适用 RFC 2026 §6.5.1 的争议程序（RFC 8126, §10）。这套被援引的程序依次经过工作组主席、负责的领域主任、完整的 IESG，再到 IAB；每一层都必须复核并尝试解决，IAB 在程序合规与技术优劣上为终局（RFC 2026, §6.5.1）。一旦认定存在程序失败，IESG 重新审视自己的行动并向 IETF 报告；IAB 可以撤销 IESG 的决定、恢复原状，或提出建议，但不能作出属于 IESG 权限的决定（RFC 2026, §6.5.2）。

这最后一句话的分量超过它的长度，而由此得出的结论属于本文的解读，不是任何一份文件写下的句子：如果所审阅的链条中可确认的最强结果只是撤销并恢复原状，而顶端又不能作出属于 IESG 权限的决定，那么所审阅的条文并未明示授予命令完成登记的权力。这留下了几种可能：提出建议、撤销后重新审议，或依个案另行走向登记。撤销不等于命令。申请人可以赢得论证，而上诉本身并不因此把该取值写进注册表。

还有一项结构性事实，值得钉在案头。RFC 8126 §5.2.1 原话是「The IESG may remove any designated expert that it appointed, at its discretion」，同节还写到 IESG 任命并替换 IETF 注册表的专家，通常依据领域主任的推荐（RFC 8126, §5.2.1）。第 10 节把异议首先送到同一个机构。两份文件都没有调和任命角色与上诉角色，在所审阅的条文中也没有陈述两者之间的分离安排。链条中第一个被点名的机构环节，就是任命该专家的机构：第 10 节的路径要先经过工作组主席与负责的领域主任，才到完整的 IESG；至于某一起上诉由谁审理、是否由同一批人处理，本文并未确立。

其他条文把边缘磨软，却不改形状。IESG 可以例外地逐案越过登记程序（RFC 8126, §3.3）。专家审查中出现反复且无解释的延迟时，IANA 必须向 IESG 上报，IESG 应纠正情况或更换专家（RFC 8126, §5.3）——这个救济针对的是延迟，不是申请人要的那个取值。透明度原则则写得很直白：「the recommendations by designated experts must be visible to the public to the maximum extent possible and subject to challenge or appeal」（RFC 8720, §3.3）。可见性有承诺，决定日期没有。

文件周围的记录仍在变动。2026 年 3 月的 RFC 9907 更新了 RFC 8126，并使 RFC 8407 作废；它要求写出说明，把权威注册表的变动与相应的 IANA 维护的 YANG 模块维护挂接起来，新取值应写入权威注册表，而不是直接加进模块（RFC 9907）。勘误档案显示社区已经试过什么：技术勘误 6522 于 2021 年 4 月 8 日被拒绝，它原本要让特定版本的 Internet-Draft 明确满足 §4.6 的规范门槛，而核验者把它当作需要社区讨论与共识的政策提案，而不是纠错；编辑性勘误 5772 于 2019 年 7 月 3 日被留待文档更新处理，只涉及致谢部分的一处引用（RFC 8126 勘误）。这次拒绝记录的是某一种拟定措辞未获采纳。它并不证明从来没有 Internet-Draft 在任何注册表的规则下于实践中被接受过，而 §4.6 的现有文字也没有把 Internet-Draft 列入可接受形式。

存在一份替代文本，但它尚未生效。draft-ietf-ianabis-rfc8126bis-05 于 2026 年 11 月 2 日发布；其摘要称它使 RFC 8126 作废，但文件首页把这一点限定为「if approved」，而文件状态标明它是 Internet-Draft，即进行中的工作（draft-ietf-ianabis-rfc8126bis-05）。因此本文把 RFC 8126 当作现行文本，替代稿记为待定，而不是已经完成的取代。

有三条边界应紧贴相应论断，而不是堆在文末。本次没有审阅任何真实的登记申请、拒绝、上诉提交或处置结果，因此以上全部描述的是已公布的框架，不是某一具体申请的处理过程。任一具体注册表受哪些政策约束，没有确立——同一个注册表可以承载多种程序。IESG 内部如何处理上诉，以及任何未公开的既往上诉记录，均未取得。

一处检索限制，只说一次：关于 IANA 命名职能那一类文书的三次检索尝试，都在提供方一侧失败后才关闭这条线；命名职能合同、Customer Standing Committee 章程与 Naming Function Review 报告在本次审阅中仍未被读到。这是本台检索的缺口，不是关于那些文件的结论。

什么会改变这个判读？一份公开的上诉处置结果，最终以 IAB 而非 IESG 的方向把某个取值写入注册表；或者某个注册表把自己的准则写下来，从而把「推定予以登记」变成可检验的测试。在那之前，对任何依赖某条 IANA 注册表条目的人来说，诚实的概括比看上去要窄：框架公布标准、公布透明度承诺，却把时间表和最后的话交给同一小群人。