要約

  • RFC 1516は、SNMP応答を送るためにリピーターのリセットを短時間遅らせることを認めた。応答は要求との対応を示すが、物理動作の完了証明ではない。
  • 破壊的自己試験中のパケット転送は保証されなかった一方、管理カウンターとポートの管理状態は維持された。
  • 健全性更新とリセット完了通知は後から生じる。サービス復旧を宣言するには、さらに独立した観測が必要だった。

最後に届くのではなく、最初に届く返事

管理局が rptrReset に reset(2) を書き込む。RFC 1516 は、エージェントがリセットを少し待てると定めた。例として挙げた理由は、SNMP応答を送信する時間を確保することだった。そして応答は、いずれにせよ送信されなければならなかった。

この順序では、noError は「リセット済み」の印ではない。未処理だった要求と返事を request ID で結び、エージェントがプロトコル上の拒否をしなかったことを示す。装置を不安定にする工程は、その後に始まり得る。

工程には破壊的自己試験が含まれた。試験内容は標準化されず、セグメントへパケットを注入せず、管理機能を妨げないという境界だけが置かれた。試験中に受け取ったパケットは転送されることも、されないこともある。管理面の返事が正常でも、データ面の一期間は未確定のままだった。

読み戻しても履歴は出てこない

rptrReset は状態保存欄ではなく命令口だった。reset(2) の書き込みは START 状態への遷移を起こし、noReset(1) の書き込みは何もしない。読み取りは常に noReset(1) を返す。

したがって後のポーリングだけでは、命令がなかったのか、開始したのか、完了したのかを識別できない。要求値、request ID、応答、時刻を管理局側で残さなければ、操作の来歴は消える。現在値を集めることと、過去の行為を記録することは別だった。

文書が “Hub MIB” ではなく “Repeater MIB” を選んだのも同じ節度である。当時のハブやコンセントレーターには、Token Ring、FDDI、ブリッジ、ルーター、端末サーバーまで混在し得た。RFCが共通化したのは IEEE 802.3 リピーターであり、筐体全体の意味ではない。

リセットを忘却にしない

リセットは RFC 内の管理カウンターをゼロにせず、portAdminStatus も変えなかった。管理上無効にしたポートは、再起動したからといって勝手に有効にならない。自己試験はリピーターをリセットしても、管理情報を変更しないとされた。

この保存規則は、介入の前後を比較できるようにする。しかし保存されたカウンターは、試験中の各パケットが通ったことを証明しない。管理状態の維持は方針の継続を示すが、リンクやアプリケーションの回復を示さない。

ハードウェアの状態、運用方針、観測履歴は、同じ境界を別々に越える。リセットを「すべて初期化」と扱えば、標準に反するだけでなく、介入を評価する手掛かりまで捨てることになる。

完了には別の通知があった

自己試験後、エージェントは rptrOperStatus とエージェント固有の rptrHealthText を更新し、health trap を送る。さらに rptrResetEvent は、管理命令で始まったリセットの完了時に送られ、運用状態を含んだ。Set応答と完了通知は、それぞれ違う出来事の証人だった。

完了通知にも欠落可能性がある。同種の通知は五秒以上空け、抑制されたものは後送りせず破棄する。エージェント自身の再起動なら coldStart または warmStart であり、rptrResetEvent ではない。通知が見えないことだけで、全てのリセットや再起動を否定できない。

健全性も万能ではない。health text はエージェント固有で、非破壊試験はごく簡単な試験の後に “okay” を返してよい。エージェントの健康判断、リセット完了、利用者のサービス回復は別の主張である。

後継規格にも残った順序

RFC 1368 は既にカウンターと管理状態の保存を定めていた。RFC 1516 の変更一覧は、短い遅延とリセット後の処理を明確化したと記録する。返事を先に出す規則は、意識的な改訂だった。

RFC 2108 は SMIv2、複数リピーター、100 Mb/s 対応を加えて RFC 1516 を置き換えた。旧単一リピーター用オブジェクトは非推奨になったが、新しい rptrInfoReset は同じ順序を維持した。応答を送り、破壊的動作を実行し、管理情報を保ち、rptrInfoResetEvent で完了を知らせる。

RFC 1157 は request ID による要求・応答の対応と成功した Set の応答を定義する。RFC 1215 は trap の記述規約を与える。両者はメッセージを識別できるようにするが、先のメッセージを後の現実の代理証人にはしない。

監査できる一件にする

最低限、エージェント、対象オブジェクト、要求値、request ID、応答コード、送受信時刻を保存する。その後に動作開始・完了、カウンターの連続性、ポート管理状態、健全性変化、受信した完了／再起動通知、独立した通信試験を追加する。

すると「SetにnoErrorが返った」「完了通知を受けた」「管理方針が残った」「サービス試験が通った」を別々に言える。最初の一文しか確認できなければ、残りは未確認のままにする。

Heng Lu のランニングコード優先、最小初期仕様、現実層の議論は、この小さな順序の意味を明瞭にする。共通仕様は検証可能な交換を定める。自己試験は実装、実行権限は運用者、結果は動いているネットワークが担う。

情報源と証拠の限界

RFC Editor の RFC 1516 記録、RFC 1516、RFC 1368、RFC 1157、RFC 1215、RFC 2108 が履歴と技術的意味を支える。Heng Lu の三論考は編集上の区別を支える。

これらは特定製品、実配備、実行済み命令、実時間、応答や通知の受信、パケット転送、障害、復旧を立証しない。冒頭は規格から組み立てた時系列であり、事故報告ではない。