要約

  • RFC 1239 は五つの MIB ルートを 1.3.6.1.3 の実験用アークから、標準の mib-2 と transmission へ再割り当てした。
  • 背景には実装上の負担があった。標準化の後期に番号を変えると、内容がほぼ同じでもベンダーは製品を改修し、現場の問題や早期実装の萎縮を招き得た。
  • 新旧番号の表が示すのは標準化側の決定であり、個々の装置、管理ソフト、保存データが移行した時点ではない。

OID は文書番号ではなく、問い合わせ先だった

RFC 1239 が批判した従来の手順は単純だった。開発中の MIB には実験用アークを与え、Full Standard になってから標準 MIB のアークを与える。ところが昇格時に定義の実質的な変更がほとんどなくても、ベンダーは番号のために実装を直さなければならなかった。

RFC 1155 の SMI では、OID はオブジェクト型に行政的に割り当てられた名前である。管理側はその数列を要求に入れ、エージェントは対応する値を返し、収集ソフトは保存キーとして扱う。根が変われば、その下の全オブジェクトの数値アドレスが変わる。

遅い再割り当てには、もう一つの逆効果があった。将来の改修を嫌う実装者が、Full Standard まで着手を待つ可能性である。それでは、標準を育てるはずの実装経験が集まらない。RFC 1239 は、標準化の早い段階で標準アークを割り当て、その後も維持する方が望ましいとした。

現在の RFC Editor と Datatracker は文書を Historic、Legacy と記録する。これは文書の現在位置であり、特定機器の採用状況ではない。

五つの対応表は、五つの移行完了証明ではない

RFC 1229 の Generic Interface Extensions は 1.3.6.1.3.6 から 1.3.6.1.2.1.12 へ移った。experimental 6 が mib-2 12 になった形である。

残る四つは transmission 配下へ入った。RFC 1230 の IEEE 802.4 は実験番号 7 から 8、RFC 1231 の IEEE 802.5 は 4 から 9 へ移った。RFC 1232 の DS1 は 2 から 18、RFC 1233 の DS3 は 15 から 30 である。新しい共通ルートは 1.3.6.1.2.1.10 だった。

RFC 1239 は切替日も別名も定めていない。新旧を同時に提供する期間、能力交渉、管理ソフトの変換手順、履歴データの結合方法もない。番号表は標準上の行先を確定するが、現場の移行経路までは作らない。

権威ある番号と、実際に返った値を混同しない

現在の IANA SMI レジストリ には GenericIF 12 と transmission 8、9、18、30 が残る。後続 RFC が参照先になった行もある。現行レジストリは現在の権威を示し、RFC 1239 は再割り当ての履歴を示す。どちらも、単独では一台のエージェントの応答記録にならない。

新 OID への問い合わせ失敗には、旧版実装、未対応オブジェクト、アクセス拒否、停止、問い合わせミスなど複数の説明がある。旧 OID から応答があっても、それはその観測点の事実にすぎず、標準 OID がどこにも実装されていないとはいえない。片方の不在を、もう片方の状態へ飛躍させてはならない。

時系列データも同じである。表示名を変えず保存キーだけ替えれば、同じ系列が二つに割れる。逆に自動結合すれば、同時期のエージェント更新や意味の変更を隠すかもしれない。RFC 1239 はそうした事故を報告していない。だからこそ、正確な OID、機器と管理側の版、時刻、応答、権限条件、保存キー、結合判断を別に残す必要がある。

番号の安定は意味の固定でもない。後の文書は同じルートを使いながら、状態やアクセス、解釈を変え得る。RFC 1239 が守ろうとしたのは不要な改番からの互換性であり、永遠に同じ意味を保証することではなかった。

出典