要約

  • RFC 1303 は MODULE-CONFORMANCE により、SNMP エージェントが主張する MIB グループと変種を sysObjectID に結び付け、管理局が適合する対話を選べるようにした。
  • オブジェクトのアクセスは読み書きがプロトコル上意味を持つかを示すだけで、行政的な認可方針とは独立だと明記している。
  • モジュールの主張、書込み構文、要求への応答は、主体の権限、現在の完全な能力、変更の永続化、運用上の効果を単独では証明しない。

分析

同じ名前でも同じ会話とは限らない

RFC 1303 は Informational RFC として、すべての SNMP エージェントが同じ MIB を同じ深さで実装するという前提を置かなかった。MIB のモジュールは適合グループに分かれ、エージェントは一部のグループだけを実装できる。さらに、特定のオブジェクトには実装者が選べる余地がある。相手の差を知らずに操作を最適化すれば、管理局は能力のない相手に正しい言葉のように見える誤った要求を送る。

そこで MODULE-CONFORMANCE は、どのモジュール、グループ、変種を支持するかを記述し、その記述をエージェントの sysObjectID に結び付ける。管理局は識別子を取得し、説明のデータベースを参照して振る舞いを選べる。これは互換性のための予備知識である。識別子が、誰が設備変更を決められるかを示すわけではない。

しかも sysObjectID は完全な現在地図ではない。RFC は、SMUX のピアのように、エージェントが動的に支持対象を学ぶ場合を挙げる。そのときは追加の MIB オブジェクトで記述を補う必要がある。安定したラベルを、稼働中の能力全体や不在の条件の証明にしてはならない。

読めること、書けること、許されること

受管理オブジェクトには名前、構文、アクセス水準、実装状態がある。名前とインスタンスは対象を示し、構文は値の抽象的な形を限定し、実装状態は必須・任意・廃止・非推奨を分ける。アクセス水準は、インスタンスを読むか書くことがプロトコルとして意味を持つかを扱う。

RFC 1303 の最も重要な一文は、このアクセス水準が管理上の認可方針と独立だという点である。read-write は組織の許可証ではない。要求の形がプロトコルに適合していることと、責任者が今その変更を許すことは別の記録である。反対に、組織が認めた方針であっても、エージェントが対象を実装しない、許容する書込み値が異なる、または作成条件を満たせないため、SNMP では表現できないことがある。

SYNTAX と WRITE-SYNTAX の分離もこの境界を保つ。両方ある場合、前者は読取り、後者は書込みに関わる。例には利用不能なオブジェクト、読取り専用の状態、読める値と書ける値の集合が異なる項目がある。観測できる値は置換を許さず、形式に合う値は認可を意味せず、応答は意図した運用効果を意味しない。

行作成の条件は統治の結論ではない

CREATION-REQUIRES は、概念上の行を SNMP Set で作る前に明示的に代入すべき列を挙げる。条項がなければ、そのエージェントは SNMP による作成を支持しない。これは要求がインターフェースにとって十分かを述べる規則である。

しかし、必要欄がそろった候補が、承認済みの変更になるわけではない。変更時間、責任のある主体、影響の確認、下流への反映、ロールバック、サービスの観測は別の層に残る。RFC 1303 のマクロ展開は概念上実装時に起こり、実行時ではない。安全性も本文の対象外である。したがって能力記述を、実行中の権限証明に読み替える理由はない。

出典

RFC 1303 は 1992 年の SNMP エージェント記述の約束を示すだけで、実在の製品、認可、成功した Set、永続設定、ネットワークの結果を示さない。