RIPE NCC 资源树已上线，未检查子项不能借父级绿灯

摘要

RIPE NCC 10 月 19 日在数据库网站上线资源树和资源检查，取代原来的表格；LIR Portal 内的 Assisted Registry Check 整合还在后面。
上线之后，最要紧的是别把“检查通过”“需要复核”“尚未检查”画成同一盏灯。没有精确匹配的路由对象，只能先记为观察结果。

父节点亮绿灯，树枝查到哪儿了

10 月 19 日，RIPE NCC 的 Edward Shryane 告诉数据库工作组，数据库网站的 Resources 页面已经换上资源树，并启用资源检查。旧表格退场了，父级分配和子级资源现在可以沿树枝展开。Shryane 还说，这套功能将进入 LIR Portal 的 Assisted Registry Check 流程；那是下一步，不是这封部署通知宣布已经完成的部分。

两天后，RIPE NCC 的设计团队点出这棵树最容易骗人的地方：父级显示绿色时，下面某个子资源可能还没查过。大型资源层级需要大量 API 调用，检查可能没走完。页面越会替成员归纳，越需要交代究竟查到了哪片叶子。

设计稿还介绍了资源侧栏：登记资料、使用情况、RIPE Database 对象和路由信息集中在一处。它能把记录转成待办线索，条件是每条提示都说清观察到了什么，以及哪些部分还没有证据。

提示可以省时间，也可以把判断说得比证据更满。RIPE NCC 说，大型资源层级里的每个父级和子级都跑一遍检查，可能需要大量 API 调用；有些子资源尚未检查。设计团队仍在研究如何让用户看见这段未完成的工作，而不是误以为整棵树都已通过。

状态至少要有三种：已检查且通过、已检查且值得复核、尚未检查。“未知”不是错误，却是一个必须显示的状态。隐藏它，用户看到的就不是通过，而是一张空白检查单套上绿色外壳。

自动检查看见了什么

RIPE NCC 的设计文章列出几类检查情形：已公告但没有登记使用情况的 IPv6 分配；小于预期规模的 IPv6 指派；登记了指派却没有公告的分配；在 BGP 路由表中不可见的 ASN；以及可能需要补充指派登记的在用地址空间。部署邮件确认资源检查已上线，但没有公布逐项功能清单或各项检查的生产覆盖率。

这些提示不是同一种证据。登记缺项可能需要补记录；ASN 不在某个路由表里，首先是一条可见性观察；路由对象没有与资源精确对上，则可能因为路由采用了更具体的前缀、覆盖前缀或其他有效配置。RIPE NCC 明确指出，单凭“没有精确匹配”发出警报会误导成员，因此设计倾向于先提供中性说明。

这比每遇到一个不规则形状就画红三角可靠。网络团队看到警报，就要有人花时间查它。所有异常都叫“问题”，人会学会忽略警报；系统没查过却给绿色，人会把空白当成结论。两种设计都在让用户替界面补课。

RIPE NCC 的 My Resources API 文档说明，账户数据可以包括 ASN、IPv4/IPv6 分配与指派、历史 IPv4 资源，以及状态、登记日期和 RIPE Database 对象链接。改版页面会在记录上增加解释，但每条记录本身仍不会自动说明该采取什么行动。成员需要知道系统比较了哪些数据、发现了什么，以及下一步由谁处理。

一个状态词，就是一项小决定

“需要复核”给具体情况留了位置；“问题”听起来像已经判案；“没有找到精确匹配”则只描述系统看见的现象，没有假装知道路由设计的全部原因。

这套设计已经开始区分可行动的复核项与需要解释的信息，也准备说明每条提示为何出现、可能意味着什么、可以采取什么动作。RIPE NCC 安排在 RIPE 93 测试成员能否看懂资源树、识别需要关注的条目、解释自动检查结果，并理解从 My Resources 转到现有 Registry Check 服务的路径。

公开记录还缺 RIPE 93 的测试结果和生产检查覆盖报告；带日期的测试报告与逐资源检查状态定义，会改变目前的判断。