摘要

  • ICANN 自身的公共评论材料指出，提交的意见是公开的，程序通常保持开放至少四十天，ICANN 组织会总结提交意见并确定主题，启动该程序的群体会在决定后续步骤之前审查提交意见和总结报告。这一设计使总结成为一份治理文件，而非仅仅是办事员的便利之举。
  • 问责差距并非在于评论被隐藏。更严重的问题是，一份官方总结可能会将不同意见压缩为由准备、建议或为决策辩护的同一机构所选择的类别。如果没有可见的编码表，读者就无法辨别反复出现的反对意见、专业的技术警告或少数机构的立场是被认真权衡了，还是仅仅被简化转述了。
  • .org 续约程序就说明了这个结构性问题。该程序页面将取消价格上限条款视为实质性变更，收集了公共评论，承诺为董事会审议提供总结和分析，并链接了评论和报告。公众可以看到咨询架构，但要重建每项反对意见如何影响最终决策，需要的不仅仅是主题叙述。
  • 一份可发布的公共评论摘要应包括透明的议题编码手册、区分独特论证与重复签名的计数、少数派与异议部分、决策回应表，以及驳回反对意见的具体理由。其目的不是要让董事会受制于每条评论，而是要防止公共咨询因压缩而变成默认同意。

摘要正是咨询转化为权力的结点

公共评论期看似民主，因为它邀请各方发声。在 ICANN，它也是制造正当性的正式环节。该程序的公开页面将公共评论描述为一种机制，让利益相关方的意见与建议得以正式、公开地记录在案。同一页面还指出，除非适用例外，程序开放至少四十天，提交意见和总结报告会予以公布，评论对公众可见。而“关于公共评论”页面则进一步说明：ICANN 组织总结提交意见，识别主题，启动程序的群体会审查提交意见和总结报告，处理这些输入，并提出后续步骤。

这个顺序至关重要。评论是原始的民主行为；总结则是一种制度性的翻译。董事会、员工、支持组织、咨询委员会或其他启动群体极少会花时间像公众那样逐页阅读数千页的评论。即便个别决策者广泛阅读，他们仍依赖员工或委员会的材料来了解记录的内容。因此，总结实际上成了评论进入决策的实践入口。一份糟糕的总结可能在满足归档要求的同时，削弱了评论的实际效力。

这并非在臆测恶意。大规模的公共咨询需要压缩。董事会不可能把每条提交意见都变成一份单独的决议。员工必须识别主题、合并重复论点、忽略不当内容，并引导决策者关注需要判断的议题。困难在于，压缩本身就是一种判断。决定两条评论提出了同一议题的人，已然塑造了记录。将一条反对意见归类为超出范围的人，已然影响了可用的补救措施。将反对意见视为请求未来监测而非改变合同的人，已然收窄了选择空间。

ICANN 的章程之所以使这个判断问题变得重要，是因为它们并未将透明性视为简单的张贴。第 3 条要求对决策依据做出详细解释，包括评论如何影响了政策考量，并公开披露董事会和社群决策的理由。这种措辞并不要求每条评论都胜出，但它确实要求一个可追溯的解释。若公共评论摘要只说“收到了评论，考虑了主题，提案将继续推进”，它或许满足了归档习惯，却未能兑现更强的问责承诺。

因此，治理问题不在于 ICANN 是否发布评论——它经常发布。更严肃的问题是，官方摘要是否给了外部人士足够的证据，去检验评论是如何被转化为理由的。一份正当的摘要应当允许读者询问：谁提出了这一主张，有多少不同的论证支持它，附带了什么证据，ICANN 是如何分类的，它触及了哪个决策点，以及它为什么被接受或驳回。若没有这条链条，公共评论就变成了公开的喧嚷，继之以私下的筛选。

评论不是票数，但它们是证据

解读公共评论记录的第一个错误，是把它当成全民公决。ICANN 并非由全球互联网公众选出的立法机构。一千条相同的信息不会自动胜出一条专业的技术异议，而少数高质量的评论也可能指出大量请愿所忽略的缺陷。公共评论不是计票。

