摘要

  • 2015 年，Alain Durand 汇总五年 IANA 使用数据，把请求分为域名、号码资源和协议参数三类。
  • 新通用顶级域名带来了更多委派请求；号码资源请求在所示时期大体平稳；PEN 则是协议参数中使用最频繁的一组，因而被单独绘制。
  • 请求数量可以说明活动规模，却不能单独衡量处理难度、时效、准确性、错误后果，也不能说明制定政策或监督执行的权限归谁。

从注册表使用者到服务观察者

Alain Durand 在 2015 年 5 月 27 日发表的文章，开头并不是一项宏大的制度主张，而是一段职业视角的转换。他在 IETF 工作二十多年，担任过工作组主席，也参与撰写 RFC；作为技术参与者，他熟悉 IANA 注册表的使用方式。加入 ICANN 数月后，他意识到，知道如何提交或查阅一项注册信息，与了解背后的服务如何接收、核验和处理请求，并不是一回事。

他当时的部分职责是支持 IANA 职能监督权的移交工作。为了弄清日常运营到底涵盖什么，他整理了当时能够取得的五年使用统计。Durand 没有把这组数据称作独立审计，也没有声称它能预言未来的工作量，更没有用它为某一种治理安排背书。他提出的问题要具体得多：不同运行社群实际使用哪些服务，数量和组成如何变化？

他的回答首先是规模。按照文章所述，IANA 部门为三个运行社群维护 2,800 多个注册表：域名、号码资源和协议参数，其中包括 IETF 使用的注册表。这个数字说明目录的广度，不等于有 2,800 多条同样活跃、同样繁忙的队列。某个注册表可以很少变动，却仍关系到长期连续性；另一个注册表则可能有许多标准化的小改动。登记册的数量不能直接折算成人力、复杂度或风险。

三类工作也不是同一把尺子下的同类事件。域名服务涉及联系信息更新，也涉及委派或重新委派；号码资源分配要落实相关社群商定的政策；协议参数申请则遵循对应的技术程序。相同的运营者可以处理它们，但共同的机构名称并不能让处理每个请求所需的判断、风险和授权变成一样。

三条数据线，三种变化

在域名部分，Durand 将 ccTLD 和 gTLD 的委派、重新委派，与联系人、名称服务器、DS 记录等更日常的修改区分开来。新 gTLD 的委派曲线出现明显上升，说明项目环境改变后，运营服务接收的这一类请求增多。它不能证明是运营者发起了该项目，也不能把请求数直接解释成社会价值或工作难度的增加。

号码资源的曲线需要放在它自己的范围内理解。Durand 提到，2010 年以前 RIR 曾申请较大的 IPv6 单播地址块；IANA 未分配的 IPv4 单播地址池在 2011 年耗尽，之后有少量退回的地址块依全球政策重新分配给 RIR。尽管背景发生变化，五年图表里的号码资源请求整体仍较平稳。这里说的是 IANA 收到的资源分配请求，不是互联网流量、所有地址使用状况，也不是 IPv4 稀缺程度没有变化。

协议参数方面，IANA 维护的注册表中，许多属于 IETF 定义和使用的参数。PEN（Private Enterprise Number）是最常被申请的 IETF 协议参数之一，通常用于 SNMP 管理信息库的配置。PEN 的请求量过大，放在同一尺度上会挤压其他曲线的可读性，因此 Durand 将它单独画出。这个做法帮助读者看清细节，也提醒我们：分组和坐标轴会影响图表能够呈现什么。

最后的合并图把三类社群的请求放在一起，并为 ccTLD、gTLD 委派采用第二坐标轴，以便读数。他将总体活动描述为相对可预测，新 gTLD 委派是明显例外；号码资源请求大体平稳，协议参数请求则在 2012 年年中一段较平静时期后上升。这是对流量模式的观察，并没有证明三类请求可以互相换算，也没有证明请求总量足以用于评估运营能力。

数量与质量之间的空白

按月统计请求，能够回答多少项活动进入系统，却不能说明每项经历多少轮核验、沟通和判断。它不显示请求在运营者手中等待了多久，也不呈现退回修改、最终记录出错的影响范围，或某项决定是否遵从了正确政策。数字本身更不会告诉读者哪一个机构有权改写规则、复核决定或要求补救。

2015 年 5 月的另一份正式绩效报告已经采用了不同指标。对于受托顶级域名的例行变更，标准要求 80% 在 21 天内完成；报告显示实际按时率为 86.1%，准确率为 100%。号码资源服务则分别考察政策执行、注册表更新时间、澄清轮次、完成时间和公开透明度。当月没有完成号码资源请求。这些指标和 Durand 的请求量图并不矛盾，只是回答不同的问题：一个看流量，另一个看特定的时效、准确性或程序表现。

权限边界在规范文本中更加清楚。RFC 2860 规定，属于 IETF 范围的协议参数分配，应遵循 RFC 中的标准和程序；遇到技术疑问时，IANA 应征求 IESG 的指导。运营者承担执行职责，但请求计数不是制定规范的来源。Durand 与他人共同参与的 RFC 3901、RFC 3363 和 RFC 4472，则显示了他在 DNS、IPv6 和运行问题上的技术经历；这些文件有多位作者或编辑，不能据此说成他的个人作品。

2016 年 3 月 10 日，ICG 发布的最终过渡提案为名称、号码资源和协议参数分别保留相应社群的政策及监督安排。ICANN 董事会同日接受了该提案。已查阅的文件没有说 Durand 的使用研究导致或决定了这一结果。准确的叙述可以承认他的分类工作让运营范围更容易理解，同时保留这场制度设计由不同社群共同推进的事实。

一张图之后应继续追问什么

从证据能够确认的行动很具体：Durand 从熟悉注册表的外部使用方式出发，整理了可取得的五年请求统计，按社群和请求种类拆分，并说明了为何需要将 PEN 单列。公开结果使读者能够看见 IANA 并非只有一条同质队列。证据没有提供每项请求的工时、内部讨论过程或研究对预算和提案造成了什么影响，因此不应给这个贡献增加未经证明的因果解释。

评价服务时，接下来的问题包括：什么事件会被算作请求？分类由谁定义、何时更新？适用规则由哪个社群制定？处理时间有多少由运营者掌控，又有多少在等待申请人、RIR、专家或政策机构？结果是否准确、可见且可纠正？发生争议时，哪个机构有权调取记录并要求补救？只有把这些问题分开，工作量和治理责任才能同时被说明。

今天的 IANA 绩效索引仍将名称服务级别协议、号码资源、IETF 参数分配统计及根区维护者绩效分别呈现。不能据此推断这些页面是 Durand 2015 年研究的直接延续；它至少说明，不同服务所承担的义务和对应的用户并不相同，一个通用总分未必有意义。

请求量持续上升，可能需要检查容量、程序或外部项目变化；它本身不触发政策转向。平坦曲线也不能证明风险很低：一个罕见但高后果的请求，可能比许多例行更新更需要保障。指标应跟着决策问题走，而不是让最容易取得的数字替所有决策作答。

Durand 的研究像一张运营地图：它标出了请求从哪里来、类别如何变化。地图让讨论有了具体起点，却不赋予最繁忙的社群额外权力，也无法单独判断服务是否及时、准确和有韧性。看见活动之后，还要看规则、结果和可以采取行动的监督机构。

资料来源