要約

  • 10月28日付の個人Internet-Draftは、RTRに購読方式と六種類の新しいPDUを提案する。ルーターはイベント通知、定期配信、または両方を選べる。
  • イベント用のPush Notifyは購読ID、変化の種類、シリアル番号を知らせるだけで、変更されたRPKIデータを載せない。データ列を送るのはPeriodic Updateである。

緊急のROA変更が起きたとして、運用者が知りたいのは「通知を送った時刻」より「ルーターが新しい状態を受け入れた時刻」だ。新しいRTRプッシュ案は数秒での伝播を動機に掲げる。しかしパケットの設計をたどると、警報と荷物は別便になっている。

既存の番号付き標準RFC 8210でも、キャッシュはルーターからの要求を待たずにSerial Notifyを送れる。受けたルーターは更新タイマーを待たず、Serial QueryかReset Queryをすぐ送ってよい。現行の8210bis草案も同じ区別を残す。先に鳴る警報はすでにあり、問い合わせの後で変更データが届く。

提案が新しく持ち込むのは、初期同期後の購読契約だ。ルーターがイベント通知か定期更新を頼み、必要なら解除する。IANAに求めるPDU番号は六つ。購読者ごとの状態を抱えるキャッシュにとって、この追加負担は、実際に短くなる時間で説明されなければならない。

イベント用Push Notifyの図には、購読ID、通知種別、シリアル番号が並ぶ。本文はROA、ASPA、ルーター鍵の変更を例示するが、その変更オブジェクトを入れる欄はない。通知の後にどうやってデータを送るかも定義されていない。警報が早く届いても、これだけでルーターの検証表は更新できない。既存のSerial Notifyも、すでに即時の問い合わせを促せる。

一方、Periodic Updateは合意した周期でCache Response、データPDU、End of Dataを送り出す。キャッシュはルーターが保持しているはずのシリアル番号を書き込み、ルーターは手元の番号と違えばデータを処理してはならない。この拒否権があるため、送信時刻だけでは速度を語れない。受信側が整合性を確認した時点まで測る必要がある。

IETFの文書記録では、これはStandards Trackを目指す個人草案で、状態はI-D Existsだ。再現可能な遅延比較や導入実験は載っていない。次の改訂でイベント後のデータ移送と測定条件が示されれば、速さの主張を検証できる。現段階で示されたのは、新しい警報と定期的な荷物便である。