相反的错误同样有害：把评论当作背景氛围。公共评论期不是一场仪式性的听取之旅。当 ICANN 邀请受影响各方就一项提案投入时间时，它就产生了一项义务，去解释这些时间如何影响了决策。评论提供着有关运营后果、法律依赖、成本归属、实施风险、用户预期、市场结构和非预期效应的证据。它们也揭示了提案是否被将受其约束的人们所理解。即使基于错误前提的评论，只要许多受影响方都怀有同样的误解，也可能是有价值的，因为这种误解本身就可能制造实施风险。

这意味着，一份好的总结至少应区分四样东西。第一，它应识别事实性证据。一条评论可能指出一项运营依赖、一个合同信赖点、一种安全风险或一项在提案中不可见的成本。第二，它应识别规范性立场。评论者可能说某项规则不公平、与 ICANN 的承诺不符或违背社群预期。第三，它应识别补救偏好。评论者可能支持目标，但要求更窄的条款、更长的通知期、一条过渡路径或一次后续审查。第四，它应识别纯粹的支持或反对。支持声明是有用的，但不应与证据或补救方案混淆。

然后，总结应告诉读者每个议题扮演了何种角色。证据是否改变了文本？反对意见因缺乏支持而失败？ICANN 是否认同风险，但把补救方案放在了别处？董事会是否因为优先考虑了合同统一性、竞争、安全、稳定或其他声明的价值而驳回了一条公平性论点？这些是不同的结果。一份仅仅说“有些评论者提出了关切”的主题式总结，恰恰掩藏了真正关键的决策。

当决策者或其员工已有一条偏好的路径时，风险是最大的。在许多 ICANN 程序中，在评论开放前，员工已花费数月准备拟议的合同、章程修正案、运营计划或实施设计。这并非不当；复杂的治理需要起草。但同样的准备工作也制造了一种激励，将评论视为修饰而非否决。因此，由起草者撰写的评论摘要，必须承受比中立记录更高的证据标准。它必须向公众展示，机构对提案的投入是如何与对反对意见的分类相分离的。

.org 续约程序展示了压缩风险

2019 年拟议的.org 注册管理机构协议续约是一个有用的案例，因为公开记录显示了咨询的架构。该程序于 2019 年 3 月 18 日开启，于 2019 年 4 月 29 日关闭。ICANN 的页面将全球域名部门列为发起组织，并指定了一名员工作为联系人。它描述了现行协议、续约提案、基础注册管理机构协议比对以及实质性差异。其中列出的一项变更，是取消了先前协议中限制注册价格并允许涨价的定价条款。

该页面还用平实的语言说明了下一步：在审查公共评论后，ICANN 将准备并公布一份总结与分析，该报告将在董事会审议拟议续约时供其使用。这句话便是整个问题的缩影。总结并非为博物馆而准备，而是为决策而准备。一旦一份报告成为董事会审议的一部分，报告的质量便会直接影响决策的质量。

.org 的记录也显示了为什么评论分类不能简化为一条标题。一条价格上限的反对意见可能意味着好几件事。一位评论者可能论证说，.org 被非商业用户所依赖，因而具有公共利益属性。另一位可能论证说，由于注册人面临转移成本，传统注册管理机构拥有市场权力。第三位可能论证说，基础注册管理机构协议是不恰当的参照物。第四位可能接受定价灵活性，但要求更长的通知期、更低的上限、分阶段涨价或单独审查。第五位可能反对谈判的双边性质。这些都可以被概括为“对定价的关切”，但它们是触及不同决策点的不同论证。

如果董事会随后批准了续约，那么驳回的理由应当被分开表述。ICANN 可能拒绝一条可负担性论点，因为合同框架将传统注册管理机构与其他运营商同等对待。它可能拒绝市场权力论点，因为它相信竞争或注册人保护已经足够。它可能拒绝程序性论点，因为续约条款限制了重新谈判的空间。它可能将一条公共利益关切推迟到后续的合同合规或政策论坛去处理。每条理由都是可争论的，但至少它是可见的。若没有这种可见性，公众就只能看到存在关切，而决策依然推进。

