要約

  • RFC 3159のPIB-INDEXは、InstanceId一つだけでPRCインスタンスを識別した。仕様はその値に、インスタンスを指すこと以外の意味を認めなかった。
  • ポリシーの意味は、PIBモジュール、PRC、テキスト規約、対象カテゴリー、アクセス方式、一意性・参照制約、適合性宣言、AUGMENTSとEXTENDSのライフサイクルへ分散していた。
  • 行が正しく識別できても、受理・導入・施行・成果は別である。COPS-PRの記録、PEP状態、実トラフィック、アプリケーション結果が必要であり、後年のHistoric指定もこの証拠境界を消さない。

行番号は正しくても、解釈はまだ始まっていない

あるPDPがPEPへ二つのProvisioning Instanceを送るとする。両方とも同じ分類条件、同じ動作、同じしきい値を持ち、同じキューを参照する。ただしInstanceIdだけが異なる。

プロトコルの記録には二つの行が現れる。それでも二つの異なる意図があったとは限らない。モジュールが重複内容を許しているかもしれない。一意性制約に反して拒否されるかもしれない。一方が別の基底行に属する疎な拡張かもしれない。仮想ストアが違う可能性もある。

RFC 3159は、この不確実性を番号へ押し込まなかった。PIB-INDEXが指定する属性はInstanceId型であり、PRCインスタンスを特定する以外の意味を持たない。行定義のOIDにその値を追加すると、個別PRIのPRIDができる。これは正確な住所であって、政策意図の要約ではない。

番号の桁に顧客、優先度、地域などを暗黙に埋め込めば、正式なスキーマの外に第二の言語が生まれる。採番変更や移行で意味が壊れても、検証器には見えない。意味を持たない識別子は弱い設計ではなく、意味の所在を監査可能にする制約だった。

SMIの道具を借り、ポリシー用の境界を作った

2001年のSPPIは、SNMPのStructure of Management Informationを適応してPIBモジュールを記述した。ASN.1の形式、既存の知識、ツールを再利用できる一方、COPSのprotocol objectとSMIのmanaged objectを混同しない工夫が必要だった。

そこで表と行の定義をProvisioning Class（PRC）、行の実体をProvisioning Instance（PRI）、列をattributeと呼んだ。SMIのscalar objectに相当するものは採用せず、PIB操作は表形式のPRCを対象にした。

MODULE-IDENTITYはモジュールの意味を、OBJECT-TYPEはPRCと属性の構文・意味を伝えた。テキスト規約は、同じ基礎型に固有の意味を与えた。オブジェクトグループとモジュール適合性は、実装が最低限備える範囲を示した。

この形式性は重要だが、実行証明ではない。ASN.1として解釈でき、必須属性がそろい、型制約を満たすPRIであっても、PEPが受け入れたか、装置が設定したか、パケット処理が変わったかは別の問いである。

PIB-INDEXは住所、INDEXは変換用だった

基底行にはPIB-INDEXが必要だった。例外は、AUGMENTSまたはEXTENDSによって既存行の識別を継承する場合である。PIB-INDEXは一つのdescriptorだけを含み、それがInstanceIdを指した。

SPPIには通常のINDEXも現れ得たが、目的はPIBをMIBへ機械的に変換することだった。同じ「インデックス」という語でも、片方はポリシーインスタンスの識別、もう片方は変換後の管理表現に関する規則である。

監査でPRIDだけを保存すると、この違いも、PRIDを解釈するためのモジュール改訂も失われる。必要なのは、モジュール名と版、PRC行定義、適用するテキスト規約、対象カテゴリー、仮想ストアを同時に保つことだ。

スキーマが分かれば、行が何を意味し得るかは説明できる。だが、実際に導入されたかどうかは依然として説明できない。

意味は複数の宣言を結んで初めて現れた

PRCは属性と説明を定義し、テキスト規約が値の意味を具体化した。SUBJECT-CATEGORIESはモジュールをCOPS Client Typeへ結び付け、あるいは全カテゴリーに適用すると宣言した。同じモジュールが複数の仮想情報ストアへ入ることもあった。

PIB-ACCESSは情報の向きを定めた。installならPDPがPEPへ導入できる。notifyならPEPが全インスタンスと属性値をPDPへ通知する。install-notifyは両方を持ち、report-onlyは通常の導入・通知対象ではないが、PEPの同期・非同期報告に含められた。

数値のPRIDから、これらの違いは読めない。導入命令の行と観測報告の行は同じような識別子を持つ。誰が作り、誰が受け取り、どの操作が許されるかはモジュール定義に戻らなければ分からない。

適合性宣言も同様である。実装があるPRCを理解する最低能力を示せても、特定のPRIが今その装置で有効だとは証明しない。

一意性は識別子とは別の契約だった

UNIQUENESSは、複数インスタンス間で同一になってはならない属性の組を示した。ここにPIB-INDEX属性を含めることはできなかった。

この排除が設計上の要点である。プロトコルが一行を参照するためのIDと、ポリシー内容を区別する属性の組は別物だった。空のUNIQUENESSなら、二つのPRIはインスタンス番号以外の全属性が同じでもよい。

したがって、IDが違うという観測からポリシーが違うとは言えない。逆に内容が同じという理由だけで行を統合すれば、参照関係やライフサイクルを壊すかもしれない。

仕様は有用な場合にUNIQUENESSを入れるよう勧めたが、全PRCには強制しなかった。宣言のない自然キーを運用側が勝手に発明してはならない。不在の制約は、不在のまま記録すべきである。

参照番号には宛先の型が必要だった

