摘要

  • Milan 初步报告的第 3.1 项要求检验 80% 的 IETF 参会者能否以不过度的努力或成本取得签证；公开说明谈的却是第 3.2 项的非歧视问题，两项仍同时显示绿色。
  • 这是一处公开证据与测试项目没有绑定的缺陷，不是 Milan 未通过门槛的证据。征询意见阶段仍可补充计算、改正文字或调整状态。
  • 同日、同模板的 Montevideo 报告把两项分开：3.1 说明 80% 的入境可达性，3.2 另谈非歧视。这个对照只用于识别记录结构，不表示哪座城市更合适。
  • Daniel Kade 建议为每个评估状态附上一张“标准—证据凭据”，保存题目、来源、算法、截止时间、不确定性、责任人、修订史和后续决策阶段，同时不公开个人签证资料或商业报价。

一个绿灯借用了邻居的答案

Milan 报告形成于 2026 年 7 月 9 日，列出的潜在场地是 Allianz MiCo。五页报告检查九个项目，包括场地、开放互联网、签证、旅行风险、健康、空气质量、社会动荡以及参与者对歧视风险的亲身经验。汇总结果是八项满足、零项不确定、零项不满足、一项尚未评估。读者先看见的是颜色：绿、黄、红、灰。

第 3.1 项的文字非常具体：签证要求是否能让 80% 的 IETF 参会者在没有过度努力或成本的条件下取得签证。这个问题至少需要一个参照人群，并把其国家分布与免签、普通申请渠道、费用和办理负担对应起来。官方模板给出的示例也正是这种写法。

Milan 报告填入的说明却是：意大利签证规则不会因为种族、族裔、宗教、性别、性取向或性别认同而构成歧视，并链接到意大利外交部门。这段话适合回答第 3.2 项。下一行确实问非歧视问题，也使用了实质相同的说明和链接。两行都亮着绿灯。

于是，公开文件中看不到 3.1 所需的关键连接：采用了哪些会议的参会者分布，以国籍、居住地还是通常出发地统计；免签与标准申请分别覆盖多少；怎样定义“不过度”的努力和成本；缺失情况如何处理；评估截至哪一天；最终百分比是多少。

这里必须克制。也许内部工作表已有完整计算，只是报告粘贴错了句子；也许准备在反馈后补上；也许状态还需要重评。公开材料无法区分这些可能。因此，可靠结论不是“绿灯错误”，而是“这盏绿灯的公开依据无法从它所在的记录中复原”。

Montevideo 只是结构对照

同一天形成的 Montevideo 报告使用相同模板。它在第 3.1 项明确写道，按国家计算，80% 的参会者可以免签进入 Uruguay，或以合理成本走标准申请程序。第 3.2 项则另行说明签证规则的非歧视性。两项各答各题。

这个对照不应被写成城市竞赛。Montevideo 还有两项灰色：空气质量数据不足，以及需要参与者亲身经验的歧视安全问题；其汇总为七项绿色、两项未评估。Milan 是八项绿色、一项未评估。颜色总数不是排名，两个报告也都没有建议批准或拒绝。

Montevideo 的作用仅是证明：模板本身能够区分“多少人可以合理入境”和“规则是否歧视”。Milan 的重复说明不是表格必然产生的含混，而是某个答案落在了错误的行上。

这个对照还暴露出更普遍的问题。Montevideo 的说明回答了正确问题，却仍未展示 80% 的计算。只要采用精确比例，治理上就需要解释分母和方法。可以公布聚合表：参照会议、按国家汇总的规模、官方入境渠道、通常费用和步骤、缺失数据、最终结果。无须披露任何人的姓名、国籍、护照或签证经历。

“无建议”恰恰是初步报告的正确状态

两份报告的建议栏没有给出批准或拒绝，不是流程遗漏。IETF 当前的 Venue Assessment Report 模板明确说明，初步报告只有部分资料，因此不作建议；社区反馈以及由反馈触发的进一步研究，构成初步版与最终版之间的新增内容。

