要約

  • RFC 1157では、エラー条件を通過したSetRequestの変数割り当ては、そのメッセージに関して同時に設定されたかのように実施される。応答は、人間の操作者、再起動後の保存、設定値が誘発する外部動作の完了までを証明しない。
  • RFC 1905は検証と変更を分ける。検証エラーなら割り当ては行われないが、commitFailedやundoFailedは変更または巻き戻し段階の失敗を示す。したがって、すべてのエラーを「変化なし」と読むことはできない。
  • RFC 1157の著者はJ. D. Case、M. S. Fedor、M. L. Schoffstall、J. R. Davinであり、Marshall T. Roseではない。Roseは謝辞でIETF SNMP Extensions Working Groupの議長として記され、初期SMIやMIB関連文書の共同著者だった。

夜間保守で、一つの要求が転送制御、タイマー、管理状態の三つを書き換える場面を考える。応答はnoErrorで、変数バインディングも返る。運用記録がこれを「担当者が変更を完了」と要約すれば、プロトコル処理、人の身元、承認、永続化、実世界の結果という別々の事実を一行に押し込むことになる。

RFC 1157が述べる処理はもっと限定的だ。エージェントは、名前の存在、値の妥当性、応答サイズ、その他のエラー条件を先に調べる。該当しなければ、各変数へ対応する値を割り当てる。その割り当ては、同じメッセージに関して同時に設定されたかのように効力を持つべきだとされる。これは複数の書き込み同士の関係を示す性質である。

この「同時のように」は、組織全体の正しさを意味しない。コンソールを使った社員の名前は分からず、変更票の承認も示さない。値が不揮発領域に保存されて再起動後も残るか、狙ったネットワーク効果がすでに現れたかも別問題である。エージェントが答えているのは、自らが公開する管理変数の範囲に限られる。

初期SNMPの変数モデルには、この境界が最初からあった。RFC 1157は、任意の命令を送るのではなく、変数を調べて変更するものとして管理機能を表現する。命令に似た効果は、後で動作を起こすパラメーターの設定として実現できる。再起動までの時間を設定する例なら、パラメーターの書き込みと装置の再起動は二つの観測点になる。前者が成功しても、後者は待機中、失敗、または別のサブシステムでしか確認できないことがある。

人物の位置付けにも同じ精度が必要だ。RFC 1157の署名はJ. D. Case、M. S. Fedor、M. L. Schoffstall、J. R. Davinで、Roseの名は著者欄にない。謝辞にはThe Wollongong GroupのRoseがIETF SNMP Extensions Working Group議長として載る。一方、管理情報の構造と識別を扱うRFC 1155はRoseとKeith McCloghrieの共著であり、MIB文書も固有の著者名を保つ。IETFの人物記録はRoseによる幅広いネットワーク管理文書を示し、経歴資料はSNMP作業部会議長や後のIETFネットワーク管理エリアディレクターという役割を記す。別文書の署名を借りなくても、技術形成と組織運営への寄与は十分に大きい。

RFC 1905ではSetRequestが、監査しやすい二段階の境界になる。変更前に、アクセス、書き込み可能性、型、長さ、符号化、値、整合性、生成条件、資源などを検証する。ここで失敗すれば、対応するエラーを返し、その要求の割り当ては実行しない。この種類のエラーなら、「要求は変更段階へ進まなかった」と判断できる。

検証が通ると、エージェントは割り当てを同時のように実施する。しかしRFC 1905は変更段階の故障も名前で残す。commitFailedは割り当てを完了できず、他の割り当てを元に戻す試みが必要だったことを示す。undoFailedは、元の状態への完全な復元を保証できなかったという、さらに強い警告である。前者では読み戻しが必要で、後者では独立確認まで混在状態の可能性を扱わなければならない。

同じ変数を異なる値で重複させた場合は、RFC 1905が実装依存としている。一つのリストという外形だけから、移植可能な実行順を推測することはできない。

セキュリティと承認は隣接するが別の証拠だ。RFC 3411はSNMPアーキテクチャで、メッセージ処理、セキュリティ、アクセス制御を別のサブシステムに置き、安全なSETを旧世代の重要な課題として扱う。RFC 3414のUSMはプロトコル主体の認証とメッセージ保護を可能にする。RFC 3415のVACMは、セキュリティモデル、名前、レベル、コンテキスト、ビュー種別、変数名を評価する。そこから、どの技術主体がどのポリシーで許可されたかは説明できる。それでも、実際に端末を使った人や、会社の変更権限までは自動的に決まらない。

信頼できる運用証跡は、単一の成功表示ではなく、結び付けられた複数の受領証である。要求と順序付き変数、応答、エラー状態とインデックス、認証主体、アクセス判断、直後の読み戻し、永続化後の確認、誘発されたサブシステムの結果を残す。そうすればSetRequestが実際に観測した事実だけを、過不足なく使える。

Sources