要約

  • RFC 1052は短期の共通管理基盤としてSNMPを選び、Craig Partridgeが合意形成のためHEMSの撤退を提案したと記録した。同じ文書はHEMS RFC 1024を共通MIB作業の出発材料に含めた。
  • その決定後に出たRFC 1076は、階層データ木を小さなスタック機械でたどり、流れてくるASN.1命令を順に実行して応答を組み立てる別の設計を保存した。
  • プロトコルの採用、情報定義の再利用、照会の認可、エージェントの返却値、装置で観測された効果は別々の証拠である。

撤退は設計を無価値にする判決ではなかった

RFC 1021 が描いた問題は、機器の多様化だった。重要なゲートウェイを少数のベンダーが供給していた時代なら、熟練管理者が各社固有の道具を覚えることもできた。接続ネットワークと実装者が急増すると、人の経験だけでは共通運用を維持できない。

High-Level Entity Management System、HEMSは役割を分けた。管理対象には小さな照会処理系とイベント生成器を置く。管理センターのアプリケーションは複数命令を含む要求を作り、標準値だけでなく装置固有値も解釈する。故障しうるゲートウェイに重い知能を集中させない構成だった。

RFC 1021は監視と制御も分けた。監視は挙動を知るためのデータ収集、制御は挙動を変える行為である。効果を観測できない制御には意味がないため、初期HEMSは監視を厚くし、一般化できる制御や強いアクセス保護は未完成だと明記した。

1988年3月、選択の軸は設計の豊かさだけではなくなった。RFC 1052 はIABによるHEMS、SNMP、CMIP/CMISの検討を記録する。短期の基盤に推されたのはSNMPだった。ソフトウェアが既に存在して稼働し、運用者とベンダーが早い合意を必要としていたからである。

同じ報告には、HEMS側のCraig Partridgeがインターネット全体の合意を可能にするため、HEMSを候補から引くよう提案したことが記されている。だが直後に、HEMSが定義した監視項目は広範で十分議論されていると評価され、RFC 1024 をSNMPやCMIP/CMISの資料とともにMIB作業部会の入力にするよう勧告された。

選ばれなかったのは共通プロトコルとしてのHEMSであり、そこに書かれた意味のすべてではなかった。

選択後に完成した「別の道」の仕様

RFC 1076 は1988年11月に発行され、RFC 1023を置き換えた。4月の判断を覆す文書ではない。実験的HEMSがどのような監視・制御言語を考えていたかを、より完全な形で残した文書である。

照会は一つの遠隔手続きではなく、ASN.1オブジェクトの列だった。値やパスは到着すると制限深度のスタックに積まれ、演算コードは読まれた時点で実行された。要求の後半を受信している間に、前半の結果を出力することもできた。

この方式は、管理される側に要求全体を保持させず、複数の質問を一往復にまとめる。反面、後半でエラーが起きた時には、前半の結果が既に送られている。応答は全命令が同時に見た一枚の写真ではなく、順次処理の痕跡だった。

実行可能な命令はBEGIN、END、GET、GET-ATTRIBUTES、GET-RANGE、SET、CREATE、DELETEの八つに限られた。保存プログラム、サブルーチン、一般的な分岐はない。パス、テンプレート、値、フィルターを小さな命令集合と組み合わせることで表現力を得た。

管理情報は木として見えた。辞書が部分木をまとめ、根からのパスが名前になり、葉が値を持つ。処理系が通った部分は、文脈を含む木の形のまま応答へ写された。同じ小さなタグ番号でも辞書が異なれば意味が違うため、値だけを切り離して返さない設計である。

変わる表では、順番より性質を使う

インターフェース、経路、TCP接続の表は変化する。再起動前の三番目が、再起動後も三番目とは限らない。RFC 1076は一般的な位置番号を安定した識別子にせず、要素の内部値を調べるフィルターを用意した。

存在、等価、以上、以下を検査し、AND、OR、NOTで組み合わせる。あるIPアドレスを持つインターフェースだけのカウンターを得たり、その下のARP表へ降りたり、条件に合う複数要素へSETを実行したりできる。対象を「何番目か」ではなく「どの性質を持つか」で選んだ。

ただし、フィルター付きBEGINが複数の辞書に一致した場合、どれを使ってもよいとされた。複数一致をエラーにすべきかは実経験に委ねられている。正しい構文は一意な対象を保証しない。制御の前には、条件が一つだけに一致するという別の証明が必要だった。