8 月 14 日的征询通知按这个设计运行。IETF Administration LLC 说正在考虑 Montevideo 和 Milan 作为未来会址，两者均为“无建议”，并要求通过一个公开可查看、不可订阅的单向邮件地址提交意见，反馈还会汇总到公开 Trello 看板。通知称征询将于 8 月 28 日结束。截至本文观察时点，称任何一座城市已获批、已被否决或已被选中，都没有依据。

两份报告的第 6.1 项也说明为什么初步阶段必须容纳空白。这项测试不是从法律条文抽象判断城市是否安全，而是要依据 IETF 参与者对种族、族裔、宗教、性别、性取向或性别认同歧视的亲身经验。两份报告都把它留为灰色，等待社区反馈。远程研究人员不能用旅行警示替别人制造“亲身经验”。承认证据尚未到位，是合规的限制，不是评估失败。

反馈之后，IETF LLC 可以继续远程研究、改变判断，并发布带有批准或拒绝建议的更新报告。拒绝意味着该城市的路径停止；批准也只是进入下一步。随后还有详细评估、实地考察的可能、成本、酒店和本地支持。若出现与 IETF 开会核心目标有关的疑虑，IESG 可能在自己的权限内作出可行性判断。再往后，IETF LLC Board 审阅机密决策材料，之后才是合同和公开通知。

这些不是一件事的不同叫法。绿色项目不是 Executive Director 的最终建议；建议不是商业尽调；IESG 的判断不是 Board 的批准；Board 批准也不是签订合同。初步报告的价值，是把证据可靠地交给下一环，而不是替下一环行使权力。

“压倒性多数”怎样变成 80%

RFC 8718 规定了更宽的制度边界。IASA 要运用最佳判断，尽可能保持流程开放，并在考虑合同之前足够早地让社区表达意见。重要的城市标准之一，是包括签证在内的入境障碍应当很可能让“压倒性多数”愿意参会的人能够到场；对“旅行障碍”还要结合会议能否成功举办作宽泛理解。

报告模板把“压倒性多数”操作化为 80%。这一步有价值，因为它把一个有弹性的形容词变成可以检验的阈值。与此同时，它也带来新的说明责任：比例必须有分母、参照期和计算规则。否则，精确只存在于问题里，答案仍然模糊。

“IETF 参会者”可以有多种合理定义：若干近期会议的注册人数、去重后的个人、按每次会议累计的出现次数，或针对特定地区的预测。国家权重也可以按国籍、居住地或通常旅行出发地。每种选择都影响结果和隐私。“标准申请”是否包含需要长途前往领事馆的程序？“合理成本”按企业差旅还是自费贡献者衡量？本文不替评估者选答案，只要求公开记录说清实际采用了什么。

入境规则还会变化。来源和检索日期必须同行。某项结论可能在 7 月 9 日基于当时资料合理，几个月后却需要重算。有时间边界的记录不仅保护参会者，也保护评估人员：后来的人可以指出条件变化，而不必把时势变化误写成当初的任意判断。

反馈阶段应当修记录，而不是猜记录

对 Milan 错位最相称的处理，是在现有公开反馈渠道中指出它。一个可执行的意见只需说明报告版本和第 3.1 项，指出其说明回答了 3.2，并请求公开 80% 的聚合方法、补上正确说明，或在证据不足时调整状态。同时明确：意见不主张 Milan 不合格，也不主张哪座城市应获选。

RFC 8711 第 4.7 节还提供了更正式的问责渠道。若参与者认为 Executive Director 或 Board 的决定或行为不符合 IETF BCP 或 LLC 政策程序，可以请求 Board 正式复核，说明行为、违规理由和建议补救，LLC 应公开请求与回应或结果。这个机制是重要的兜底，但不应被当成修订一份正在征询中的初步表格的日常入口。普通反馈更早、更轻，也更合比例。