本文可用的来源记录并不支持对每一条.org 评论的独立重述，也不支持将报告与每条提交意见进行完整编码比对。这一局限是重要的。重点不是编造数字上的不平衡，或引用隐藏的文件；重点在于指明能够使这种重述成为可能的治理标准。链接了评论和报告的公开程序页面是一个起点。暴露自身分类方法的公开总结则是下一步。

缺失的编码手册

最实际的改革是提供编码手册。公共评论摘要应在报告之前或随报告一同公布用于分类提交意见的类别。这些类别不必复杂。它们应指明议题、决策点、主张类型和提议的回应。编码手册应足够稳定，以便读者能够在不同程序间进行比较，但又足够灵活，以捕捉未曾预料的论证。

例如，一项注册管理机构协议程序可使用如下议题代码：定价、续约权、服务连续性、滥用义务、注册人保护、竞争、过渡、法律授权和实施时间。可使用如下主张类型代码：事实性证据、运营风险、法律解释、政策原则、拟议的文本编辑、支持、反对和超出范围的材料。可使用如下回应代码：已在最终文本中采纳、仅做解释性采纳、附理由驳回、推迟至其他论坛处理、不在 ICANN 权限范围内、已处理、缺乏证据支持，或需要后续实施工作。

编码手册的价值不在于数学上的精巧。它迫使摘要撰写者将分类选择公之于众。若一条公共利益异议被当作竞争论点处理，读者便能看到这一转换。若一条技术安全警告被混入一般性反对中，这种混合便可被质疑。若一条少数派立场被标记为“超出范围”，报告便能说明原因。随后，董事会便可以更清晰地了解自己正依赖什么，再来依赖这份摘要。

编码也将数量与分量区分开来。一千份表单提交可能都携带相同的议题代码，并计为一条拥有众多支持者的反复出现的论点。一条专家评论可能携带值得注意的技术风险代码，即便没有其他人提出。一份利益相关方团体的评论可能代表正式的社群立场，应如此标记，但它不应抹去个人的反对意见。编码手册使摘要既能展示广度，也能展示实质。

这对 ICANN 尤其重要，因为公共参与是不均衡的。有些利益相关方拥有全职的政策工作人员。另一些则是志愿者、注册人、小型网络运营商、民间社会团体或仅在特定决策波及自身时才出现的用户。一份暗中偏重经过打磨的机构评论的摘要，可能在未加说明的情况下复制了参与的不平等。一份对每条简短反对意见都同等计数的摘要，则可能丢失专业见解。透明的编码并不能解决这种分布问题，但能使其变得可见。

少数派观点需要一个被命名的位置

共识机构常常担忧设立少数派专栏，因为这可能使分歧看起来比实际更大。这种担忧可以理解，但用错了地方。压制少数派观点并不能创造共识，它只会制造一份不透明的记录。董事会仍然可以选择多数派或员工的建议。问题在于，它能否展示自己拒绝采纳的是什么。

当少数派观点符合以下一项或多项检验时，应予以保留：它们识别了一种可信的运营损害，即便只有少数评论者看到了它；它们来自在评论记录中代表性不足的受影响群体；它们质疑决策的法律授权；它们提出了一个能以更低成本实现所述目标的更窄的补救方案；它们揭示了提案在不同社群中被不同地理解。

摘要不应将这类观点掩埋在“其他评论”之下。它应说明该观点是什么、笼统地说由谁提出、有什么证据支持，以及它为什么最终改变或未改变结果。如果观点薄弱，报告可以明说。如果观点在 ICANN 的使命之外，报告可以明说。如果观点有效但属于后续的政策论坛，报告可以指出是哪个论坛，并说明为何当前决策不应等待。报告不应该做的是，将异议转化为一团没有决策回应的关切氛围。

