摘要

  • IAB在2026年10月15日致ICANN董事会的联络意见中，要求在Initiation阶段开始前设立独立且具有约束力的复核小组，处理运营者指定、撤换和绩效停职争议。
  • ICANN于2026年2月发布的功能模型把独立复核列为Establishment阶段的后续考虑事项。这是有记录的阶段安排，不代表机制已经定案，也不等于社区达成共识。

治理委员会可能先成立，之后才决定如何对其最重要的决定提出异议。互联网架构委员会（IAB）10月15日就拟议根服务器系统治理框架向ICANN董事会提出的意见，聚焦的正是这种顺序风险。IAB希望在模型第一阶段启动之前，先处理核心问责保障，包括独立申诉路径。这封联络意见是给董事会的建议，不是具有约束力的决定，也不能代表整个社区的共识。

框架本身采用分阶段实施。ICANN在2026年2月发布的稳定版功能模型称，Initiation阶段将组建治理委员会和秘书处，权限有限，主要用于组织和准备；Establishment阶段再把职能、政策和问责机制正式化；完成相关里程碑后才进入Governance阶段，治理结构届时才拥有对根服务器系统治理的正式权限。模型作者把渐进过程描述为在扩充治理能力的同时维持运营连续性，而非让委员会一成立就获得完整权力。

真正的问题更窄：如果第一阶段先确立了委员会的构成、权限和工作惯例，而外部救济机制尚不存在，后来要改这些安排会付出什么代价？相关草案将申诉与复核放在委员会内部。ICANN对公众意见的处置记录，则把独立复核标为Establishment阶段再考虑的事项。IAB提出的是另一种安排：在Initiation阶段之前设立中立的外部小组，并使其在职权范围内的决定具有约束力，能够审理运营者的指定、撤换以及因绩效问题而暂停资格的申诉。内部申诉和独立复核并不等同：前者请原决策机构重新审视自身决定，后者提供一条不受该机构支配的路径。

治理委员会处在技术连续性与公共问责的交叉点。功能模型让根服务器运营者（RSO）、国家代码顶级域名注册局和通用顶级域名注册局社区直接参与；其他群体则通过公开征询和联络渠道参与。模型也承认运营者承担实际服务，专业技术知识不可或缺。IAB的批评是，RSO目前拥有一半投票权，同一组织可能通过不同群体重复投票，一些受影响群体又没有正式席位。这是IAB对模型的看法，不是各方一致认可的“被俘获”结论。

申诉机制的重要性取决于它能覆盖哪些决定。模型把运营者指定与撤换、绩效评估、财务与资源管理、安全事件报告和政策建议等职能放在后续阶段。Establishment阶段的里程碑要求制定正当程序和申诉机制；在转入完整治理阶段前，相关职能须实际运行，核心政策须获批准，并完成公开评估与利益相关方咨询。因此，在委员会行使完整权限之前，框架确实安排了多层保障。但它没有明确回答：在独立机制尚未成立的空档期，运营者或受影响一方能否挑战初始规则、临时决定，或委员会对自身权限的解释。

IAB还要求在委员会正式成立前确立多元且有约束力的融资方案、加强制衡、平衡投票权，并禁止组织在多个群体重复投票。这些提议彼此相连：复核者由谁任命、经费从何而来、哪些决定可复核、裁决是否必须执行，决定了申诉是否有效。一个没有独立预算、公开理由，也无权处理关键决定的小组，只会提供名义上的保障。反过来，运营职责尚未说清就部署完整复核制度，也可能带来延误和混乱。设计难点是让申诉真正可用，同时不让常规技术运行陷入程序争议。

组建委员会不等于立即把治理权交给委员会。2月版模型限制了Initiation阶段的权限，后续推进依赖里程碑和咨询。这为分阶段实施提供了理由，却没有回答延后独立复核是否安全。制度在“筹备期”也会形成先例：早期选择会塑造预期、预算、任命方式，以及后来参与者认为哪些安排还能改变。初始安排越决定谁能参与决策，就越需要证明存在真正的修订路径，而不是口头承诺以后再议。

董事会的选择也不必只有启动或叫停。它可以授权组织准备工作，同时规定：下一阶段必须以公开的申诉章程为条件，写明独立任命、稳定经费、管辖范围、运营者与受影响群体的申诉资格、书面理由、处理期限、信息披露规则，以及委员会必须落实的补救措施。为保障服务连续性，可以保留范围狭窄的紧急处置通道，并要求随后迅速接受独立复核。这既能检验IAB的担忧，也不意味着所有技术决定都要诉讼化，更不暗示IAB代表所有利益相关方。

接下来要观察的是可验证的程序。委员会启动前，申诉规则是否已公开并落实经费？复核者是否由委员会之外的程序任命和撤换？运营者指定、撤换和绩效决定是否都在复核范围内？理由和结果是否公开，同时对安全敏感信息作出合理保护？如果答案仍是“留待Establishment阶段考虑”，就意味着框架选择先让机构运行、以后再建立外部救济。这种选择可以辩护，但董事会应说明过渡期间受影响方如何寻求纠正，以及初始规则将如何保持可修改。