摘要

  • ICANN 董事会主席 9 月 24 日的工作坊回顾说，根服务器系统治理工作组的模型与 RSSAC 标准及建议之间既有一致之处，也有未解决分歧。
  • 董事会讨论的是若采纳建议，可怎样协助相关方解决问题；回顾没有公布争议清单，也没有宣布采纳。
  • RSSAC058 把过渡前的章程文件、受约束方同意、运行连续性和决策规则分成不同检验点，不能用一声「已有共识」代替。

对根服务器这样依赖持续协作的基础设施，最危险的新闻写法，是把一次「比较」报道成一次「交权」。Tripti Sinha 在 9 月工作坊回顾中用了两个关键限定：模型与 RSSAC 标准有一致之处，也有未解决分歧；董事会考虑在可能接受工作组建议的前提下，如何帮助相关方处理余下事项。她没有说明争议究竟是什么。这个空白本身就是新的、可核查的治理事实，却不是任何一方已被判定错误的证据。

工作坊预告在 9 月 2 日点名 RSSAC037 与 RSSAC058，说明董事会准备以既有模型和成功标准作参照。会议结束后的回顾只给出结论类别，没有逐项对照或参与方的意见。9 月 6 日公开的董事会决议也没有采纳这份根服务器治理模型的决议。由此能得出的结论是审议尚未在这些公开资料中完成；不能推断一项具体标准遭否决，也不能替董事会编出批准日期。

工作组 2026 年 2 月的最终文本提出逐步建立机构：起步阶段重在组建、咨询与准备，尚不行使完整治理权；建立阶段再形成程序与问责安排；符合节点后，治理阶段才可能启用更完整的职能。文本还把拟参与社群的承诺列入筹建过程。方案值得审阅，但一份阶段设计不等于阶段已经开始，更不等于现有根服务器运营关系今天就被改写。

RSSAC058 提供了更严格的提问方法。其 B 部分要求，受新结构约束的各方先就最终章程文件达成同意，过渡须格外注意不扰乱根服务；C 部分要求说明哪些决定只由根服务器运营者作出，哪些由其与他方共同作出，采用什么决策门槛，以及新结构与 RSSAC 如何相处。这些条款是面向未来决议的公开检查问题。董事会并未说它们哪一条就是目前的分歧，报道不能把「可能需要核对」写成「已经查出违规」。

2025 年的 RSSAC063 也应放回原位。RSSAC 当时支持征求意见的文本，把它视为迈向治理演进的第一步；董事会在 2021 年要求工作组将 RSSAC058 纳入工作。这些是支持推进和要求对照标准的行为，不是对 2026 年最终方案逐项验收的证明。反过来，董事会如今承认仍有差异，也不意味着先前一致的部分突然失效。

可行的公开产物是一份「标准处置对照」：每项重要标准对应方案条款、目前答案、尚待决定的问题、能作出决定的主体，以及问题应在模型、章程文件还是后续阶段解决。已达一致就记录一致，延期处理就注明延期边界。这是 Daniel Kade 的编辑建议，不是 ICANN 现有命令；它不要求披露可能暴露根服务攻击面的技术细节。它要求的是，未来任何「接受」一词都能指向一条可以复核的授权路径。

资料来源