Summary

  • RIPE NCC 将 RPKI Dashboard 的维护排在 2026 年 11 月 3 日 CET 21:00–21:30；RIPE NCC Access、LIR Portal 和 RIPE Database 的另一项维护排在 21:00–21:10。两份状态记录列出的受影响组件不同。
  • 10 月 23 日，这两组组件也同时开窗。RIPE 于 CEST 20:07:44 通告控制台维护完成，20:29:56 才通告登录、门户与数据库维护完成。相差约 22 分钟的是通告时间，不是会员实际无法操作的时长。

门口写着 21:10 结束维护，门后的控制台写着 21:30。会员该看哪只表？RIPE NCC 官方状态页对 11 月 3 日列出两项独立维护，都从 CET 21:00 开始。RPKI 项目计划到 21:30，受影响组件仅列 RPKI Dashboard，正文预告控制台届时不可用。另一项目计划到 21:10，组件是 RIPE NCC Access、LIR 会员门户和 RIPE 数据库。它只给出笼统的维护通告，没有说明会员能在哪一分钟完成一次资源操作。

两组名字在会员工作流程里连在一起。RIPE 的托管 RPKI 使用指南要求会员用关联 LIR 的 RIPE NCC 账户进入 RPKI 控制台，再管理路由源授权 ROA。RIPE NCC Access 指南也把控制台列为资源管理入口。状态页可按组件开两张卡，运营人员修改 ROA 时却必须经过入口和应用。拆开的维护计划最终要在同一个人的操作里合拢。

10 月 23 日曾有同样的双卡开窗，但计划时长不同。当日的 RPKI 记录安排 CEST 20:00–20:30，登录、门户和数据库记录安排 20:00–21:00。前者在 20:00 标记进行中，20:06:47 标记验证，20:07:44 通告完成；后者 20:01:07 标记进行中，20:29:56 通告完成。两次完成通告相隔 22 分 11 秒。

11 月的排程把计划长短倒了过来：入口侧计划先结束，控制台二十分钟后结束。两个月份共有四份独立状态记录，这些记录没有给出“同一项技术改动重复执行”的证据。十月的时间戳说明 RIPE 何时对每项维护发出完成通告，没说明会员何时实际登录成功、打开控制台并保存一次 ROA 修改。

组件范围也要读准。11 月那张标题叫“RPKI System Maintenance”的卡，具体只列控制台。RRDP、rsync、ROA 管理 API 和 BGP 路由不在这两张卡的未来状态记录里。另一张卡列 SSO、门户、数据库。RIPE 给出了计划窗口，却没有给出一条跨组件操作的验收记录。会员所需要的结束语很简单：能否认证，能否进入控制台，能否提交并确认 ROA 修改。