要約

  • RFC 1442 は各情報モジュールに一つの MODULE-IDENTITY を置き、OID、管理組織、連絡先、最終編集時刻、改訂説明を一つの系譜にまとめた。
  • 同文書は、このマクロの展開が概念上「実装時」に行われ、「実行時」には行われないと明記した。したがって、モジュールの最新版から個々の装置の実装範囲やアクセス可能性を推定することはできない。
  • 後継の RFC 1902 と RFC 2578 は、互換的な変更ではモジュール名を保ち、非互換な意味には新しい記述子と OID を割り当て、廃止済み OID を再利用しないという規律を引き継いだ。

最新の辞書で古い話者を読む

管理端末は新しい MIB パッケージを使い、十年前の装置から返った値を美しく表示できる。列挙値は人間向けの語に直され、単位も付く。画面だけを見れば、装置自身が新しいモジュールを名乗ったように感じられる。

実際に新しいのは、値を読んだ側の辞書かもしれない。装置が返したのは OID と符号化された値であり、その解釈にどの定義ファイルを使うかは収集側の判断である。新しい辞書が旧い応答を読めるのは互換性の成果だが、辞書の発行日を話者の製造日へ移す根拠にはならない。

RFC 1442 は、この混同を避けるためだけに書かれた文書ではない。それでも、モジュールの宣言を実装時のものと位置づけた一文は、今日の資産管理に鋭い境界線を引く。定義の由来が確かであることと、装置の中身が確かであることは別々の証拠を要する。

名前のない器を管理対象にした

SMIv2 は記述を三つに分けた。管理対象を定義する OBJECT-TYPE、通知を定義する NOTIFICATION-TYPE、そしてそれらを収める情報モジュール自体を定義する MODULE-IDENTITY である。最後のものにより、MIB は単なる構文の束ではなく、責任者と履歴を持つ成果物になった。

モジュールには imports や exports の後に、ただ一つの MODULE-IDENTITY を置く。そこにはモジュールの OID、責任組織、問い合わせ先、最後に編集された時刻、各改訂の時刻と説明が含まれる。どの組織が名前空間を維持し、どのような変更を重ねたかを、ファイルの内部からたどれるようになった。

これは地味だが強い基盤である。名前を固定すれば、他のモジュールは安定して定義を import できる。履歴があれば、同じ名前の下で許された修正を比較できる。保守責任も、散逸した電子メールや担当者の記憶だけに依存しなくなる。

ただし、MODULE-IDENTITY は問い合わせ可能な管理対象そのものではない。RFC 1442 はマクロの展開を実装段階に置いた。時刻や説明がデータの形をしていても、稼働中のエージェントがそのまま返す台帳ではない。仕様書の自己紹介と装置の自己証明を、標準は同一視しなかった。

最終更新時刻の主語

LAST-UPDATED という語だけを切り出すと、さまざまな期待を背負わせられる。最後のファームウェア更新、最後の導入、最後の起動、最後の設定変更。しかし、この値の主語は一貫して情報モジュールである。示すのはモジュールが最後に編集された時刻だ。

REVISION も導入履歴ではない。RFC 1442 では、時刻と変更内容を新しい順に記すための句だった。当初は省略可能だったため、履歴がないことさえ「改訂なし」を意味しない。人が維持する仕様の記録であって、装置から自動収集されたログではないからだ。

証拠管理では、時刻に必ず主語を付ける必要がある。MIB ファイルを取得した時刻、収集器が読み込んだ時刻、ベンダーがファームウェアを公開した時刻、装置が応答した時刻、外部状態を確認した時刻は、互いに近くても交換できない。最も新しい日付を選ぶのではなく、どの出来事を記録した時計かを残すべきである。

名前を変えないことにも条件があった

改訂のたびにモジュール名を変えれば、imports は不必要に壊れる。記述の明確化や参考文献の訂正まで別モジュールにすれば、互換な改善を追う負担が増え、同じ系譜であることも見えにくくなる。そのため RFC 1442 は、一定の変更を同じ名前の下で許した。

許されたのは、旧い実装との互換性を守る方向の変更である。説明や参照の改善、一部属性の安全な変更、規則に沿った表の拡張などが想定された。安定した名前は、変化を否定する標識ではなく、互換性を約束した改訂列の標識だった。

一方、定義の意味を許容範囲外で変える場合には、新しい記述子と新しい OID が必要になる。旧い座標をそのまま使って契約だけを取り替えてはならない。記述子は imports の世界で、OID は通信の世界で、意味のすり替えを防ぐ。

ここには「同じ名前なら同じ実装」という主張はない。あるのは「同じ名前の系譜では、変更の種類を制御する」という編集上の約束である。

廃止された文書から現行標準へ

RFC 1442 は 1996 年に RFC 1902 に置き換えられた。後継文書も、モジュール、オブジェクト、通知という構成を保ち、一つのモジュール identity と、実装時／実行時の区別を維持した。文書の status が変わっても、境界は消えなかった。

1999 年には RFC 2578 が RFC 1902 を置き換え、SMIv2 の Internet Standard となった。そこでは、同じモジュール名のまま複数の版が存在し得ること、改訂が通信上の相互運用問題を起こしてはならないこと、変更時には revision 情報を更新することが、より明瞭に示された。

また、obsolete になった定義を削除せず、その OID を再割り当てしないという規則も重要である。使わなくなった意味を記録から消すと、その番号が後に別の意味で現れたとき、古い実装は区別できない。廃止の印は削除よりも多くの情報を残す。

current、deprecated、obsolete は、定義を新規利用すべきかどうかを示す仕様上の status である。ある装置が実装しているか、現在の資格情報で見えるか、正しく動くかを示す status ではない。現行定義が未実装の場合も、廃止定義が稼働し続ける場合もある。

証明できる範囲を狭く保つ

モジュール identity は、証拠として弱いのではない。用途を守れば非常に強い。取得元とハッシュを添えれば、収集器がどの定義を使って値を解釈したかを固定できる。組織、連絡先、OID、改訂説明を通じて、仕様の責任と系譜も確認できる。

しかし、それだけで装置について言えることは少ない。モジュールを実装しているか、すべての object が instrument されているか、利用者の view に入っているか、記述どおりの副作用を持つか、再起動後も変更が残るかは、それぞれ別の問いである。

稼働面では、実際の endpoint、transport、security identity、context、要求、応答を保存する。noSuchObject、instance 不在、access denial を区別する。適合グループに照らして複数の object を調べる。書き込みなら外部状態を別経路で確認し、必要なら lifecycle event の後に再観測する。

結論も分解して残せる。「ハッシュ H のモジュールで応答 R を解釈した」は強く言える。「装置 D は revision Y を実行している」は追加証拠がなければ言わない。この慎重さは情報を減らすのではなく、反証可能な形に整える。

固定された名札が守ったもの

RFC 1442 が残したのは、変化を受け入れながら身元を失わない方法だった。モジュール名は imports を支え、revision は編集の記憶を支え、新しい OID は非互換な意味の境界を支えた。後継標準が同じ考えを採ったのは、それが運用可能な制度だったからである。

問題は名札ではなく、名札に過剰な証言を求めることである。仕様の台帳は仕様の現実を記述する。稼働コードの現実は、稼働面から採らなければならない。整った記録が現場を自動的に作るわけではない。

モジュール名が変わらなかったことは、成功だった。その名前から装置の版まで読み取れると思った瞬間にだけ、成功は誤解へ変わる。

出典