要約

  • RFC 9171 は受信、転送、ローカル配送、削除、状態報告を別々の Bundle Protocol 状態として定義する。報告が述べるのは、それを生成したノードが主張する状態である。
  • BPv7 自体はエンドツーエンド配送を保証せず、custody transfer はベースプロトコルの状態ではなくなった。受信だけから保管、アプリ処理、権限、外部結果を導くことはできない。

遅延耐性ネットワークでは、通常のネットワークが前提にする会話の連続性がない。接続は途切れ、待ち時間は大きく、送信時に次の接点が存在するとは限らない。Bundle Protocol Version 7 は、アプリケーションデータと、それを将来利用可能にするためのプロトコル情報を一緒に運ぶ。この環境で「送った」「終わった」だけでは、検証できる経路にならない。

RFC 9171 は動作ごとに異なる言葉を与える。transmission は Bundle Protocol Agent（BPA）がコピーを endpoint のノードへ到達させようとする試みである。forwarding は、他のノードがコピーを受信するよう、一つ以上の convergence-layer adapter を用いて継続的に働きかけることをいう。delivery はさらに局所的で、登録状態に従い、ペイロードと関連メタデータがそのノードの application agent に提示されたことを指す。削除、破棄、保持を妨げる retention constraint もまた別の状態である。

これは文体の違いではなく、証拠の適用範囲である。転送された bundle が次のノードに届いたとは限らない。受信された bundle がローカル配送可能とは限らない。application agent に渡されたペイロードが処理済みとも限らない。そして、いずれかを伝える報告が、対応すべき相手に届いたとも限らない。これを一つの「配送完了」に潰すと、画面は簡単になるが、責任がどこで変わったかを後から追えなくなる。

受信手順は最初の境界をはっきり示す。他のノードから bundle を受信すると、BPA は “Dispatch pending” retention constraint を追加する。受信報告が要求され、状態報告が有効なら、BPA は report-to endpoint に受信状態報告を生成すべきである。ここから言えるのは、そのノードが RFC の定める受信処理を開始した、という限定された事実である。

その後も bundle が残るとは限らない。BPA は付属 CRC を検査する。形式が不正であるか、受信時に計算した CRC が付属値と一致しなければ、BPA は bundle を削除し、受信手順の残りを飛ばさなければならない。処理できない extension block でも、報告が出た後に制御フラグに応じて削除または除去に至り得る。したがって、受信報告の存在は、適合する bundle が保持・転送・アプリケーション配送されたという証明にはならない。

転送の範囲も別である。BPA は転送先ノードと adapter を選び、送信を依頼する。データ送信手順の完了が成功した forwarding かどうかは実装固有であり、成功しない場合にはローカル設定に従って再試行が選ばれることがある。forwarding report が表すのはこの状態である。それは次ノードからの受領書でも、経路が今後も使える保証でも、最終 endpoint 到達の証明でもない。

宛先側では境界がさらに明白になる。ローカル配送は destination endpoint に対応する registration の状態に依存する。fragment は再構成を必要とすることがあり、passive registration や実装固有の配送失敗は配送を延期または放棄できる。配送状態報告が生成されても、RFC はそれが payload を application agent に渡したことだけを表し、その agent がペイロードを処理したことは表さない、と明記する。

この限定は自動化された運用設計にとって重い。application agent は自身の規則により、検証、待ち行列化、拒否、延期、変換、無視を行える。BP の状態だけでは、どれが起きたかは分からない。それは決定責任者を示さず、権限ある人が結果を確認したことを証明せず、不可逆な指示が実行されたことも示さない。これらが必要なら、アプリケーションと決定を担う仕組みが別に記録を残す必要がある。

状態報告は便利でも、世界全体の監査記録ではない。RFC 9171 は、多数の要求が過剰なトラフィックを生み得るため、状態報告の生成をデフォルトで無効にするよう求める。有効化後でさえ、要求された報告を生成するかどうかは BPA の判断に委ねられる。報告に時刻があれば、それはノードのローカル時計が報告した時刻で、実装事項である。つまり報告は、あるノードが述べ、別の bundle として report-to endpoint に運ばれる限定的な主張であって、全世界の時系列でも、予定読者が受け取った証明でもない。

custody との歴史的比較も外せない。実験的 RFC 5050 は custody acceptance と custody signal を定義していた。RFC 9171 の表では対応する要求フラグが version 6 の値として示され、Appendix A は custody transfer が Bundle-in-Bundle Encapsulation へ移ったと述べる。ベース BPv7 には保持、転送、ローカル配送、報告、拡張の有用な仕組みがあるが、受信を保管責任の引受けへ変える仕組みはない。保持責任が必要な運用では、仕組み、条件、失敗時の扱いを明示すべきであり、受信ビットからそれを読み込んではならない。

RFC 9171 が述べる最大の限界は率直だ。Bundle Protocol 自体は destination への配送を保証しない。信頼できる convergence-layer protocol は隣接ノード間の損失を減らせるが、エンドツーエンドの配送保証には BP 拡張および/またはアプリケーション層の仕組みが必要である。これは隠れた欠陥ではない。BPA がある地点で bundle に行ったことを記し、それ以後にアプリケーション、人、組織が何を選んだかを勝手に証明しないという、正直な責任分担である。

経営や統制の立場で問うべきなのは、受信報告を信じるかどうかではなく、記録が知っている範囲だけを述べているかどうかである。受信、転送、ローカル配送、アプリ処理、確認、承認、外部実行を分け、それぞれについて、誰が主張し、どの規則に基づき、どこへ送られ、どの時計を用い、何が失敗となるかを記録する。狭くても真の記録はつなげられる。すべてを表すふりをする一つの緑色表示は、後から監査しても真実にはならない。

Lu Heng が区別する表象、ローカルな決定、実際に動く現実という層は、ここで有用な編集上の規律になる。BP の状態報告は、範囲の定まったプロトコル状態の表象である。それが示す範囲では信頼すべきだが、権限や成功の宣言へ昇格させるべきではない。観測した事実と、別の主体がなお選択し実行しなければならない結果を分けるとき、運用中のシステムは強くなる。

出典