要約

  • RFC 2366 では、関連 VC 行が残っている、または使用中であっても、MARS クライアント、MARS サーバー、MCS の親行を削除できた。子行の整理は別の処理だった。
  • read-create はモデルが許容する上限であり、準拠エージェントが必ず書き込みを受け入れるという意味ではない。行、カウンター、通知、成功した SET のいずれも、回線解放や配送を単独では証明しない。

運用画面から一行が消える。見た目は明快だ。対象はもう存在しないように見える。しかし RFC 2366 は、管理情報の消失と通信資源の消失を意図的に一致させなかった。

marsClientRowStatus は、クライアント行の作成、変更、削除に使われる。行を active にするには必要な列と対応する統計行が要る。それでも削除は、関連表の行、特にクライアント VC 表が存在する場合や使用中の場合にも許された。

削除後、エージェントまたは管理局は、可能なら SET で古い関連行を消すよう勧められた。「可能なら」という条件が重要である。親行の削除と子行の整合は一つの原子的処理ではない。残った VC 行は、生きた回線、すでに解放された回線の残骸、または整理待ちの記録のどれでもあり得る。

同じ規則は MARS 本体と MCS にも置かれた。MARS 行は関連する marsVcTable が残っていても削除でき、MCS 行も自分の VC 表が存在・使用中のまま削除できた。三つの役割で反復されたことから、これは単なる記述ミスではなく、管理モデルと ATM 実体の異なる寿命を受け入れた設計だと分かる。

基礎となる RFC 2022 では、MARS が ATM クラスター内のマルチキャスト参加情報を配布した。送信者は受信者へのポイント・ツー・マルチポイント VC を作るか、MCS に転送を任せる。RFC 2366 はその制御機構そのものではない。そこから選んだ状態を仮想情報ストアへ投影した。

クライアント表には ATM アドレス、既定 MARS、登録状態、識別子、タイマー、グループ範囲、予備 MARS、VC、統計が並ぶ。MARS 側にはサービス状態、優先順位、ホストと MCS の対応、登録メンバー、VC、統計がある。MCS にも登録、予備、VC、統計の系統がある。

これらは同じ事実の別名ではない。登録クライアント行はクライアント設定全体ではなく、アドレス対応は回線ではない。VC 行に VPI/VCI、グループ、相手先、PVC/SVC、制御種別、アイドル時間、再検証、カプセル化、交渉済み MTU があっても、スイッチが回線を維持していることや、各受信者へパケットが届いたことまでは示さない。

行の由来で権限も変わる。設定されたホスト／サーバー対応は管理できるが、動的に学習された行は同じ RowStatus で変更・削除できない。VC 行の一部属性は active 中でも変更可能だった一方、SVC の行はその経路で変更も削除もできなかった。管理局が観測できる範囲と支配できる範囲は一致しない。

アクセス宣言にも二層があった。多数のオブジェクトは MAX-ACCESS read-create とされた。だが準拠宣言では、その最小アクセスを read-only とし、書き込みは必須ではないと繰り返した。

つまり、モデルは書き込み可能な最大形を定義しても、実装は観測専用で準拠できる。RFC 1904 は、書き込み可能なオブジェクトなら SET に応じて実体へ合理的な影響を与えられなければならないとする。MIB の文法から自動的に編集機能を推定するのは、上限と実装能力の混同である。

SET が成功しても、権限や結果は別に確認する必要がある。認証された主体、VACM のビュー、許可された操作、エージェントの応答、値の永続性、その後の ATM 信号処理、スイッチ状態、トラフィック、受信結果を順に記録しなければならない。SNMP の成功は管理操作の受領であって、回線やアプリケーションからの受領証ではない。

カウンターも限定された証拠だった。要求、JOIN、LEAVE、分割応答、NAK、移行、最後の MARS_MULTI を待つタイムアウトなどを役割ごとに数える。取得時刻、基準値、リセット、インスタンスがなければ差分すら曖昧である。それらがあっても制御メッセージの観測量であり、データ配送量ではない。

既定 MTU と VC の交渉済み MTU は別だった。登録状態はエージェントの状態であり、相手側すべての独立確認ではない。HSN、CSN、SSN は制御メッセージ欠落や参加変更の手掛かりだが、データ面を証明しない。marsFaultTrap は故障条件の検出を通知するが、送信、管理局での受信、診断、修復、回復は続く別工程である。

セキュリティ節は、書き込みを単なる利便性として扱わなかった。保護されない SET は運用に悪影響を与え得る。ネットワーク自体が暗号化されても、SNMPv1 だけでは誰が変更・作成・削除してよいかを決められない。RFC は SNMPv3 のユーザー型セキュリティとビュー型アクセス制御を勧め、読み取りにも制御が必要な場合があると記した。

読み取りだけでも、ATM アドレス、参加関係、対応表、予備優先順位、VC の相手、MTU、タイマー、障害状態が見える。暗号化、本人確認、ビュー権限、利用目的はそれぞれ違う審査である。

公開から二か月後、モジュールの所在自体も修正された。RFC 2366 は MIB を snmpModules 配下に置いたが、その割り当ては事務的な誤りだった。RFC 2417 は内容をほぼ保ったまま mib-2 57 へ付け替え、RFC 2366 を廃止した。意味が同じでも、共有する識別座標が誤っていれば相互運用は難しい。

RFC 2366 の価値は、画面がネットワークそのものだと主張しなかった点にある。親行、関連行、動的状態、信号処理、回線、配送を別々に問える共通語を作った。行が消えた後に残る問いこそ、運用上の真実だった。

出典