少数派观点的处理方式也是检验“俘获”的试金石。一个形式上开放的系统，可能被重复参与者、受资助的演员或组织化的选民所主导。一份仅展示支配性主题的摘要，能使俘获看上去像共识。一份记录少数派反对意见的摘要，则能让读者看到，决策究竟是依赖专业知识、谈判实力、持续耐力还是实际的一致同意。

这并不意味着每条孤独的异议都成为否决票。董事会有权驳回糟糕的论证。员工有权指出某条评论误解了合同。ICANN 有权以稳定、安全和互操作性为由，对抗受欢迎却不可行的要求。关键在于，驳回必须被说明理由。少数派观点并不因被允许发言而获得尊重；它被尊重，是因为不采纳它的理由清晰可见。

驳回理由是治理资产

一条附带理由的驳回往往比一条被采纳的编辑更有价值。被采纳的编辑因文本变动而易于察觉。驳回则需要解释。它们展示了真实的价值层级：合同统一性高于量身定制的保护，稳定高于速度，隐私高于公开，竞争高于价格管控，安全高于便利，使命边界高于公众要求。若没有驳回理由，公众便无法得知哪种价值占了上风。

ICANN 的章程已指向这个方向，它要求详细解释决策基础，以及评论如何影响了政策考量。短语“评论如何影响”不应被解读为“评论是否改变了最终文本”。影响可以包括确认一项选择、收窄一项条款、产生一项监测承诺、暴露一处误解、引发一次后续审查，或因董事会认为论证缺乏说服力而未获采纳。摘要应展现这整幅光谱。

驳回理由也能保护 ICANN 免受不公批评。如果公共评论记录中充满强烈反对，但法律协议并未授予 ICANN 施加所要求条件的权力，那么明说这一点，远胜于假装反对意见只是被“考虑”了。如果一条评论要求采取一项会破坏注册管理机构稳定的补救措施，报告应解释稳定风险。如果一条评论提出了一个已由其他合同条款处理的正当关切，报告应指明该条款。这些解释或许无法令反对者满意，但能制造一份可被复核的记录。

缺乏驳回理由则会制造相反的激励。批评者假设机构忽视了他们。支持者假设机构有理由，只是无需展示。员工学会了一项宽泛的主题叙述比详细回应更安全，因为详细理由会制造靶子。这是错误的教训。在一个正当性系统中，理由不是负债，而是权威的通货。

时机决定了评论能否真正产生影响

一份公共评论摘要可以写得完美，但若在决策已定时才姗姗来迟，仍然无法产生影响。如果董事会已然承诺，如果一份合同必须在截止日期前签署，或者员工已商定了无法现实地重新打开的条款，那么摘要就成了一份防御性文件。它解释为何先前的路径幸存了下来。它并不创造改变的机会。

.org 程序再次显示了为何时机需要更明确的处理。公开页面解释说，现行协议将于 2019 年 6 月 30 日到期，评论报告预计于 2019 年 6 月 3 日完成。这一时间表在报告与到期日之间留下了狭窄的窗口。一个被压缩的窗口并不证明程序恶劣。续约的时钟是真实的。但当决策窗口很窄时，摘要应披露在审查评论时，还有哪些选项仍是开放的。文本可以重新谈判吗？期限可以临时延长吗？某一争议条款可以被推迟吗？董事会可以有条件地批准吗？员工可以重新与注册管理机构运营商展开讨论吗？若不了解选项集合，读者就无法评估公众的影响力。

时机在评论开放前也同样重要。如果提案反映了双边谈判的结果，公共评论可能是在挑战对方已接受的条款。如果提案反映了社群政策过程，评论可能是在审查实施而非政策。如果提案反映了一项预算或运营计划，变更可能影响依赖于此的项目。摘要应说明程序姿态。只有让读者知道他们是试图改变政策、实施、合同文本、时机还是监督，才能公平地评判一条评论。

