要約

  • active、notInService、notReadyはエージェントが返す状態であり、createAndGo、createAndWait、destroyはマネージャーが書き込む動作要求である。後者がGETで読まれることはない。
  • マネージャーは索引と値を提案するが、必要条件と遷移を決めるのはMIBとエージェントである。そのため、行は存在しても未準備であり得て、準備済みでもまだ機器に使われない。

表の形は、データベースの保証ではなかった

MIBのオブジェクト識別子にインスタンス索引を付けると、列と行からなる表が見える。だが1991年のRFC 1212は、それを概念上の表と行として扱った。列同士の関係はアプリケーションが理解する慣行であって、SNMPが完全な行や参照整合性を自動的に保証するわけではない。

行の削除にはMIB固有のinvalidのような整数を使えた。作成では、まだ存在しないインスタンスをSetRequestで指定し、エージェントが受理すれば生成された。DEFVALで省略列を補うこともできた。しかし、未完成の行がいつ存在し、いつ機器に使わせてよいのかは、表ごとに異なった。

複数の管理局が同じ表を書き始めると、その曖昧さは競合になる。索引を選ぶこと、行を確保すること、必要列を埋めること、運用に入れることは、本来別の出来事だった。

RMONは「作成中」を公開した

RFC 1271のRMON MIBは、後の仕組みに近いEntryStatusを定めた。値はcreateRequest、underCreation、valid、invalidである。管理局は行を確保し、作成中のまま列を整え、最後に有効化できた。同じ索引を複数が狙えば、最初に作成に成功したものだけが取得し、後続はエラーを受ける。

OwnerStringは、誰が資源を作ったかを示し、協調する管理局の衝突を減らした。ただしRFCは、これがアクセス制御ではないと明記している。協調しない管理局なら、他者の行を変更または削除できる。出所を示す情報と、排他的な権限は別物だった。

六つの値は、状態と動作に分かれる

RFC 1443でSNMPv2のRowStatusが標準化され、現在の定義はRFC 2579にある。

存在する行を読むと、返るのは三状態だけだ。active(1)は管理対象機器が利用可能であることを示す。notInService(2)は行が存在し、利用停止中で、エージェントが有効化を試みるだけの情報を持つことを示す。ただし内部整合性、資源の確保、将来の有効化成功を保証しない。notReady(3)は、利用に必要な列インスタンスが欠けている状態である。

残りは書き込み専用の動作だ。createAndGo(4)は作成と即時有効化、createAndWait(5)は利用させずに作成、destroy(6)は概念行に属する全インスタンスの削除を要求する。

GETがこの三動作を返すことはない。また、マネージャーはnotReadyを書けない。情報不足を判断して返すのはエージェントである。要求と観測結果を同じ値として保存しない点が、この設計の核心だった。

createAndGoは成功か不成立か

一度で作成する場合、マネージャーは未使用のインスタンス識別子を選び、必要列とRowStatus=createAndGoを同じSetRequestに入れる。エージェントの既定値が補える列もある。

情報が十分なら行が作られ、読み出せる状態はすぐactiveになる。不足していればinconsistentValueで失敗し、行は作られない。失敗後に修正可能な下書きが残ったと考えてはいけない。必要値を追加して再送するか、対応していれば段階的作成へ切り替える。

「作ってすぐ使う」という短い操作は、途中状態を残さないからこそ明確になる。

createAndWaitは未完成を隠さない

createAndWaitが受理されると、行は存在するが機器からは利用できない。必要列が欠けていればnotReady、必要情報を満たせばnotInServiceとして読める。後者は有効化を試せる準備ができたという意味であって、有効化が許可されたという意味ではない。

マネージャーはその後activeを書き込む。エージェントは受理できるが、値や現状が矛盾すればinconsistentValueを返す。エージェントがcreateAndWait自体をサポートせず、wrongValueで拒否することも規格上可能である。

停止中の行もメモリーや索引を消費する。RFC 2579は、notReadyまたはnotInServiceに異常に長く残った行をエージェントが検出し、削除するよう求める。具体的時間はDESCRIPTIONで示すべきで、記載がなければ人間の検討時間を含め約5分が提案される。すべての製品が5分で動くという証拠ではない。

最後の条件はMIBの文章が担った

RowStatusだけでは、active中に別の列を変更できるか決まらない。稼働中に変更できる表もあれば、いったんnotInServiceにする必要がある表もある。使用中のため停止や削除を拒否するエージェントも許される。

状態列のDESCRIPTIONは、有効化前に有効値が必要な列と、active中の変更条件を明記しなければならない。RFC 4181は後に、動的作成を認める表には通常read-createのRowStatus列を置き、再起動後の永続性、StorageType、エージェント自身による作成・削除条件まで文書化するよう整理した。

共通化されたのは遷移の言葉であり、個々の装置の判断全部ではない。具体的なMIBの説明が、共通語に実際の意味を与える。

一つのSetRequestを越えて原子性は広がらない

行作成では複数の列と状態変更を同じ要求に入れる。RFC 3416は、SetRequestを概念上二段階で処理する。まず全variable bindingを検証し、すべて通れば変更する。同じ要求内の代入は、互いに対して同時に起きたかのように扱われる。

変更に失敗すれば他の変更を取り消し、commitFailedを返す。すべてを取り消せなければundoFailedになる。後者の存在は、原子性を無限に拡張して解釈してはいけないことを示す。

対象は一つのSNMPエンティティが受けた一要求だけである。複数装置をまたぐトランザクションでも、分散ロックでもなく、再起動後の保存やデータプレーンの効果も証明しない。管理応答の成功と、実サービスの成功には別々の証拠が要る。

存在を運用と呼ばなくなったことが成果だった

RowStatusは役割を分けた。マネージャーは希望を述べ、MIBは公開契約を定義し、エージェントは値と遷移を判定し、動作中の機器が最終結果を示す。

見える行が未完成でもよい。完成した行が停止中でもよい。有効化要求は拒否され得る。activeでさえ、永続性、通信の成功、セキュリティ上の正しさまでは語らない。状態を狭く読めるから、観測証拠として使える。

出典と限界

RFC 1212とRFC 1271は初期の慣行とRMONの前身を示し、RFC 1443とRFC 2579はRowStatusを定義する。RFC 3416はSetRequestの境界、RFC 4181はMIB設計上の責務を示す。現在の普及率、ベンダー適合性、共通の清掃時間、セキュリティや通信効果は証明しない。意図・準備・運用の分離という評価は、仕組みから導いた分析である。