ReferenceId型の属性にはPIB-REFERENCESが必須で、参照先インスタンスが属するPRCを指定した。TagReferenceIdにはPIB-TAGが必要で、別PRCのどの属性を用いてタグ集合を構成するかを示した。

一方は宣言されたPRCの一つの行を指し、他方は共通タグを持つ行の集合を選ぶ。同じ整数値でも、関係の型と範囲がなければ意味は決まらない。

キューPRCのインスタンス12と、しきい値PRCのインスタンス12は、自動的には同じ対象ではない。タグ7もモジュール横断の普遍的グループではない。ログが番号だけを残せば、リンクの形は残っても宛先は消える。

参照証拠には、参照元属性、そのテキスト規約、指定された対象PRC、対象側の識別規則、モジュール改訂が必要である。

三種類の行は、存在の仕方が違った

SPPIの行定義は、自分のPIB-INDEXを持つ基底行、AUGMENTSによる一対一の追加行、EXTENDSによる疎な追加行のいずれかだった。

AUGMENTSは基底行の識別と存在を共有した。基底インスタンスを導入すれば、すべての追加PRCの対応インスタンスも導入される。基底を削除すれば、追加も削除された。

EXTENDSはゼロまたは一の関係である。疎な追加インスタンスは対応する基底なしに存在できないが、基底があっても必ず存在するわけではない。明示的な導入が必要で、先に明示削除もできる。基底削除時には暗黙に消えた。基底と同時に入れる場合は、同じCOPSメッセージへ含める必要があった。

同じインスタンス番号から、これら三つの時間的規則は推測できない。バックアップが行だけを復元し、関係定義と履歴を失えば、参照可能だが存在条件を満たさない孤児を作る。

IDは行を結ぶ。ライフサイクルは、その結び付きが時間の中で正しいかを決める。静止画だけでは足りない。

構文が正しくても導入は失敗した

INSTALL-ERRORSは、PRCの導入または削除を拒否する固有理由を列挙できた。しかしRFC 3159は、この句がなくても導入・削除は失敗し得ると明記した。違うのはPRC固有のエラーを返せないことだけだった。

これにより、検証済みPRIから成功へ飛ぶことはできない。スキーマ適合はPEP受理ではない。受理はトランザクション完了ではない。完了は実装状態の確認ではない。設定が存在してもトラフィックに一致するとは限らず、一致してもアプリケーション目的が達成されたとは限らない。

COPS-PRは決定、エラー、commit/abort、キャッシュ状態、再接続を含む伝送・取引の仕組みを提供した。SPPIはその中で運ぶ情報を記述した。記述言語とトランザクション記録は接続されるが、同一ではない。

運用画面が緑の「成功」を一つだけ出すなら、何が成功したのかを明示しなければならない。最初の構文成功で後段の不明状態を塗りつぶしてはいけない。

能力、設定、結果を「適合」にまとめない

オブジェクトグループは関連属性を集め、MODULE-COMPLIANCEは必須グループや最小アクセスを示した。適合を主張する実装は、指定された属性とPRCを実装する必要があった。

しかし能力があること、特定設定が存在すること、設定が実際に作用したことは三つの状態である。あるPRCを実装してもインスタンスがゼロの場合がある。行を保存しても機能が有効でない場合がある。有効でも一致するパケットが来ない場合がある。

RFC 3159のセキュリティ記述も範囲が狭い。プロビジョニング情報を定義する言語そのものはインターネットへセキュリティ影響を与えない、という主張だった。COPSセッション、PDPの権限、ポリシー内容、PEP実装まで安全だと認定したわけではない。

証拠は、適用する層より広い権威を持ってはならない。

Historicになった経路からも設計の教訓は残る

後年、RFC 6632はCOPS-PRが広く導入されなかったと記録した。管理データのバイナリ符号化は、一般的なテキスト系スクリプトで単純な設定作業を行う際に扱いにくいと運用者から指摘された。Proposed StandardになったPIBモジュールはなく、COPS-PRの利用は推奨されないとされた。RFC 3159の現在の状態はHistoricである。

この経緯を隠して、SPPIを現代の主流方式として描くことはできない。しかし「広く導入されなかった」は「一度も実装されなかった」ではない。Historicも、当時の設計を無価値にする削除印ではない。

むしろ退いた経路だからこそ、境界がはっきり見える。住所、意味、アクセス、存在関係、取引、実行結果は別々だった。現代のAPIで資源URIと200応答を持っていても、この区別を失えば同じ誤りを繰り返す。

普及率と設計上の洞察は別の評価軸である。

永続させるべきものはPRIDではなく証拠の連鎖だ

監査可能な記録は、PIBモジュールと改訂、対象カテゴリー、仮想ストアから始まる。PRC、テキスト規約、基底・追加・疎な追加の関係、InstanceIdと完全なPRID、一意性、参照先、タグ、アクセス方式、適合性プロファイルを保つ。

次にCOPS-PRの要求と決定、トランザクションID、導入・削除結果、一般およびPRC固有のエラー、キャッシュ・再接続の文脈、PEPの前後状態を保存する。さらに実際のパケット処理を観測し、最後にアプリケーションが目的達成を評価する。

モジュールはフィールドの意味を証明する。PRIDは対象行を示す。プロトコル記録は交換内容を示す。装置記録は導入状態を示す。トラフィックは施行を示し、アプリケーション記録は成果を示す。

RFC 3159のインデックスは、この連鎖全体を装わなかったから有用だった。番号は行を指す。それ以上の主張は、別の証拠を必要とする。

出典