摘要

  • AFPUB-2020-GEN-001-DRAFT01 设想把若干会员状态集中展示，并以周期性检查、自动通知、重复提醒和工作人员提示推动纠正；它最有价值的用途，是把一项可能的差异连同规则版本、证据、时间和修改记录清楚交给相关会员。
  • 付款、文件、WHOIS、路由宣告、反向 DNS、PI 再分配、转移授权与回复历史不是同一种证据。一个颜色、标签或重复次数可以安排核实优先级，却不能证明违约，更不能成为停止服务、撤销资源、收回资源或关闭会员资格的权力来源。
  • AFRINIC-32 于 2020 年 9 月记录的结论是“未达成共识”，官方页面现将 Draft 1 标为 Expired。现有材料不证明它获采纳、实施或曾对任何会员产生处分，也不证明存在实际损失。
  • 合理的替代设计应先以私密、只供观察的方式运行：逐项说明数据来源和适用条款，允许回应、纠错与有理由的人工复核，保留前后版本，并把任何可能影响网络连续性的后果与仪表盘状态彻底分开。

L3 — 一块屏幕，数种证据

登录之后，会员究竟会看见什么

Draft 1 的吸引力不难理解。互联网号码资源登记服务分散着许多日常义务和技术记录：账款可能在财务系统里，法定文件可能在会员档案里，联络人资料留在 WHOIS，反向解析由另一套工具处理，路由宣告又存在于外部运行环境。会员若想确认自己的登记状况，可能要分别联系不同人员、核对多个页面，再判断某项提示究竟是数据延迟、操作疏忽，还是需要正式回应的问题。

提案希望在 MyAFRINIC 中给每名会员呈现自己的状态，并尽可能自动、周期性地复查。这里的“会员可见”必须准确理解：它不是公开点名每一家会员，更不是向市场发布逐户名单，而是让登录后的会员看见自身指标。这个私密边界十分重要。只要状态仍属于会员与登记机构之间的纠错信息，它首先是一项服务；一旦未经核实的状态泄露或被公开，它就可能变成声誉指控、安全线索或交易障碍。

官方页面记录，AFPUB-2020-GEN-001-DRAFT01 的题名为 Policy Compliance Dashboard，版本为 Draft 1、1.0，提交日期是 2020 年 2 月 17 日，作者为 Jordi Palet Martinez、Frank Habicht、Mark Elkins 和 Haitham El Nakhal。页面如今把它标记为 Expired。时间和状态共同限定了本文讨论的对象：我们面对的是一次设计提议，不是一套已经运转的制度。

提议列举的指标跨度很大，包括付款或文件状态、会员是否回应、资源是否被宣告、WHOIS 资料是否及时、反向 DNS、PI 资源再分配、转移授权，以及所谓重复或持续出现的违反情形。把这些项目排列在一个页面上，视觉上当然整齐；但整齐不是同质。界面可以把九个格子排成同样大小，却不能据此把九种事实变成同一种法律或技术判断。

付款记录最接近可核对的交易事实，却仍可能受入账时间、币种、银行传递或争议款项影响。文件状态可能只说明登记机构尚未收到某件材料，也可能涉及文件真实性、授权范围或更新周期。会员没有回复，可能是联络地址失效、通知未送达、内部交接，或问题本身仍待说明。资源没有被观察到宣告，并不自动表示持有人违反了什么；持有人可以基于网络设计、储备、迁移或安全考虑暂不宣告。

WHOIS 资料的新鲜程度取决于哪个字段、哪一时间点和哪项更新要求。反向 DNS 可能出现技术配置错误，也可能根本没有与某项强制义务对应。PI 再分配和转移授权涉及事实链、授权链与适用文本，不能只靠一个外观模式判断。至于“重复”或“持续”，更必须先回答：重复的是同一事实、同一条款还是同一个机器信号？上一次差异已经纠正后，计数是否归零？规则版本改变后，旧记录还能否算入？如果这些问题没有答案，计数器只是把不确定性累加成更醒目的不确定性。

可见性为何仍然值得做

