要約

  • RFC 3737は、ワーキンググループが管理していた一覧から、将来のRMON MIBモジュールルートの割当責任をIANAへ移した。ただし既存OIDは動かしていない。
  • 境界は明確だ。IANAはrmon配下のMODULE-IDENTITYルートを割り当て、モジュール内部の通常のオブジェクト識別子は著者や編集者が割り当てる。

遅い訂正もあったレジストリ

リモート監視MIBは、MIB-IIのツリーにあるrmonノード、1.3.6.1.2.1.16の下に蓄積してきた。RMONMIBワーキンググループは、新しいモジュールの割当一覧を独自に管理していた。RFC 3737はそれを失敗とは呼んでいない。おおむねうまく機能していたという。ただし、誤りが工程の終盤で訂正された例があり、いくつかの割当は後に使われなくなった。また、標準化過程にあるMIBモジュールがRFC公開時にルートを得る通常の方法とも異なっていた。

RFCの表を見ると、継承された構造が分かる。初期の番号にはstatistics、history、alarm、captureなどのオブジェクト群があり、後の番号にはMODULE-IDENTITYルート、利用可能値、予約値、廃止された割当が並ぶ。単一種類のオブジェクトが整然と並ぶツリーではない。RFC 3737は、初期の一部の割当が論理的でなく、変更もできないと明記する。解決策は過去の番号の付け替えではなく、今後の決定を誰が記録するかを変えることだった。

IANAが受け取ったのはルートであり、モジュール全体ではない

RFC 3737は既存の割当をSMI Numbersレジストリに取り込み、IANAに管理を求めた。以後、IANAがrmon配下で割り当てるのはMODULE-IDENTITYのルートだけである。モジュール内の通常のOIDは、引き続き著者や編集者が通常のMIB手順に従って割り当てる。当時のRFC 2434に基づき、新しいルートにはStandards Actionが必要で、番号はRFCの公開時にIANAが割り当てる。

この境界は重要だ。ルートは共有名前空間でモジュール同士が衝突しうる接点である。ルートが決まった後は、トップレベルのRMONレジストリにすべてのオブジェクト番号を求めず、モジュールの中で内部構造を組み立てられる。衝突しやすい境界だけを中央で扱い、モジュール内部の設計は各仕様に残す。

後年のIANA SMI Numbersページにもrmonツリーは残っている。一部の参照先はRFC 4502に変わり、利用可能値、廃止されたモジュールの項目、予約済み割当も見える。これは更新日のあるレジストリ記録であり、モジュールの実装や導入を証明しない。ルートの登録、MIBの実装、監視観測の取得は別々の記録だ。RFC 3737が変えたのは次のルートを誰が登録するかであって、登録が実行コードの証拠になるわけではない。

出典