这就是为什么短语“在审查公共评论后”本身是不够的。审查可以意味着从“我们阅读并调整了提案”到“我们阅读并继续推进”之间的任何含义。一份透明的摘要应描述剩余的自由度。它应说明哪些议题仍可变更，哪些受先前承诺的约束，以及哪些需要另一个论坛来处理。这种坦诚或许会让评论者失望，但它能防止虚假的预期。

决策者不应是唯一的叙事者

在 ICANN 的公共评论模式中，ICANN 组织总结提交意见并识别共同主题。这或许高效，但却集中了叙事权力。准备提案、谈判合同或为董事会提供建议的组织，常常也撰写那份解释对该提案的反对意见的摘要。即使员工行事谨慎，自我审查的表象仍是不可避免的。

有几种方法可以降低这种风险，而无需为每项程序增设新的官僚机构。其一是在叙述性报告之外公布分类表。其二是允许评论者在最终报告前查看初拟的议题类别，并标记错误分类。其三是允许启动群体添加一列与员工摘要分开的回应，这样读者就能区分“评论说了什么”和“决策者对此怎么看”。其四是对涉及合同、费用、核心治理文件、问责机制或标识符稳定性的高影响程序，要求对分类进行独立审查。

关键的分离是在摘要与回应之间。摘要应尽可能公平地描述评论记录。回应则应解释 ICANN 将做什么。当两者被合并时，便存在一种诱惑：用计划好的回应语言来描述评论。尖锐的异议变成了“被现行保障措施解决的关切”。要求不同决策的呼声变成了“对替代政策的偏好”。法律性质疑变成了“关于授权的评论”。这些短语或许是准确的，但它们需要支撑。

将摘要与回应分开，也能帮助董事会。董事们需要知道，他们何时被告知记录包含了什么，又何时被建议该如何决策。员工的建议是正当的。问题不在于建议；问题在于，建议被伪装成了中立的压缩。收到一份编码后的摘要、一份回应表以及原始评论的董事会，能提出更好的问题。

一条切实可行的公共评论审计追踪

最低限度的公共评论审计追踪将包含六个层次。第一层是原始提交档案，带有时间戳、按规则公布的提交者姓名、附件以及后续勘误。ICANN 已在很大程度上提供了这些。第二层是一份机器可读的索引，将每条提交意见与议题代码相连。这份索引不应要求读者抓取网页或手动打开每个附件。

第三层是一份主题摘要，用日常文字解释主要论点。这就是那份熟悉的公开报告，但它应建立在编码索引之上，而非取代它。第四层是一个少数派与异议部分。该部分应识别那些在记录中不占主导、但因证据质量、受影响方地位、法律授权、运营风险或补救设计而十分重要的论证。

第五层是回应表。每个主要议题都应收到一条决策回应：已采纳、部分采纳、已驳回、推迟、超出权限、已处理，或需要后续工作。表中应包含理由，而不仅仅是标签。第六层是董事会使用声明。如果董事会依赖该报告，决议或理由应指明报告和决定性议题。如果董事会驳回了某一主要反对意见，它应说明原因。

这些层次都不要求董事会放弃裁量权。它们只是让裁量权的行使变得可复核。一个无法被复核的公共评论系统会沦为正当性仪式。一个展示其分类的公共评论系统则成为证据。

董事会记录无法修补一份薄弱的摘要

有一种诱人的说法：董事会理由才是真正的问责文件，公共评论摘要只是其中一项输入。这个答案是不充分的。到一份董事会决议被起草之时，摘要已经塑造了可见议题的宇宙。董事会的理由可以解释董事们为何批准了一项决策，但它往往无法揭示那些从未作为独立问题被呈递到他们面前的东西。

这一点之所以重要，是因为董事会材料并非中立的容器。它们是为决策会议准备的。它们必须简洁、在法律上谨慎，并与正在审议的提案保持一致。如果公共评论报告已将一组反对意见归入一个宽泛的标题下，董事会文件可能只会提及该宽泛标题，而非底层的差异。于是，决策记录重复了压缩，而非检验了它。公众看到了报告与理由之间的一致性，但这种一致性可能只意味着两份文件继承了相同的分类。

