要約

  • RIPE NCCは2026年11月3日21時06分58秒CET、RPKI Dashboard専用の保守記録を完了にした。開始の更新は21時00分08秒。別のAccess、LIR Portal、Database保守記録は21時08分以降も進行中で、部品一覧に同じDashboardを含んでいた。
  • RIPEの部品状態APIはその時点でDashboardをunder_maintenanceと表示した。専用記録のcompletedは一件の作業票の終了を示すが、会員がログインしてROAを送信できたかを示す実地試験は公開されていない。

完了したのは何か。同じ画面について公開された二つの状態を読むと、この短い問いが厄介になる。11月3日21時06分58秒CET、RIPE NCCはRPKI System Maintenanceの専用記録をcompletedにした。作業開始の記録から約6分50秒後だ。対象部品はRPKI Dashboard。ここだけを見た会員には、ROA管理画面の保守が終わったように見える。

しかしもう一件の保守記録はRIPE NCC Access、LIR Portal、RIPE Databaseを扱い、実施中の保存記録にはRPKI Dashboardも載っていた。21時08分58秒の更新は作業継続を告げ、21時41分を過ぎてもin_progressだった。予定終了は21時40分、さらに21時59分へ変わった。部品状態APIではDashboardのunder_maintenance表示が21時08分58秒に更新されている。専用票の完了より約2分後だ。Accessは21時41分21秒にoperationalへ戻ったが、Dashboard、Portal、Databaseは保守中のまま。専用票は完了、同じ部品の一覧は保守中。どちらもRIPE自身の表示である。

二枚目の作業票には途中で中身の変更もあった。作業前に保存した応答は、Database、Portal、Accessの三部品だけを挙げ、終了予定を21時10分としていた。実施中の二つの応答ではDashboardが四番目に加わり、予定は21時40分、21時59分と変わった。APIには開始と継続の更新が残るが、部品追加の時刻と理由、予定を合計49分延ばした経緯は説明されていない。現在表示される一枚の記録だけでは、計画がどう書き換わったかを読者は追えない。

最後の予定時刻を待たず、終了の記録が出た。Dashboard部品は21時46分51秒にoperationalへ戻り、二枚目の作業票は21時47分19秒に完了した。専用票が21時06分58秒に終わってから部品表示の復帰まで39分52秒。二つの完了通知の間は40分21秒だった。21時59分は改訂された予定であり、実際の終了時刻ではない。一枚の完了印が付いてから約40分間、同じ部品には別の公開状態が残った。

状態の語句を通信障害の測定値に変えてはいけない。completedは作業票に終了通知が付いたこと、under_maintenanceは公開状態欄の表示を示す。21時07分や21時22分に会員が実際にROAを変更できたかは、両方の表示からは決まらない。RIPEのホスト型RPKI案内によれば、会員はLIRに結び付いたRIPE NCC AccountからDashboardに入り、Route Origin Authorizationを管理する。Accessの案内もDashboardをその入口の先に置いている。一つの会員操作は二枚の作業票をまたぐ。

そのため、問題は単純な「どちらが早く終了したか」ではない。専用のDashboard票が閉じた後、同じ部品を含む別の票と部品状態欄はなぜ保守中だったのか。後者の票が状態を支配していたのか、表示だけがサービスの実態に遅れたのか。公開記録には会員としてログインし、画面を開き、ROAを提出した確認がない。サービスが動いていたとしても、読者がそれを判断するための運用記録が不足している。

RIPEは各部品に一つの権威ある状態を割り当て、その状態を保持する進行中の作業票を示せばよい。部品の追加や終了予定の変更も時刻付きで残す。最後に会員の操作経路を試した結果を添える。そうすれば完了印は、単なる作業管理上の達成ではなく、利用者が行動を決められる情報になる。

RIPE NCCの原資料