修订本身应当留痕。最终版可以简要注明：初步版 3.1 的说明误用了 3.2 的文字；现已加入何种计算或来源；绿色是否保持、改变或转为待评估；修订日期和原因是什么。静默替换会让页面更干净，却让读者无法知道社区反馈是否发挥作用。

版本记录不是惩罚错误。它把录入错误与政策转向分开，让后来使用摘要的人知道读的是哪一版，也避免旧的“八项满足”在理由已经变化后继续脱离上下文传播。对依赖多次交接的机构而言，改正行为本身也是证据。

一张“标准—证据凭据”

Daniel Kade 的建议，是给每个评估项目附一张很薄的凭据。这不是 IETF 已采纳 的政策，也不是要新建审查机关。它只负责让状态在被复制、汇总或交到下一阶段时，不丢掉含义。

凭据首先记录权威来源和版本：RFC 条款、后续更新、模板版本。随后保存稳定的测试编号和完整题目，再写明作用范围——国家、城市还是具体场地——以及评估对象和截止日期。

核心部分把证据逐项连接到问题。若是计算，就列出参照人群、权重、阈值、缺失处理和例外；若是外部资料，就给出检索日期，并用一句话说明它为何回答这一题。状态与不确定性一起记录：“满足”必须带依据，“无法评估”必须写明等待什么证据。

凭据还要说明责任与阶段。Secretariat 的初步判断、Executive Director 发布的初步报告、反馈后的最终报告和后续决策材料不是同一项行为。修订史保存旧状态、反馈引用、新文字、日期和理由。进一步研究、最终建议、必要时的 IESG 判断、Board 决策和合同状态继续分栏，不合并成一个颜色。

边界同样明确：不公开个人签证史、受保护特征、私人反馈、会址报价或 Board 的机密商业材料；不把会址决定改造成公众投票；不从 LLC 手中夺走行政判断。聚合方法足以让外界核验，又不会把透明度变成隐私暴露。

截止时点能够成立的结论

截至 8 月 28 日，公开材料支持的判断很有限，也很清楚：Milan 第 3.1 项的说明没有回答该项问题，而与第 3.2 项的说明实质重复；两项均为绿色；官方模板和 Montevideo 报告都把这两道题分开处理；目前仍是初步征询阶段，没有最终建议。

材料不支持以下说法：Milan 低于 80%，绿色一定要改成红色或黄色，Montevideo 更应获选，或者内部从未做过相关研究。也无法预测最终报告、商业可用性、Board 判断或合同。

治理的关键并不总在宏大的决议中。很多权力在一张表格被交接时开始积累。若每个格子都能回到自己的问题、方法和证据，后续裁量仍可追溯；若不能，颜色就会代替理由，之后每一次引用都让它看起来更确定。绿色可以是摘要，不能是“请相信我们”的替身。

证据边界

本文使用两份初步报告、现行模板、征询通知、IETF 会址流程页面，以及 RFC 8718、8711 和 9712。本文没有 Secretariat 内部工作底稿、按国家计算表、私人意见、完整 Trello 记录、机密商业报价或后续最终报告，因而不能判断最终适用性和会址选择。

“报告没有展示计算”只是一项披露结论，不证明计算不存在。Montevideo 只说明字段应如何分开，不验证其比例，更不构成排名。“标准—证据凭据”是 Daniel Kade 的治理建议，不是 IETF 现行规则。

来源

  1. Montevideo 与 Milan 会址评估征询通知
  2. Milan Venue Assessment Report
  3. Montevideo Venue Assessment Report
  4. IETF Venue Assessment Report 模板 v3
  5. IETF 会议场地识别与选择流程
  6. IETF 城市评估索引
  7. RFC 8718：IETF 全体会议场地选择流程
  8. RFC 8711：IASA 2.0 的结构
  9. RFC 9712：IETF 会址要求复核