RFC 1451：アラームが残っても通知経路は失効する

要約

RFC 1451 の管理局は、上流から見るとエージェント、監視対象から見るとマネージャーである。大規模なネットワークや複数の管理領域で、観測と制御を分担するための二重の役割だった。

Alarm表は対象変数、周期、標本方式、上下のしきい値を持つ。Event表は条件にイベント型を結びつける。Notification表はイベントと宛先コンテキストを対応させ、InformRequestの再送条件を持つ。一つの行を作っても、残りの行が自動的に存在するわけではない。

絶対値方式では周期末の値をそのまま比較する。差分方式では前回と今回の周期末の差を比較する。snmpAlarmValue が示すのは最後に完了した標本期間であり、進行中の期間は終了するまで公開されない。

観測には時間の粒度があった。標本の間に起きて戻った変化は必ずしも残らない。差分の境界をより細かく扱う実装方法も提案されたが、全実装への保証ではなかった。

対象は一定の整数型に限られ、32ビット符号付き表現に入らない統計値は実装固有の方法で切り詰められ得た。表示値には、対象そのものとは別に採取時刻と表現幅の条件が付いていた。

Alarm表から対象を読む行為は、アクセス制御を迂回してはならない。標本コンテキストと送受のpartyには、そのコンテキストへの権限が必要だった。RFC 1445 が当時の管理モデルを与える。監視を設定できることと、対象情報を読む権限は別である。

認可エラー、対象なし、不適切な型が明示されれば、取得不能イベントを一度生成してAlarm行を破棄する。応答がないだけなら、通信不能と判断して行を破棄するか、最新値だけを削除して再試行を続ける。空欄の原因は一つではない。

上側しきい値を越えて上昇イベントを出した後、値が下側しきい値まで戻らなければ、次の上昇イベントは出ない。下降方向も同じである。境界付近の揺れを抑えるためのヒステリシスだった。

このため、高い値が続くことと、新しい上昇イベントが生まれることは異なる。Eventの回数は高い標本の数ではなく、状態履歴を含む遷移の数だった。起動直後の最初の標本には別の起動ポリシーも働く。

Alarm行は上昇、下降、取得不能ごとにEventの索引を持つ。ゼロは無関連を意味し、対応するEvent行が存在しない索引も接続にならない。検知条件が成立しても、イベント型へ進まない構成が可能だった。

Event行が持つのはイベントOID、生成回数、最後に生成したときのローカルsysUpTimeである。これは生成側の記録であり、受信側の台帳ではない。

Notification行はEventと宛先コンテキストの組で作られる。要求された再送間隔が実装の最小値より短ければ引き上げられ、要求回数が実装の最大値より多ければ削られる。設定値は希望であり、資源制約を通過した値が実行される。

当時の操作は RFC 1448 のInformRequestだった。後の RFC 3416 はこれを確認型通知としながら、配達保証はないと明記する。正常に届けば受信SNMPエンティティは内容をアプリケーションに渡しResponseを返す。応答はイベントの真偽や人の対応を証明しない。

snmpEventNotifyLifetime は秒単位で減少し、ゼロになると行の状態がdestroyになる。継続して通知を受けたい管理局は定期的に値を更新しなければならない。既定値は86,400秒だった。

期限切れになるのは、あるEventとある宛先の関係である。その逆向きにAlarmやEventまで削除する規則はない。生成側が標本とイベントを記録し続けながら、一つの受信経路だけが消えることは仕様上区別されていた。

公式記録はRFC 1451をHistoricとする。本文のセキュリティ節も、問題を論じないとだけ記す。現在の製品や過去の普及を推測してはならない。

後の RFC 3413 は通知の生成、受信、ターゲット、フィルタ、プロキシを別の役割として整理した。ここでは後代の境界を示すために使い、1993年の直接の後継と断定しない。