一份更有力的摘要能在董事会开会前降低这种风险。董事们应当不仅能看到员工的结论，还能看到结论之下的有争议的图谱。如果一项提案引发了定价、服务连续性、市场权力、公共利益依赖和程序授权方面的关切，这些关切应作为独立行出现。之后，一位董事可以决定只有其中一项是重要的，或者所有问题都已得到回答，或者有一项需要推迟。但不应该发生的是，在反对意见被搅拌成单一主题之后，董事被要求批准一项结论。

同样的道理也适用于董事会成员亲自阅读原始提交意见的情形。个人的勤勉是有用的，但它不是一种控制。公共治理不能依赖特定董事的阅读习惯。一种摘要方法应当在董事轮换时、在议程繁重时、在附件冗长时以及在决策紧迫时，都能发挥作用。该方法应当使记录变得易读，而无须信任任何单个人会注意到报告遗漏了什么。

重复的评论不应抹去不同的损害

意见量大的程序常常引来重复信息。ICANN 必须能够处理表单评论、活动文本和重复的反对意见，同时又不能假装每条相同的句子都增加了一个新论点。然而，重复管理也可能制造自身的扭曲。如果重复的评论仅被视作一场大众运动，摘要就可能忽略这样一个事实：不同的提交者将相同的反对意见附着于不同的损害之上。

设想注册管理机构协议程序中的一条定价反对意见。一家非营利注册机构、一位注册商、一位消费者维权者、一位安全研究人员和一位域名投资者，可能全都反对取消价格上限，但理由各不相同。非营利机构可能担心使命预算。注册商可能担心客户愤怒和续费摩擦。消费者维权者可能担心公益网站的锁定效应。安全研究人员可能担心被弃用的域名成为滥用目标。投资者可能担心域名估值的不确定性。顶行的句子是相同的，但风险地图却不同。

因此，一份好的摘要应以两种方式计算重复。它应识别重复的文本或活动提交，以免读者将数量与独立分析混为一谈。同时，它应保留附加在重复立场上的不同的损害理论。一千条写着“不要批准”的评论，可能包含着五种理由，这些理由必须被分开。正当性问题并非通过声称许多评论者反对提案来解决，而是通过展示反对意见实际上提出了哪些风险来解决。

这对于正式撰写能力不同的受影响方类别尤其重要。一个小型组织可能因缺少政策顾问而提交简短的反对意见。一个大型利益相关方团体则可能提交一封带有引证和拟议文本的详细信函。如果摘要只偏重文笔的打磨，大型利益相关方将占据主导。如果它只偏重数量，运动则将占据主导。正确的方法是对两者都予以记录，然后询问哪些论证与决策相关。

“超出范围”的认定也需要理由

“超出范围”是公共评论报告中最有力的短语之一。它可能是正确的。ICANN 的使命是有限的，并非每一条与互联网相关的申诉都属于 ICANN 的决策。一项注册管理机构合同不可能解决所有市场集中、言论、隐私、竞争法或国家监管的问题。摘要不应强迫董事会就超出其权限的事项做出决定。

但“超出范围”这一标签也能掩盖最困难的边界问题。一条评论是否超出程序范围，常常取决于程序是如何被框定的。如果拟议协议取消了价格约束，那么可负担性可能就是核心议题而非边缘议题。如果拟议政策影响联系数据的公开，那么隐私和执法获取可能就是核心议题而非附带议题。如果拟议的问责变革影响谁能质疑一项决定，那么成本和准入可能就是核心议题而非仅仅是程序性议题。

出于这个原因，“超出范围”的认定应附带理由。报告应说明，该议题是在 ICANN 使命之外、在启动群体的权限之外、在审议中的特定文本之外、已被先前的政策决定所确定，还是留给另一程序处理。这些都是不同的表述。使命限制意味着 ICANN 没有权力。程序限制意味着 ICANN 可能拥有权力，但选择不在此处重新打开那个问题。先前决定限制意味着评论来得太迟，而非无关。论坛限制意味着评论者应知道下一步该去哪里。

