摘要

  • 这份通知标题指向《ICANN 章程》第 17 条与第 18 条；ICANN 自家的章程页把这两条标为 Customer Standing Committee 与 IANA Naming Function Reviews，二者都不是规定章程本身如何被修订的那一条。
  • 通知所援引的审批行动与社群论坛机制，按同一页面的说明，位于附件 D，即 EC Mechanism；而 Address Supporting Organization 自述的职责范围是 IP 地址政策，它在这里的席位来自跨社群机制，不来自对议题本身的权属。
  • 本次检索未取得通知正文、Board 决议、论坛记录与附件 D 的生效条文。论坛究竟约束了决定，还是仅仅记录了决定，因此仍然悬而未决——本文提供的正是能把它判定下来的检验方法。

ICANN 的公开记录里有这么一份通知，它的标题读起来像把地址标签贴错了包裹。收件人是 Address Supporting Organization。它召集了一个叫 Approval Action Community Forum 的东西。而被交付审批的，是《ICANN 章程》第 17 条与第 18 条的一组根本性修订。

只看编号，人会以为要打的是一场关于章程如何修改的仗。翻开章程，战场完全在别处。第 17 条是 Customer Standing Committee，第 18 条是 IANA Naming Function Reviews。地址社群被召来谈的，是命名职能。

这不是文字疏漏。这是一张地图，标出权威实际落座的位置，也标出当 IANA 命名职能之上的问责架构被重写时，号码社群握着的是哪一种抓手。

两层结构，同一份文件

ICANN 的章程页在该处标注为 2026 年 7 月 3 日修订版，条目列得很干脆：第 17 条是 Customer Standing Committee，第 18 条是 IANA Naming Function Reviews。同一页面把 Empowered Community Mechanism——包括 Approval Actions 与 Community Forums 的程序——放在附件 D。

仅仅这一点，就完成了大半分析工作。通知点名的是实体层：一个常设委员会，一项审查职能。召集论坛的程序则坐在一份程序性附件里。当一份文件以一层为标题、却经由另一层运作时，真正有意思的问题不是哪一层被贴错了标签，而是哪一层能改变结果。

我在这里读的是标题，不是条文。修订后的条文我没有取得，所以我无法告诉你 Customer Standing Committee 在修订之后承担哪些义务、审查职能如何被触发、谁任命谁，也无法告诉你一项不利结论如今带来什么后果。标题所确立的是位置：这两条正是命名职能被监视、被审查、被追究的通道。修订动到的，就是这套架构。

地址社群是从隔壁过来的

Address Supporting Organization 自述为 ICANN 内三个 Supporting Organizations 之一。它就互联网协议地址政策进行审议并提出建议，并就政策问题向 ICANN Board 提供意见。它同时参与 ICANN 的 Empowered Community，而该社群自家网站把这个机制描述为 ICANN 社群得以行使某些权力的途径，例如依照章程所定义的 Approval Action 程序质疑 Board 的决定（aso.icann.org）。

由这里只推得出三件事，也正好只有三件。

第一，ASO 在这场程序里的席位是真实的。参与 Empowered Community 不是观察员胸牌，而是一个 Supporting Organization 进入质疑程序的正式通道。

第二，这个席位不是建立在议题权属上。ASO 自述的日常事务是地址政策；第 17 条与第 18 条处理的是命名职能。于是号码社群参与的，是一场关于他人业务领域的决定——通过跨社群机制，合法地参与，却不具备地址政策在别处给它的那种实体性资格。

第三，那道落差，正是杠杆丢失或找到的地方。一个握有一般程序权利、却对议题没有专门主张的参与者，必须更费力才能成为关键一方：它要把看法转化为获授权的立场，而该立场还必须对决策规则起作用。这两步都不自动发生，也都不在一份通知里显形。

判定约束与记录的检验

人总想把这类论坛读成否决权，或者读成走过场。两种读法都是猜。有一条更干净的界线，值得写成一个任何运营商或律师都能执行的检验。

先把行为拆开。Board 的批准是一个行为。通知是第二个。论坛是第三个。ASO 的正式决定是第四个。Empowered Community 的任何汇总或认证是第五个。法律效力是第六个。把它们糊成一团，程序性准入就会被误当成同意。

