摘要

  • 2026 年 8 月 13 日，ccNSO 理事会讨论了一份已不能完整反映现行 ICANN《章程》的 2007 年区域自选程序，其中一个明确问题是同一国家或属地存在多个 ccTLD 管理方。
  • 旧程序让 IANA 行政联系人替“该管理方”提交申请；现行规则则区分管理方、代表、属地与特使。修订必须先确定区域选择附着于哪个单位，以及谁的同意能使它生效。
  • 这种选择只服务于 ccNSO 治理，不改变 ccTLD 授权、IANA 服务资格、实际运营控制、主权归属，也不自动改写 ICANN 其他组织采用的地理分类。

网站迁移暴露的是授权问题

这次议题不是由一场争议选举触发的。2026 年 7 月 30 日，ccNSO 理事会邮件列表上的通知说，在网站迁移过程中，相关人员重新看到了 2007 年的程序和申请表，并发现它们已被后来的《章程》变化越过。8 月 13 日举行的第 232 次理事会会议随后讨论了此事。官方社群报告明确提到同一国家或属地可能存在多个管理方，并记录了理事会要求秘书处准备一份报告，比较现行程序与潜在修订的利弊。

在已审阅的公开材料中，还没有新的程序被通过。没有证据表明某次既往选举因旧表格而无效，也没有具名管理方公开声称自身区域选择遭拒，更没有一场已公开的一地多管理方冲突。因此，准确的问题不是“ccNSO 正在补救哪场失败”，而是“在真实冲突发生之前，它能否把一个过时的单一主体模型改造成可执行的复数授权模型”。

2007 年的设计在当时有清晰流程。它处理的是一类特殊情况：某些 ccTLD 管理方按照公民身份标准而不是属地所在位置被归入 ICANN 地理区域；如果该管理方是 ccNSO 成员，可以请求自行选择区域。IANA 数据库中的行政联系人提交申请，并附相关政府或公共机关的支持函。IANA 核验申请人，ccNSO 秘书处检查资格，地区联络人员检查支持函，最后由理事会决定。

旧程序还设有边界。选择只适用于 ccNSO 事项；除非出现特殊情形，五年内不能再提出新的选择；程序需要定期复核并由理事会继续采用。问题不在这些限制本身，而在于整套步骤反复使用单数的“管理方”，仿佛联系人、管理方、属地和投票主体天然重合。

管理方、代表与特使不是同一个角色

现行《章程》第 10 条把这条链拆开。每个 ccTLD 管理方可以指定一个人、组织或实体作为其代表；若没有主动指定，IANA 数据库中的行政联系人被视为该管理方的代表。一个属地只有一个管理方时，这名代表同时也是属地的特使。

一旦同一属地有两个或以上管理方，结构就不同。各管理方必须从各自代表中指定一人担任属地特使；如果没有作出指定，《章程》提供与加入 ccNSO 时间有关的缺省机制。在第 10 条指定的投票中，一个属地只有一票，由特使投出。

这不是称谓上的细枝末节。代表的授权源于某一个管理方；特使则是在特定 ccNSO 决策中承接整个属地唯一投票接口的人。行政联系人可以因缺省规则成为本管理方的代表，却不会因此自动取得约束同一属地其他管理方的权力。反过来，特使能够投某些票，也不等于他取得所有 ccTLD 的技术控制，或可以替所有管理方处理任何事项。

旧申请表因此留下一个尚未回答的单位问题。区域究竟附着于每个管理方、某个 ccTLD、整个属地，还是只在某些提名、投票和法定人数测试中使用？不同答案会产生不同的同意门槛。如果两个管理方选择不同区域，是各自分别归类，还是属地只能有一个结果？如果属地只有一个结果，特使可否单独申请，还是必须证明所有管理方同意？

区域不是装饰标签，而是权力分配的输入

ccNSO 理事会在 ICANN 五个地理区域中各设三名由成员选出的理事。当前选举说明显示，每年每个区域有一个席位进入遴选。候选人的提名人和附议人必须来自同一区域、但来自不同属地；选票则通过特使投出。区域归属会直接影响谁能提名、谁能附议、候选人进入哪一场竞选，以及哪份选民名册适用。

