要約

  • USER_ERROR_SPEC は Class 194 として、未知のオブジェクトをそのまま転送する RSVP の範囲に置かれた。古いノードを通過した事実は、そこで意味が解釈されたことを示さない。
  • 受信、名前空間の解決、ローカルな判断、対処の実行、復旧の観測は別々の段階であり、各段階に固有の受領証が要る。

新しいエラーオブジェクトが、更新されていない三台の RSVP ノードを通過する。各ノードは Class 194 を知らない。それでもオブジェクトを削除せず、1 ビットも書き換えず、次のホップへ送る。最後の受信者だけが企業固有の定義を持ち、値を解釈できる。

この経路は相互運用の成功例である。同時に、意味の共有例ではない。三台の古いノードが証明したのは、未知の拡張を壊さなかったことだけだ。エラーを認識したこと、ログに残したこと、対処に同意したことは証明していない。

RFC 5284 の強さは、この限定された成功を許容した点にある。すべての実装を一斉更新せずに、組織固有の診断を既存経路へ載せられる。プロトコルの連続性と意味の権限を分けることで、拡張の運搬を広くしつつ、その結果をローカルに統治できる。

Class Number が互換性の動作を決める

USER_ERROR_SPEC には Class 194、C-Type 1 が割り当てられた。RSVP の Class 192–247 は、実装が理解できない場合にもオブジェクトを未変更のまま転送する範囲である。Class Number は単なる識別子ではなく、未知の実装が取るべき動作を選んでいる。

この性質は、段階的な導入に向いている。最初はエンドポイントだけが新しい拡張を生成し、解釈する。中継ノードは古いままでも輸送を妨げない。後から一部の受信者がロギングを実装し、さらに限定された自動化を追加できる。

ただし、到着したオブジェクトから経路全体の理解度を推測してはならない。パケット取得で完全なバイト列が見えても、中継点の辞書や方針は見えない。転送の受領証を、解釈の受領証として数えれば、未更新ノードの存在を隠すことになる。

繰り返しオブジェクトの規則も同じ方向を向く。実装は重複する USER_ERROR_SPEC を無視し、転送するメッセージでは変更せずに保持することが望ましい。複数回現れたからといって、重大度や信頼度が増すわけではない。

標準の ERROR_SPEC は残る

RFC 5284 は既存のエラー構造を置き換えない。PathErr と ResvErr では基本 RSVP が、Notify では RSVP-TE が、標準 ERROR_SPEC を必須としている。新しいオブジェクトはそれに追加される。

既存のエラーコードが条件を表せるなら、そのコードに私的な詳細を添えられる。該当するコードがなければ Error Code 33 の User Error Spec を使い、通常は sub-code 0 で詳細が追加オブジェクトにあることを示す。

Code 33 があるのに USER_ERROR_SPEC がなければ、メッセージは不正である。追加オブジェクトが PathErr、ResvErr、Notify 以外に現れた場合も不正となる。ResvConf にも ERROR_SPEC は存在するが、そこでのコードと値は同じ意味を持たないため対象外だ。

つまり受信者は、標準部分の妥当性と拡張部分の妥当性を別に確認できる。外側だけを保存すれば私的な意味を失い、内側だけを保存すれば RSVP の文脈を失う。互換性とは、検証点を減らすことではない。

値は Enterprise Number の内側でだけ意味を持つ

オブジェクトは 32 ビットの Private Enterprise Number、8 ビットの Sub Org、16 ビットの User Error Value を順に持つ。Sub Org は一つの組織内で並行開発チームなどの値空間を分離でき、不要ならゼロが推奨される。

したがって、値 12 だけを見てもエラーは特定できない。別の企業は 12 を別用途に使える。同じ企業の二つのサブ組織でも定義が異なり得る。正しいキーは三つのフィールドの組み合わせである。

IANA の Private Enterprise Numbers は上位空間を区別する。登録は、個々のメッセージの送信元認証でも、下位値の国際標準化でもない。受信者は RSVP の保護を検証し、適切な私的辞書を選び、対処権限を自分の方針で判断する必要がある。

古い事象を再現するには辞書の版も要る。企業が値の意味を変更した場合、現行辞書で過去を読み直せば誤った説明になる。元のバイト列、三つ組、辞書版、解釈時刻、デコーダー識別子を保存することで、初めて意味の履歴が残る。

共通の TLV は共通の辞書ではない

ユーザー定義サブオブジェクトは Type-Length-Value の形を取る。Type と Length は各 8 ビットで、全長はそれらを含み、4 バイト以上かつ 4 の倍数でなければならない。未知の受信者でも境界を認識して安全に飛ばせる。

しかし Type の割当てと Value の形式・意味は、同じ Enterprise Number と Sub Org が所有する。共通なのは構文であり、内容ではない。汎用パーサーが正しく次の位置へ進めることと、運用上の意味を理解することは違う。

この構造は責任分界を明確にする。標準はコンテナを定め、IANA は企業空間を区別し、組織は私的定義を管理し、受信者は信頼と行動を決める。どの層も、次の層の判断を自動的に代行しない。

説明文は表示できない場合がある

Error Description は UTF-8/Net-Unicode で、4 バイト境界までヌルでパディングされる。長さはパディングを含まず、ゼロも正当だ。利用しやすさのため、可能なら一行の印字可能 US-ASCII に抑えることが推奨される。

RFC 5284 は、文字集合の都合で全実装が説明文を表示できるとは限らないと指摘する。そのため、説明は補助情報に限定し、運用に不可欠な情報は数値の User Error Value に置く。UTF-8 を扱えない実装は RFC 5137 の方法でエスケープする。

この規則は表示と自動化を分離する。人は説明を読めるが、機械は版管理された三つ組の対応表を使う。ログに制御文字や過大入力が入る危険もあるため、証拠用の原文と安全に描画するビューは別にするべきだ。

説明文をキーワード検索して対処を選ぶ設計は、言語や句読点の変更を制御変更にしてしまう。補助欄を暗黙の API にしないことが、互換性よりも長く効く安全策になる。

「受け取った」から「直った」までは一本道ではない

規格は受信実装に、少なくとも企業番号、サブ組織、値、説明を記録することを推奨する。内容を解釈できる実装は、そのエラーに基づいて追加の行動を取ることが望ましい。ロギングと行動は別の動詞である。

実運用では、メッセージ妥当性、完全な保存、名前空間解決、辞書による解釈、方針による許可、アクチュエーターの実行、状態変化、サービス結果を分ける必要がある。正しい解釈の後に許可が拒否されてもよい。実行成功の後に状態が変わらないこともある。

一つの 対応済み フラグは、どこで失敗したかを消してしまう。各遷移に入力、担当、方針版、時刻、結果を持つ受領証を置けば、拡張オブジェクトは証拠として役立ち、遠隔命令へ変質しない。