要約

  • RFC 1452はSNMPv2アプリとSNMPv1エージェントの間にプロキシまたは二言語管理局を置き、ローカル表で対象版を選んだ。
  • GetBulkはそのまま渡らず、反復指定をゼロにしてGetNextへ変わった一方、旧版固有のエラーは残された。
  • 上流の応答が示すのは変換交換の成立であり、元の操作や情報量、セキュリティ、運用効果の保存ではない。

透過性の前に選択があった

RFC 1452は新旧SNMPの移行判断を各アプリへ分散させなかった。SNMPv2側のプロキシ、または両方を話す管理局が差を引き受ける。

管理局は対象へ接続する前にローカルデータベースを引いた。アプリの意図だけでは送信版が決まらない。対象識別、表の行、選んだ版、変換規則、実際の下流要求は別の記録である。

表が古くても統一画面は開ける。二版対応という能力は、各対象についての知識が正しいことを証明しない。

一括取得は一歩に縮んだ

GetRequest、GetNextRequest、SetRequestはSNMPv1へ無変更で渡せた。GetBulkは違った。non-repeatersとmax-repetitionsをゼロにし、タグをGetNextRequestへ変えるのが規則だった。

旧エージェントが行うのは各bindingの一後継探索である。アプリが一交換で求めた複数位置は実行されない。継続は可能でも、元の要求範囲が保存されたとはいえない。

RFC 1448のGetBulkはSNMPv2固有の操作である。ここで重要なのは歩き方ではなく、誰が縮退を決め、どのPDUが下流へ出たかだ。request-idだけでは経路を再現できない。

古いエラーは古いまま返した

SNMPv1応答のnoSuchName、badValue、readOnlyは、SNMPv2エンティティ自身が生成しない値でも変更しない。新しい側は旧い由来を含む応答として解釈した。

これは不足した精度を創作しない選択である。粗いnoSuchNameをbinding別の例外へ勝手に分解すれば、旧側が述べなかった事実を足すことになる。保持は出所を守るが、ネイティブなSNMPv2応答にはしない。

tooBigならvariable bindingsを空にして上へ送る。GetBulkの上流要求に対し、ネイティブ経路では想定しない旧版の失敗形が現れ得る。応答形式には下流版の履歴が残る。

通知には計算された系譜が入った

SNMPv1 Trap-PDUは単なる包み替えではない。プロキシはsysUpTime.0を加え、genericまたはenterprise-specificのフィールドからsnmpTrapOID.0を算出し、enterprise bindingを後置した。

変換後のtrapは有用だが、各項目が独立観測されたわけではない。コピー、計算、宛先選択を区別する必要がある。宛先手順にはview存在確認の例外もあり、中間層は符号化だけでなく配送判断にも参加した。

OIDが残っても定義文法は変わる

MIB共存では、SNMPv1モジュールをSNMPv2で使い続けられ、真の意味変更がない限りobjectを廃止しないとした。それでも変換はimports、型、access、status、description、indexを修正する。

ACCESSはMAX-ACCESSへ、mandatoryはcurrentへ、optionalはobsoleteへ変わる。CounterとGaugeは32bit型になり、旧write-onlyはread-writeとされ、読取り結果は実装依存と説明される。

OIDの持続は名前の連続性でしかない。権限や読取り結果まで同一にはしない。RFC 1908は、旧MIBの版ごとにmandatory leafが違えばsubtreeからのgroup推定が曖昧になり、SMIv2で書き直すほかないとした。

後継仕様は中間層の負担を示した

RFC 2576とBCPのRFC 3584はSNMPv3まで扱った。binding別例外は一つのnoSuchNameに潰れ、複数失敗のどれを示すかは実装選択になり得る。Counter64は通知変換を不可能にし、値を飛ばすGetNext反復は高価になり得た。

これは後代の境界であり、1993年の製品証拠ではない。ただし、透過性が中間の状態、資源、判断で成立することは明確になる。

RFC 1452はセキュリティを論じていない。通過は認証、認可、秘匿、完全性を証明せず、応答も変更効果を証明しない。

出典