区域和属地条件还出现在其他权力机制里。某些由成员触发的表决或法定人数测试，需要跨不同属地或区域的支持。ccNSO 提名其对应 ICANN 董事席位时，所有成员经由特使投票，虽然那并非五场彼此独立的区域竞选。换言之，同一个区域字段会被多个制度消费者读取，但每个消费者的选民结构和决定对象并不完全相同。

这正是为什么秘书处的利弊报告不应只比较纸面表格或在线提交方式。它应先列出区域数据被哪些规则调用：理事会席位、提名资格、附议资格、选民名册、法定人数、跨区域门槛以及董事提名。只有完成这张功能图，理事会才知道一次区域变更应在何时、对哪些程序生效。

生效时间尤其重要。若提名开放后才批准变更，候选人可能在程序进行中被移动到另一区域。若选民名册冻结后、投票关闭前修改归属，同一决定可能面对两套人口基准。新程序需要公布截止点、首个适用选举周期和过渡规则，而不能让后台记录更新悄然重写已经启动的竞选。

同意不能由“提交人”替代

一份可执行的申请首先应列出属地、所涉 ccTLD 和所有当前管理方，并说明现有区域与申请区域。接下来应从带日期的权威记录中提取每个管理方的代表和属地特使。申请记录必须分别显示谁发起、谁支持、谁反对以及谁尚未回应。

理事会需要公开选择一条冲突规则。可以要求一致同意；可以允许特使在达到预先规定的内部门槛后提交；可以给反对者一个异议期；也可以在分歧没有解决时延后申请。每一种方案都重新分配否决权。沉默也不是中性的：把未回复当作同意会提高行政效率，却可能把一个管理方未曾接受的选择固定五年。

政府或公共机关的支持函属于另一条证据链。它可以证明某种公民身份联系，或说明公共机关支持该请求，但不能自动证明各管理方之间已经形成授权。公共机关证明、IANA 登记身份、管理方同意和特使资格是四个不同事实。把支持函当成内部同意，会让外部机关间接决定《章程》留给成员的代表关系；完全忽略支持函，又会丢掉旧程序原本要求的地理依据。

五年限制也需要事件规则。如果期间新增一个 ccTLD、更换管理方、特使改任或原有同意分裂，旧选择是否继续约束新主体？“特殊情形”由谁认定，什么证据足以提前重开？程序必须说明限制附着于属地、决定还是申请人，以及管理结构变化是否触发复核。

一份可公开审计的区域选择记录

最终产品不应只是新版申请表。ccNSO 需要一个带版本的区域选择记录，保存原区域、新区域、属地、涉及的管理方和 ccTLD、已核验的代表与特使、各方同意状态、所适用的 ccNSO 功能、决定机关、理由、生效周期以及五年限制的到期点。

记录还应引用所用程序版本，列明 IANA、秘书处和地区人员各自完成的核验，并保留修正、异议与复核历史。每场受影响的选举可以链接到当时有效的记录版本。这样，后来审计某次提名或计票时，读者看到的不是当前数据库覆盖后的状态，而是决定发生时的权限快照。

可审计不等于公开个人联系方式。公开层只需说明某一正式角色在某日被权威来源核验，并指出负责核验的办公室。支持函可按签发机关、日期和所证明事项登记，个人电话、电邮或住址可以遮蔽。需要授权的复核者仍可查看底层材料，而公众能够理解决定链。

最后，记录必须把效力边界放在醒目位置。2007 年程序说区域选择仅用于 ccNSO 事项；现行《章程》进一步说明，加入 ccNSO 或地区组织不是访问或登记 IANA 数据库、也不是获得 IANA 服务的条件。区域自选不转让域名、不作根区指令、不判断主权，也不把特使变成运营方。

ccNSO 面对的不是一个庞大的宪制重写，而是一处小型接口修复。正因它小，最容易被当作行政维护。然而，当一个字段进入提名、席位和投票规则时，字段背后的主体、授权与时间就属于治理结构。若新程序只更新界面而不说明这些关系，单一管理方的旧假设仍会在新表格里继续作出决定。

来源