GET-RANGEはOctetStringの一部を取り出し、機種依存のメモリ表現にも使えた。しかし辞書全体をGETしても、メモリは自動的には含まれない。探索可能なデータ木と、無制限の読み出し権限は同じではない。

返された値は、外側の効果まで引き受けない

SETとCREATEは操作後の木の部分を返した。DELETEは通常何も返さず、削除できなかった一致項目があればそれを返すことがある。読み取り専用項目へSETしても必ずエラーになるわけではない。現値を返し、要求値と違うことを呼び出し側が確かめる。

現実の制御には「仮想コマンド・状態レジスタ」という考え方を使った。木の項目へコードを書けば、インターフェースを停止するような実装固有の副作用を起こせる。その項目を読めば現在状態が返る場合もある。

ここで応答が証明するのは、HEMSの管理表現が処理後に示した値である。物理リンクが実際に停止したか、経路が収束したか、隣接装置が変化を認識したか、再起動後も設定が残るか、パケットが代替路へ移ったかは証明しない。返却値と観測効果の間には、別の測定面が要る。

この区別は現在にも残る。APIが要求受理を正しく返しても、下位処理は待機中、部分完了、直後に上書き、あるいは別のテレメトリーでしか確認できないことがある。RFC 1076は制御面の事実がどこまでかを古い言葉で明確にしている。

「値なし」は三つの理由を隠した

RFC 1022 のHEMPは要求、応答、イベント、エラーを包み、認証や暗号化の区画を用意した。区画があるだけで個別メッセージが保護されたとは言えない。1987年仕様では暗号方式の番号すら未割り当てだった。

RFC 1076も認可方式を決めなかった。HEMS環境が照会へレベルや能力を与え、各データ項目が読み取り・変更の可否を判定する。GETやSETは拒めるが、辞書そのものを隠してBEGINを失敗させてはいけない。そうすると一つの権限不足が複合照会全体を中断するからである。

未定義のタグ、未実装の任意情報、権限のない情報は、いずれも長さゼロの同じオブジェクトを返した。異なる装置へ汎用照会を送り続けられる利点がある一方、空の応答だけでは原因を区別できない。

処理を止めるエラーは、種類、実装内位置、要求内のバイト位置、演算、説明を持った。出力中のASN.1構造が何重にも開いていれば、未完の各層にエラーを置き、最後にも一つ置いた。既に流した応答を解釈可能に閉じる仕組みであって、先に起きた副作用のロールバックではない。

選ばれた単純さと、書いてはいけない系譜

1989年8月の RFC 1109 は、複数のネットワークでSNMPが動き、ベンダー実装と参照実装が存在すると報告した。同時に、性能監視の規模、設定管理、利用者アクセス制御、管理命令の認証などが未解決だとした。選択は共通の足場を作ったが、管理問題を完了させたわけではない。

後の RFC 1155 は、階層OBJECT IDENTIFIER、制限されたASN.1型、仮想情報ストアを持つSMIを標準化した。RFC 1157 は、Get、GetNext、Set、Trapというより小さな操作面でSNMPを定め、SMI・MIB・SNMPを推奨運用枠組みとして記録した。

木構造やASN.1の共通性だけで、HEMSから後の全OIDへ矢印を引くことはできない。RFC 1052が直接証明するのは、RFC 1024がMIB作業の入力に指定されたことだ。各項目のコピー表も、RFC 1076とSNMPの通信互換性も示していない。

むしろ、選択と再利用を分けたことに価値がある。一つの運用プロトコルへ早く収束しながら、競合案が整理した意味を出典付きで次の工程へ渡す。撤退した設計を勝者と偽らず、役立つ成果を敗者と一緒に捨てない方法だった。

資料と証明限界

RFC 1021は実験全体、RFC 1022はメッセージ外被、RFC 1024は情報定義、RFC 1052は選択、RFC 1076は照会言語、RFC 1109は運用後日談、RFC 1155は後のSMI、RFC 1157は後のSNMPを記録する。HEMSの導入台数、RFC 1076の実トラフィック、項目ごとの継承表、特定制御の現場結果は示さない。

確認できる結論は狭い。HEMSは共通プロトコル候補から退いた。情報作業の一部は明示的な入力として残った。そして照会応答は表現された木を示すが、外側のネットワーク効果を代わりに証明しない。