附带理由的范围认定也能减少怨气。如果报告解释了正确的场所，评论者可能会接受自己选错了渠道。他们不太可能接受一份记录了他们的关切、然后却无下文的摘要。在一个多利益相关方机构中，参与的失败是叠加的。一个在某程序上花费了时间、却看不到明显回应的人，不太可能再回到下一个程序。其代价不仅在于该程序的公平性，还在于未来证据的损失。

技术反对意见不应被压平为政策偏好

ICANN 的程序常常将政策价值与技术主张混在一起。一条评论可能声称，拟议的变更威胁 DNS 稳定性、削弱滥用应对、使注册管理机构过渡复杂化、损害数据准确性，或制造运营上的模糊性。这样的评论也可能将反对作为一种政策偏好表达出来。一份薄弱的摘要会合并技术主张与偏好，然后将整个包裹作为“分歧”予以驳回。

更好的方法是将各个部分分开。如果一位评论者声称，拟议的合同变更将削弱紧急过渡，摘要应识别出具体的过渡主张。之后，ICANN 可以回答：现有的紧急条款仍然足够，风险已在别处处理，该主张缺乏支持，或文本已被修订。如果该评论者还说董事会应因公共利益象征意义而拒绝协议，那便是另一项主张。将它们分开，就能防止技术警告因更宽泛的立场未能获胜而遭埋没。

这一区分对号码资源议题至关重要。关于唯一性、注册准确性、反向 DNS、路由安全依赖或分配资格的技术事实，可能仅由少数运营商提出。它们可能不以打磨过的公共政策语言出现。一份优先考虑宽泛主题的摘要会丢失它们。因此，编码手册应将技术证据与机构偏好分开标记，即使同一份提交中同时包含两者。

董事会不应需要成为每条主张的最终技术评审者。但它应需要知道，一项技术主张是否被提出，由谁有能力评估它，给出了何种回答，以及该回答是否改变了决策。这足以使决策可复核，而不必将公共评论报告变成一篇工程论文。

公众需要否定性的认定，而不仅是积极的变更

许多公共评论报告着重强调评论后发生了变化的内容。这很有用，但它可能制造扭曲的记录。如果一份报告详细列出了被采纳的编辑，却只笼统地提到被驳回的反对意见，读者就会在真正的争议可能位于别处的地方看到响应性。公众既需要肯定性的认定，也同样需要否定性的认定。

否定性认定意味着：这一反对意见已被理解、分类，并因这一理由被驳回。这相当于一家法院说明为何一项论证失败，但并没有将 ICANN 变为法院。它约束着决策者，因为理由可以在日后被检验。如果 ICANN 说，一项可负担性反对意见被驳回是因为合同不监管零售价格，未来的批评者就可以挑战该前提。如果 ICANN 说，一项时机反对意见被驳回是因为协议即将到期，未来的审查者就可以询问临时延期是否可能。如果 ICANN 说，一项技术关切已被处理，未来的事件就可以检验该主张。

否定性认定也制造着制度记忆。下一项程序可以看到哪些论点此前已被驳回以及原因。员工不能在某项关切反复出现时仅仅声称它是新的。评论者也不能在不触及先前驳回理由的情况下重复一项论点。辩论的质量将因记录的累积性而得以提升。

这正是公共评论摘要能成为真正问责工具的地方。不是通过将每条评论变为命令，而是通过将每条严肃的反对意见变为一项附带理由的公开认定。ICANN 不需要更多的仪式性咨询。它需要的是可被复用、可被审计、可被改进的咨询记录。

来源局限与无法推论之事

本文依赖 ICANN 当前的公共评论描述、ICANN 章程，以及拟议.org 续约协议的公开程序页面。这些来源显示了正式的咨询模式、最低公开期限、总结报告的角色、报告将供董事会审议的承诺，以及该特定程序中的实质性定价议题。