然后做零效应检验。让 Board 的决定保持不变，把论坛抽掉。如果时点、内容、生效日与可用救济在抽掉之后完全相同，那么论坛就是通知，或事后正当化。如果法律效力要等程序走完才发生，或者一项获授权的不利立场能够发回重审、能够给决定附加条件，那么即便 Board 先投了票，论坛也是约束。

接着给杠杆定级，而不是替它宣称。一项立场若能阻止或发回，是可决的；若能延后，是中止性的；若只能迫使披露、说明理由或留下可审查的记录，是程序性或证据性的；若只产出言辞与能见度，是象征性的。通知证明通道存在，不告诉你通道的等级。

还有，把“批准生效”这个词留给真正生效的批准行为。如果批准是由之后的某个 Empowered Community 步骤给出的，那么起约束作用的是那一步，而不是它之前的论坛。在那一步之前开的论坛是审议；在无条件生效日之后开的论坛是归档。这个区别是法律上的，不是修辞上的。

现行文本无法显示的东西

证据位置尴尬的地方在这里。我取得的章程页标注为 2026 年 7 月 3 日修订版。如果通知所涉的修订在该日或之前生效，那么今天公布的就是修订之后的文本，它无法向我呈现差值。我能读到的这份文件，可能已经把变化吞了进去。

这对任何想争论修订究竟做了什么的人都很要紧。已公布的页面告诉你第 17 条与第 18 条现在说什么，却不告诉你它们此前说什么——而后者才是判断审查触发点有没有移动、任命权有没有转移、报告义务有没有长出牙齿的唯一办法。本次检索未取得：此前文本、对照红线稿、Board 决议的说明理由，以及生效日的表述。

后果不大，但真实。只依赖现行页面的读者，可以学到架构此刻的形状，却学不到它移动的方向。而方向，才是显示谁的权力变大的那一半。

记录没能判定的事

有四份文件能补上大部分缺口，而它们我都没有取得：给 ASO 的通知正文；授权修订的 Board 决议；Approval Action Community Forum 本身的记录；以及事件当时适用的附件 D 生效条文。

缺了它们，几个问题仍然真的悬着。修订改变了什么？论坛何时召集，落在 Board 批准之前的哪段窗口里？一项获授权的不利立场本可改变结果，还是只能给它加个注脚？ASO 到底支持、反对，还是根本没有送出立场？这些问题各自在某个地方有答案。本文一个都没有回答，而未被回答的问题不是结论。

这个区别值得守住，因为这篇文章的廉价版本会自动写成：机构在决定之后才召集社群，可见咨询是表演。本次取得的记录不支持这句话，也不支持它的反面。它支持的是一项结构性观察，和一套诊断方法。

为什么仍然重要

这份通知记录了一件在文件缺失之下依然成立的事。命名职能之上的问责架构，其修改程序里坐着这样一个 Supporting Organization：它的职责是地址。这不是起草时的偶然。它顺着 ASO 自家网站赋予 Empowered Community 的形状：一个让 ICANN 社群行使某些权力的机制，而不是一个议题委员会。

这套设计的代价，由议题主张最弱的参与者承担。ASO 能进入程序，却无法主张议题归它。它的影响力取决于能否产出一项获授权的立场，以及该立场是否进入计算——而这是阈值、时点与默认值的问题，一份通知里一样都不出现。

所以要看行为，不要看形容词。ASO 通过自家内部程序送出的获授权立场，与个别运营商的评论，是两种不同的东西。把效力系于 Empowered Community 某一步的决议，与签署即生效的决议，是两种不同的东西。经过认证的结果，与一份已公布的议程，是两种不同的东西。

这份通知的名录条目，以其完整标题登记 仅限战略圈层会员，只载有标题，别无其他：没有关系，没有通知正文，没有日期。这诚实地说明了标题能装下多少。标题告诉你哪些条目被修订，却无法告诉你谁赢了。为此，得有人把决议、附件和记录拿出来——而在那之前，读者能握在手里最有用的一件东西，就是这个检验。