要約
- 2026年9月7日付の
draft-ietf-sidrops-rtr-yang-09は、独立したRefresh Interval、Serial QueryとReset Query、Router KeyとASPA、さらに新しい5種類のError Reportに対応するカウンターを追加した。 - ルーターとキャッシュの境界は観測しやすくなるが、障害を起こした主体、ローカル経路ポリシーへの影響、利用者への影響時間までは証明しない。
- 提案された葉は読み取り専用の運用状態である。RFC 8342は収集統計を含むシステム状態を一時的と説明しており、後日の照会は保存された履歴の代わりにならない。
- 草案は二つの実装を挙げるが、いずれもdraft-03向けで、最終更新は2026年3月30日である。改訂09の新しい葉を実装した証拠ではない。
- Daniel Kadeは、収集時刻、カウンターのリセット起点、セッションとシリアル、タイマー、障害差分、運用者の処置を束ねる版付きキャッシュ状態受領記録を提案する。これは草案の要件ではない。
同じ切断でも命令は違う
外側のダッシュボードは、ルーターとキャッシュの切断をすべて一つの赤いランプにできる。開発中のRPKI-to-Router Version 2は、Transport Failure、Cache Restart、Cache Shutdownを別の事象として扱う。
キャッシュが一時的に停止しても、クライアントのデータが期限切れになる前に戻る予定なら、Cache Restartを通知する。Cache Shutdownは反対に、そのキャッシュから得たデータを破棄するようルーターに求める。長いトランスポート停滞はTransport Failureの報告とセッション終了につながり得る。ローカル経路ポリシーを適用する前から、三つの意味は異なる。
時間も状態の一部である。Refresh Intervalは通常の問い合わせ間隔、Retry Intervalは失敗後の再試行、Expire Intervalは新しい成功応答がないまま既存データを使える上限を示す。したがって、セッションが切れていても、取得済みRPKIデータが一定時間は有効という状態があり得る。「キャッシュ停止」だけでは足りない。
SIDROPSのYANG草案改訂09は、この境界をより多くの機械可読データにした。これがニュースであり、現実の障害や特定製品の適合を報告するものではない。
間隔と期限を分けた改訂
08から09への差分はrefresh-intervalを追加した。これは周期的なSerial Queryの間隔を秒で表す。同時に既存のrefresh-timeは、次回更新が起きる予定時刻を百分の一秒単位で示す、と定義し直された。
小さな変更だが、規則と現在状態を分ける。間隔はキャッシュから伝えられた方針であり、期限は特定の交換後に装置が持つ状態である。日付のない一つの値では、ルーターが間隔に従ったのか、切断後に期限を再計算したのか判定できない。
PDUの木にはSerial QueryとReset Queryの明示的なカウンターも入った。前者は既知のシリアル以降の変更、後者は有効な全データを要求する。Reset Queryの増加は、通常の差分取得とは違う復旧経路を示し得る。Version 2が扱うRouter KeyとASPAにも専用カウンターが加わった。
エラー側には、ASPA Provider List Error、Transport Failure、Ordering Error、Cache Restart、Cache Shutdownが加わる。従来の葉もError Reportコードとの対応が明確になり、提案された管理面はコード0から13までを表せる。
ただしカウンター名は判決ではない。ASPAエラーは不正なリストが経路選択に使われた証明ではない。Reset Queryは全量再取得の原因を説明しない。Restart通知は期限前の復帰を保証しない。
カウンターには起点が要る
草案はエラー値を、キャッシュサーバーと「交換された」Error Report PDUの数と記す。送信と受信を別の値にはしていない。正確な数でも、それだけではどちらに原因があったか決められない。
時間の起点も値の中にはない。4という数字は、装置起動後、管理プロセス再起動後、カード交換後、あるいは収集開始後の4回かもしれない。YANG型はゼロから数えるが、追記専用の事故記録を生成するわけではない。
基礎標準もこの境界を示す。RFC 7950ではconfig falseが状態データを表す。RFC 8342は読み取り専用の状態や収集統計をシステム状態とし、内部部品や外部システムとの相互作用で変わる一時的なものと定義する。運用状態は「今、装置が何を使うか」を知るために有用だが、昨日を自動保存しない。
各スナップショットには、モジュール版、収集時刻、収集の成否、リセット起点、限定されたキャッシュとセッションの識別、プロトコル版、Session ID、シリアル、最後のEnd of Data、Refresh/Retry/Expire状態が必要になる。これがなければ二つの値は比較可能とは限らない。
動くコードにも版がある
改訂09には実装状況の章がある。Juniper Networks(HPE)とNew H3C Technologiesが記録されている。しかし両項目はDraft-03、最終更新2026年3月30日で、具体的な実装経験は示していない。
これは以前のモデルに対する実装作業の申告としては証拠になる。改訂09の葉が利用可能、相互運用可能、既定で有効、または本番導入済みである証拠にはならない。「実装あり」とだけ報じて版を落とせば、最も重要な情報を消すことになる。
制度上の版も同様である。Datatrackerは文書をSIDROPSワーキンググループのActive Internet-Draft、Standards Track予定と表示する。IESG状態はI-D Existsで、document shepherdはなく、consensus boilerplateはunknownである。WG文書であることには意味があるが、RFCでも承認済み標準でもない。
情報源
- IETF Datatrackerの文書記録
- RPKI-to-Router YANG改訂09
- RPKI-to-Router YANG改訂08
- IETF author-toolsの08対09差分
- RPKI-to-Router Version 2改訂27
- RFC 8210:RPKI-to-Router Version 1
- RFC 8342:Network Management Datastore Architecture
- RFC 7950:YANG 1.1
- Heng Lu:Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
- Heng Lu:Running Code Primary
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加