指出分类风险，并不意味着否认仪表盘的善意用途。会员确实可能错过政策或合同文本的变化，也可能不知道旧联络信息、WHOIS 字段或反向解析配置已经与登记记录脱节。一个私密页面若能提前显示差异，可以减少意外；一套对所有会员一致发出的通知，可以降低“有人被提醒、有人被遗漏”的不均；一条完整的修改记录，可以让会员与工作人员知道问题在何时出现、怎样回应、何时解决。

这种设计也能降低现实成本。过去需要会员服务人员人工搜寻的记录，可以在一个页面集中呈现；过去必须来回写信才能确定的数据点，可以先由机器定位；过去容易遗忘的修改，可以留下前后版本。对于正常经营的网络运营者，尽早发现陈旧信息通常比在转移、融资、尽职调查或故障期间才发现更便宜。对于 AFRINIC，较清楚的证据说明也能减少含糊工单和重复沟通。

因此，问题不在于“要不要检查”，而在于检查结果被赋予什么含义。一个健康的会员页面可以说：“在某个时间点，数据源 A 与规则版本 B 的字段 C 不一致，可信程度为某个明确范围，请核对以下原始记录。”它不应只说“不合规”，更不应把“不合规”当作已经成立的责任判断。前一种表达邀请验证；后一种表达把结论藏进标签。

有用的页面还应允许会员看到通知送给了谁、何时送达、是否退信、会员作了什么回应、工作人员是否查看、哪项数据后来改变。若系统改判，也要保留原始状态与改判理由，而不是让错误像从未发生。这样的历史不仅保护会员，也保护登记机构：它能说明当时依据了什么，并使技术故障、错误数据或规则误配更容易被发现。

“自动化越多越好”只有在任务边界清楚时才成立。机器适合比对日期、字段、是否存在记录，或在指定条件下提醒某项资料尚未更新。机器不适合在缺少上下文时推断授权、真实性、正当理由或条款适用性。设计成熟度不应以自动化覆盖多少项目衡量，而应以系统是否知道何时停下来、把不确定性原样交给人来衡量。

一条提示需要携带的最小解释

每项提示至少应回答六个问题。第一，观察到的究竟是哪一个事实，而不是笼统的“状态”。第二，数据来自哪里，是否可能延迟或由第三方控制。第三，比对的是哪一份、哪一版规则或合同文本。第四，检查何时运行，结果的有效时限多长。第五，哪些因素可能造成误报。第六，会员怎样提交更正、补充说明或要求人工复核。

这六个问题把屏幕从判定器改造成证据目录。例如，反向 DNS 项不应只有红灯，而应说明被检查的资源、检查时间、观察结果、预期配置的依据，以及技术变化传播可能造成的等待期。文件项不应只显示“缺失”，而应说明所指文件、接收记录与要求依据。转移授权项尤其需要显示授权链中的具体缺口，不能因为系统没有找到某个字段，就把未找到等同于未经授权。

不确定性也必须可见。它不能被埋在帮助页面，更不能只供工作人员查看。若一项判断取决于外部路由观察、第三方数据或人工解释，会员应在第一眼就知道它不是确定事实。界面中的黄色、红色或数字即使没有正式法律名称，也会在实际工作中形成等级感。真正的保护不是换一套温和颜色，而是把状态拆开：观察事实、适用依据、通知状态、会员回应、人工复核和最终纠正分别显示。

提案还设想在复查或更新后通知会员，对页面显示的差异周期性提醒，并向工作人员发出提示。这些功能可以服务于纠错，但每一种通知都应与结论分开。通知证明系统发送过消息，不证明收件人看到；退信证明投递失败，不证明会员拒绝回应；多次提醒证明时钟运行，不证明差异越来越严重。提醒次数不能偷偷变成责任程度。

工作人员提示也只能创建待核实事项。谁接手、看了哪些材料、为什么需要更多信息、是否发现误报，都应留下理由。人工参与会改善机器判断，却不会把本来缺少权力依据的措施变得有权。一个人点击确认，比机器自动确认更适合处理语境，但“由人确认”只说明决定方式，不说明决定者有何种权力。

从提交到“未达成共识”