在此被审查的来源并不能建立起对每条.org 提交意见对照报告每行文字的完整统计审计。它们并不证明某个特定员工故意最小化了某项反对意见。它们并不证明每位董事会成员都只依赖摘要而非原始评论。它们并不证明一份不同的摘要本会改变最终决策。证据支持的是一项结构性主张：公共评论摘要的影响力足够之大，以至于其分类方法应当可见。

这一区分很重要。对摘要设计的批评不应演变为对动机的指控。更强的制度性论点是更简单的：当同一机构撰写提案、接收评论、总结评论并推进到决策时，公众需要一条从评论到回应的可追溯的桥梁。那座桥就是缺失的保障。

一份更好的 ICANN 报告应是什么样子

一份更有力的 ICANN 公共评论报告应从提案和剩余的选项入手。它应说明启动群体是否可以修改文本、重新开启谈判、推迟某项条款、有条件地批准、拒绝提案，还是只能做出实施调整。接着，它应公布一份议题编码手册。读者能确切看到评论是如何被分类的。

报告应区分独特论证与重复背书。它应避免暗示一份请愿等同于一项技术分析，或一项技术分析等同于社群正当性。它应记录受影响方类型，而不赋予机构化的打磨文字以特权地位。它应将少数派论点保存在单独的部分中。它应解释哪些反对意见被驳回以及原因。

之后，董事会文件应将决策与报告连接起来。如果一条价格上限反对意见被驳回，理由应指明支配性的原因。如果一条安全警告被采纳，文本变更或监测承诺应是可见的。如果一条法律授权异议被认定为超出程序范围，报告应解释提出该问题的可用途径。如果某条评论要求推迟而董事会拒绝，时间线的理由应是公开的。

其结果不会消灭分歧。它可能使分歧更尖锐，因为落败的论点会被更清晰地指明。但它将改善机构的正当性，因为落败方可以看到自己为何落败。在一个多利益相关方的环境中，这常常就是分歧与疏离之间的区别。

为何这超出名称本身的意义

尽管.org 例子来自 ICANN 的域名一侧，但公共评论摘要问题也同样影响着号码资源治理。ICANN 的使命包括对互联网协议号和 AS 号的最顶级协调，以及推动受影响社群制定全球性号码注册政策，并履行与 RIR 商定的任务。当 ICANN 就治理文件、全球政策、问责机制或 IANA 相关安排征求评论时，同样的摘要机制能决定运营商的反对意见是否仍然可见。

号码资源决策常涉及较小的受影响群体、复杂的技术依赖和较低的公众关注度。区区几条评论所携带的运营信息，可能超过一项大型的一般性利益程序。如果一份摘要将这些评论压缩为平淡的主题，其代价可能要到某次注册、分配、反向 DNS 或连续性决策在压力下失败时才显现出来。因此，摘要方法应当恰在最需要的地方——在参与薄弱且专业知识专门化之处——最为强健。

教训不是公共评论应按人头数来治理，而是公共评论应当留下可用的记录。ICANN 的正当性较不取决于它邀请评论的频率，而更多地取决于它能否展示评论如何改变、收窄或未能改变一项决策。一份由决策系统撰写的摘要，只有当其分类对检查开放时，才值得信任。

结论

公共评论并非自动生效的问责。当公众能够将一份提交意见追踪到一条被分类的议题、一条被保留的少数派观点、一条回应和一项附带理由的决策时，它才成为问责。ICANN 已经在发布评论和总结报告，作为其治理模型的一部分。下一个标准应当是摘要内部的这种可追踪性。

决策者或许需要做总结。它甚至可能是唯一有能力及时产出一份报告的实用主体。但当它撰写摘要时，它必须展示其工作。否则，咨询中最重要的行为便不是公开提交评论，而是那个安静的、制度性的行为——决定那些评论意味着什么。

已审查的来源