摘要

  • RFC 2860 记录了 IETF 与 ICANN 于 2000 年签署的备忘录，限定了 IANA 为 IETF 和 IRTF 协议提供的技术工作。RFC 提供分配标准；遇到技术歧义时由 IESG 指引，IANA 与 IESG 的争议则交由 IAB 决定。
  • 备忘录排除域名和 IP 地址块分配中的政策问题，却没有排除所有涉及这些空间的技术分配。它还要求公开当前分配信息、开放在线申请、仅以正当技术理由拒绝，并允许申诉和提前六个月终止。

分析

第 4.3 节的边界有两面。一面是，域名和 IP 地址块分配所涉及的政策问题不属于备忘录范围；另一面是，反向 DNS 名称、多播或任播专用地址块，以及实验性分配，只要不构成政策问题，仍要依照第 4 节处理。把这段读成“域名和地址都不归 IANA 的技术安排管”会丢掉它明确写出的例外。它区分的是问题的属性，而不是资源的外观。

这个区分之所以重要，是因为备忘录把技术决策拆成几个可追踪的步骤。第 4.1 节说，IANA 只能依照 RFC 规定的标准和程序分配、登记协议参数，涵盖拟议标准、草案标准、完整互联网标准、最佳当前实践文档，以及要求 IANA 分配的其他 RFC。如果文件没有给出标准或留下歧义，IANA 延续传统做法，除非 IESG 另有指示。遇到疑问或技术争议时，IANA 应向 IESG 寻求技术指导并遵循其意见；IESG 也可以在适当情况下指定专家。双方还承诺逐步补齐缺失的标准和程序，IANA 按 IESG 指示采用。

如果分歧发生在 IANA 与 IESG 之间，第 4.2 节把争议交给 IAB 指导，并规定依备忘录其决定为最终决定。第 4.5 节则说明申请和拒绝如何运作：公众可以在线提交协议参数分配请求，IANA 应及时执行，或因不符合适用技术要求而拒绝。拒绝必须建立在正当技术理由上。对于由 IETF 行动建立的注册表，申请人可先向 IESG 申诉，再依第 4.2 节向 IAB 申诉。这些条款提供了审查路线，并不说明某次具体申请是否走过这条路线。

注册表公开是另一种问责方式。第 4.4 节要求免费在线公布每项当前分配的信息，包括受分配者的联系方式。由 RFC 编辑公开发布在 RFC 中的分配，可视为满足这一要求。实施者因此能核对已登记的值和相应文档。不过，一个可见记录只能证明公开的登记状态，不能单独证明另一个有争议的请求已经获批或部署。

备忘录还让 IANA 能把运营问题带回技术讨论。第 4.6 节允许 IANA 在 IETF 指定的相关委员会担任无投票权的联络席位，并参与协议参数技术要求的讨论。第 4.7 节要求 IANA 审阅 IETF 公开征求最后意见阶段的文件，并把关注事项提交 IESG。运营方由此可以指出注册实践中的问题，但文本仍把标准来源放在 RFC 和 IESG 指示上。

这套程序也涵盖 IRTF。第 5 节把第 4 节程序用于主要属于互联网研究任务组范围的参数，并在程序中用 IRTF、IRSG 分别替换 IETF、IESG。如果无法判断某个参数主要属于哪一方，IAB 有权决定其归属。于是，先要确定注册表属于哪条技术轨道，再讨论谁执行分配。

RFC 2860 的身份同样需要准确描述。它于 2000 年 6 月作为 Informational RFC 发布，明确不规定任何互联网标准。它记录了 IETF 和 ICANN 在 3 月 1 日签署、ICANN 董事会在 3 月 10 日批准的备忘录。备忘录的目的，是专门界定 IANA 代表 IETF 和 IRTF 执行的技术工作；同时承认 ICANN 可为这两组织范围之外的注册表提供类似服务。

该安排可以由双方共同修改或取消，也可由任一方提前至少六个月通知后取消。这是一项写明的退出条件，并非发生过终止的证据。2011 年 RFC 6220 后来描述了 IETF 协议参数注册表运营方的职责，并指出 IETF 仍承担管理这些协议参数的责任。它能帮助理解运营方角色，却不能证明 2000 年备忘录的所有安排此后始终未变。

这份文件能够证明的是：技术参数的标准来源、歧义的升级路径、公开义务、申诉程序和明确的范围界线。它不能证明每次操作都遵守程序，也不能证明某个具体争议会如何裁决，更没有指定第 4.3 节排除的政策问题由谁决定。保留这些未知，才能看清协议参数注册的控制面究竟止于何处。

来源

主要证据是 RFC 2860：关于 IANA 技术工作的谅解备忘录，尤其是第 1 至第 5 节。后续运营角色说明见 RFC 6220。