Draft 1 的时间线短而清楚。它在 2020 年 2 月 17 日提交。提案除了仪表盘、周期复查和通知，还写入另一条路径：当证据显示可能存在不符合情形时，进行更全面调查，并依据 RSA 考虑进一步行动。提案列出的后果阶梯相当广，包含联络与整改、公布、删除相关名称服务器记录、收回、停止服务、撤销以及关闭会员资格；另有一项设计允许在工作人员评估后，由 Board 因关键战略基础设施或特殊情况延长撤销期限。

这些文字必须按其真实地位阅读：它们是拟议文本。它们能够证明提案者想把哪些后果写进设计，不能证明后果已有有效权力来源，也不能证明任何会员曾受到这些措施。把“提案列出”改写成“AFRINIC 可以”，会越过材料没有提供的关键一步。

2020 年 8 月的影响评估暴露了设计中尚未解决的问题。工作人员区分政策层面的不符合与合同层面的不符合，并指出已有付款和反向 DNS 等工具，只是尚未整合到一个仪表盘。评估引用了 RSA 中一条通知与补救路径：书面通知、邀请会员说明理由或改正、三十日回应期限，以及当 AFRINIC 认为答复或补救令人满意时停止后续行动。这个程序信息有助于理解现有合同文本，却不能替任何具体事项证明条款适用、证据充分或某项后果有权实施。

评估还追问“重复或持续”应以什么阈值认定、在纠正后如何重置，并要求说明拟议公布、域名对象删除和隔离等机制。这些不是次要的技术细节。阈值决定普通错误何时被升级，重置决定已经纠正的会员是否仍背负旧标签，公布机制决定私密服务何时变成声誉风险，删除与隔离机制则可能触及真实运行。若这些问题没有被明确回答，自动化只会更快地传播含糊。

开发成本同样不是抽象问题。评估预计 MyAFRINIC 需要显著开发投入，Member Services 需要承担额外工作，并可能增加人员。AFRINIC-32 的讨论同时记录了支持和疑虑：有人认可提高可见性，也有人担心功能重复、成本、资源负担以及自动通知是否有效。这些意见说明便利并非免费；一个状态越容易生成，就越需要有人处理误报、解释争议和维护规则版本。

2020 年 9 月，AFRINIC-32 共同主席记录的结论是 No Consensus，并把提案退回邮件列表讨论。官方页面目前把 Draft 1 标为 Expired。到此为止，材料可以支持的是：有人提出了一个系统，工作人员评估了它，会议讨论了它，它没有在那次会议达成共识，后来页面显示它已过期。材料不能支持它获采纳、批准、实施或曾对真实会员作出判断。

这一限制不是修辞上的谨慎，而是事件本身的一部分。若一篇分析把未生效设计写成既成制度，就会犯与坏仪表盘相同的错误：把一项记录变成超过记录所能证明的结论。本文不会推定实际会员状态、实际申诉、实际处罚、实际撤销、实际关闭、实际收回或可量化损失，也不会把后来出现的提案、争议或机构事件倒灌进 2020 年 Draft 1。

第一层结论：把不同保持为不同

L3 层面最重要的设计原则，是拒绝把方便聚合误认为事实同类。会员可以在一个页面查看多个项目，但每个项目必须保留独立证据链。付款差异不能借用 WHOIS 的判断方式，路由观察不能借用文件真实性的确定语气，回复历史不能借用合同违约的标签，重复计数不能借用处罚阶梯的威慑。

如果屏幕必须提供总览，它最多可以表示“有几项需要查看”，不能表示“会员有几分不合规”。前者是任务管理，后者是责任压缩。总览还应允许会员直接进入原始证据，而不是让颜色成为唯一可见信息。任何总状态都要服从底层细节，不能反过来覆盖细节。

在这条边界内，仪表盘确有公共价值：更准确的登记资料、更早的技术纠正、更一致的会员通知、更清楚的修改历史、更少的支援往返。离开这条边界，页面就会开始扮演它无权扮演的角色。它不再只是告诉会员“账本与某项依据出现差异”，而是在暗示“账本已经判定你有过错”。这正是下一层必须阻断的转换。