要約

  • RFC 9713 は IANA の Bundle Administrative Record Types レジストリに BP 版の欄を設け、BPv7 の管理要素は版欄に 7 を含む値を使うよう求めた。
  • 64384–64511 を BPv7 の実験用、64512–65535 を BPv7 の私的利用に予約したが、これは中央割当との衝突を防ぐ仕組みであり、組織を越えた意味の合意ではない。
  • 運用証跡では、レジストリ割当、版の範囲、参照仕様、実装能力、ローカル規約、受信、ポリシー上の承認、動作、観測結果を分離しなければならない。

整数だけでは検索キーにならなくなった

RFC 7116 が BPv6 のために管理レコード型レジストリを作った時点では、型フィールドは四ビットだった。その後 RFC 9171 は、BPv7 の管理レコードを二項の CBOR 配列として定義した。先頭が符号なしの型コード、次が型固有の内容である。ところが、二つの世代が参照する表には、どの値が BPv6、BPv7、または双方に属するかを示す明確な軸がなかった。

その欠落は、番号を実際以上に強い証拠に見せる。値 2 は BPv6 の Custody signal だが、BPv7 は同じ custody の仕組みを引き継いでいない。一方、値 1 の Bundle status report は両版に適用される。「2 は Custody signal」という回答は過去の登録事実としては正しくても、BPv7 の要素が処理してよいという根拠にはならない。

RFC 9713 は表の左端に Bundle Protocol Version 欄を追加した。BPv7 の管理要素は、登録済みの名称だけを見るのではなく、その欄に 7 がある値を選ぶ。共有される調整キーは「番号」から「番号とプロトコル版」の組に変わった。

内容の権威は参照仕様にある

番号と版が一致しても、まだ完全な命令にはならない。RFC 9713 は、同じコード点を BPv6 と BPv7 が使う場合の相互運用も、意味が同一かどうかも定義しない。各管理レコード型の仕様が、それぞれの版との関係を説明する責任を持つ。

現行の IANA 表は、この役割分担をよく示す。値 1 は RFC 5050 と RFC 9171 を参照し、現在は BPv7 向けの CCSDS 信号 13、14、さらに ACME Node ID Validation の値 255 も掲載されている。レジストリが示すのは割当と参照先であり、255 の CBOR 構造、トークン、検査、処理手順を定義するのは RFC 9891 である。整数は意味を保管する仕様への索引であって、意味そのものを圧縮したものではない。

運用時には、レジストリの取得時点と内容、版のセル、参照仕様の正確な版を一組で保存する必要がある。これがなければ、実装は「登録済み」と主張しながら、古い構造、別版の意味、あるいは非公開の独自解釈を使えてしまう。

私的利用が保証するのは中央割当の不在

RFC 9713 は 64384–64511 を実験用、64512–65535 を私的利用として BPv7 に予約した。IANA が同じ領域から公開型を割り当ててローカル値と衝突するのを防ぐ、実務的な措置である。

ただし RFC 8126 が示す境界は明確だ。Private Use の個別値を IANA は記録せず、意味は各サイトが決める。別々のサイトが同じ値を互換性のない方法で利用しても規則違反ではない。Experimental Use も一般的な相互運用に適した制度ではない。予約によって得られるのは空間であり、共通辞書ではない。

たとえば二社がどちらも 65000 を選び、異なる内容を符号化できる。買収、ローミング接続、災害時の相互接続、ベンダー交換が、隔離されていた規約を同じ境界へ運ぶ。最初の Bundle がどちらの辞書を採用すべきかを交渉してくれるわけではない。所有者、相手、適用範囲、改訂、期限、フォールバック、衝突時の動作を外部合意で定める必要がある。

配送成功とレコード処理成功は別である

RFC 9713 は失敗時の境界も明確にした。管理要素が不正な application data unit、または処理できない型コードを受け取った場合、そのレコードを無視しなければならない。しかし、外側の Bundle が管理要素へ配送された事実は変わらず、状態報告など Bundle Protocol Agent の他の処理も書き換えられない。

この分離により、アプリケーション処理の失敗が輸送成功を消すことも、輸送成功が理解の証拠へ昇格することも防げる。監査可能な台帳は少なくとも、Bundle 配送、管理レコードの識別、型コード抽出、版の適用確認、仕様とローカル規約の解決、内容の解析、設定済みの送信元・完全性検査、ポリシー承認、動作の試行、状態変化、効果の観測を別イベントとして扱うべきだ。

「受信済み」が真でも、その後がすべて偽または不明という状態は正常に起こり得る。これは RFC 9171 の配送や custody の論点とは異なる、意味解決と実行権限の問題である。

レジストリは調整面であり、遠隔操作装置ではない

RFC 9713 は Specification Required という登録手続きを変更せず、新しいセキュリティ機構も作っていない。RFC 9171 のセキュリティ上の考慮事項は引き続き適用される。改善されたのは共有表と、その表を参照する規則である。送信者が信頼できること、パーサーが安全であること、ローカル管理者が動作を承認したこと、期待した結果が得られたことは証明しない。

公開割当の衝突や版の取り違えを可視化する点で、レジストリの権威は不可欠である。ただし、その権威は表に実際に記録された主張の範囲で終わる。

Heng Lu の Running-Code Primacy、Minimum Initial Specification、Reality Layers は、この境界を読むための明示された編集上の視座を提供する。共通記録は狭く、ローカルで検証できる形に保ち、将来の採用は動作するシステムへ委ね、象徴的な記録に実行結果を借用させないという考え方である。これらは分析であり、IETF の意図を代弁するものではない。

情報源