摘要

  • ICANN的控制面由公司目的、章程规则、注册局和注册服务机构合同以及执行机制共同构成；这些层次不能被简单视为同一种公共权力。
  • 复议、独立复审、调解和合作参与的资格、范围、期限与结果不同。正式存在的挑战路径，并不保证决定会被暂停、撤销或及时补偿。

ICANN的制度权力首先需要被拆开，而不是被概括为一个笼统的“互联网治理授权”。《公司章程》说明机构的公司目的，包括协调全球互联网标识系统并支持域名系统的稳定与安全。[https://www.icann.org/resources/pages/governance/bylaws-en] 这是一项基础性的组织定位，但它本身并不等于对每一项运营争议都拥有直接、无限的命令权。更具体的权力，需要在其他制度层次中寻找。

《ICANN章程》承担了第二层功能。它规定机构的使命、权力、问责安排以及对董事会或组织行动提出复议和独立复审的制度框架。[https://www.icann.org/resources/pages/governance/articles-en] 第4条进一步规定了透明度、问责、复议和独立复审等程序，并设置资格条件、提交期限和排除事项。[https://www.icann.org/resources/pages/governance/bylaws-en#article4] 因此，章程既是权力的组织性来源，也是对挑战权的程序性限定。一个参与者能否进入审查程序，不能只由其是否受到政策影响来判断，还取决于相关行动是否属于机制覆盖的类型、申请是否及时，以及争议是否落入排除范围。

真正把政策和制度承诺转化为运营控制的，往往是合同。ICANN公布的注册局协议包含对通用顶级域运营者的运营、合规、争议处理和执行义务。[https://www.icann.org/resources/pages/registry-agreements-en] 注册服务机构认证协议则规定了认证服务机构的合同要求、报告和审计义务、违约通知以及可能的执行或终止救济。[https://www.icann.org/resources/pages/registrar-accreditation-agreement-en] 这意味着，ICANN对运营者的影响常常沿着合同链条实现：某项政策或规则先进入协议，协议再通过报告、审计、合规通知和其他执行工具影响运营者的行为。

这种控制面带来一个容易被忽略的区分。机构可以拥有作出某项决定的权限，但执行该决定的操作可能由另一方完成；合同可以提供施加压力的手段，但不必然提供立即逆转已经发生后果的手段；审查机构可以确认程序或章程问题，却未必能够像一般上诉法院那样全面重做原决定。因而，对每一项争议都应至少提出三个问题：决定由谁作出，执行由谁完成，哪个机制能够在何时改变结果。

ICANN列出的问责机制包括复议、独立复审、与监察专员有关的职能、调解以及其他审查路径。[https://www.icann.org/resources/pages/accountability/mechanisms-2018-06-29-en] 这些机制不是同一条逐级上诉链，而是不同入口、不同标准和不同结果的组合。复议允许符合条件的当事人请求董事会治理委员会审查某些董事会或工作人员的行动或不行动，但受到期限、资格和排除事项约束；其中可能包括政策实施、独立判断以及章程或程序规定的其他类别。[https://www.icann.org/resources/pages/reconsideration-2012-02-25-en]

独立复审的范围又不同。它针对某些董事会行动或不行动，审查其是否与《公司章程》或《ICANN章程》一致。[https://www.icann.org/resources/pages/irp-2022-03-02-en] 这不是对所有政策或运营问题的普遍上诉。它的功能更接近一种受边界约束的制度一致性审查：申请人必须满足相应的资格和程序条件，审查对象也必须属于机制允许处理的行动。即使最终获得有利结论，结论如何影响已经发生的运营措施，仍取决于具体程序和事实记录。

调解的逻辑更加不同。调解寻求协商解决，通常依赖争议各方的参与，而不是由一个裁决机构单方面施加强制性结果。[https://www.icann.org/resources/pages/mediation-2012-02-25-en] 这使它可能适合缩小争议、澄清事实或寻找商业安排，却不能被当作必然暂停执行的法律命令。合作参与程序也可能在正式小组审查前鼓励解决问题或缩小争议范围，并在某些情况下构成程序性门槛。[https://www.icann.org/resources/pages/cooperative-engagement-2012-02-25-en] 它是进入正式审查前的处理阶段，而不是对实体问题已经作出的裁决。

把这些机制放在同一张图上，可以看到“正式救济”和“有效救济”之间的差距。正式救济至少需要回答：谁可以申请、申请什么、在多长时间内申请、审查什么标准、能够得到什么结果。有效救济还要继续追问：申请期间运营是否继续，决定造成的状态是否会被维持，数据、域名、认证资格或服务关系是否已经转移，最终决定能否追溯性地修复损失，以及参与者是否有资源承担程序成本。

这些问题并不意味着ICANN的机制无效，也不意味着每项决定都应自动暂停。它们说明，制度评价不能止步于“存在问责机制”的形式性描述。对于一个运营者而言，几天的合规期限、一次域名状态变更、认证关系的中断或关键记录的不可见，都可能先于最终审查结果产生影响。若审查只在后果已经固化后完成，那么它可能仍具有解释、纠正或宣示价值，却未必能够恢复原来的运营位置。

同样重要的是，不应把合同执行误写成一般意义上的公共行政权力。注册局和注册服务机构所承受的义务，首先体现为合同、合规和组织治理关系。其约束力来自适用协议及其纳入的政策，而不是单凭ICANN的机构名称自动产生。相反，也不能因为权力通过合同实现，就认为它只是普通商业安排。合同覆盖的运营节点、报告义务、审计权限和违约工具，能够把制度选择传导到域名系统的实际运行。

由此，ICANN的控制面可以分为五层。第一层是公司目的，说明机构要协调什么以及为何存在；第二层是章程和问责规则，规定组织权力、程序和挑战边界；第三层是注册局合同，把政策和运营义务写入协议；第四层是注册服务机构认证合同，通过合规、报告、审计和违约工具维持执行关系；第五层是具体的运营执行和后续救济，决定一个纸面上的义务如何变成现实中的状态变化。争议分析如果跳过其中任何一层，就可能把权力来源、执行路径和救济结果混为一谈。

这也是为什么“谁能挑战”不能与“谁受到影响”简单画等号。章程和程序对申请人资格、期限、可审查行动和排除事项作出限制。[https://www.icann.org/resources/pages/governance/bylaws-en#article4] 某个参与者可能实际承受运营损失，却仍需要证明其属于特定机制承认的申请主体，且争议不是被排除的政策实施或独立判断事项。程序门槛不是实体结论，但它决定哪些实体问题能够进入审查。

在比较救济路径时，时间应当成为核心变量。复议和独立复审都存在程序条件，合作参与可能位于正式审查之前，调解需要参与者同意。每一种路径都可能对争议有帮助，但它们并不都能在同一时点提供同一种保护。对受影响方来说，最有价值的记录通常不是一句“可以申诉”，而是明确写出：行动何时生效、是否会继续执行、提交申请是否自动暂停、可获得的结果是程序纠正、重新考虑、协商安排还是其他形式的补救。

公开制度文件能够确定机制的设计边界，但不能单独证明每个案件中的实际效果。适用协议的版本、具体事实记录、执行通知的内容和相关程序时间线，都可能改变分析结果。尤其是合同执行后果，取决于所适用的协议版本和事实背景；公司章程的精确法律效力，也取决于适用的公司法和非营利组织法。对这些问题作出更强的结论，需要进一步核对案件记录、现行文本和具体决定。

因此，对ICANN权力的稳健判断应当保持有限而具体：它不是一个没有边界的全球行政机关，也不是只有软性协调能力的行业论坛。它通过公司文件、章程、合同和运营执行形成分层控制；它也通过多种问责程序提供挑战入口。但入口、审查和结果之间存在距离。能否暂停一项行动、能否撤销已完成的执行、能否补偿时间敏感的损失，必须根据具体机制和事实逐项判断，而不能从“存在正式救济”直接推导出来。