要約

  • RFC 1095はCMOTとSNMPを、ともに「Draft Standard」「Recommended」と記した。以前の方針ではSNMPが短期、CMIS/CMIPが長期を担ったが、IABは両方の実装経験を求めていた。
  • 二つの作業グループは同じInternet MIBを使った。しかし共通のオブジェクト体系だけでは通信できない。CMOTにはCMIS、CMIP、ACSE、ROSE、ASN.1、軽量プレゼンテーションをTCPまたはUDPへ結ぶプロファイルが必要だった。
  • RFC 1095が扱うのは一つの管理ドメインであり、管理アプリケーションは対象外、アクセス制御パラメータも任意だった。アソシエーション成立や成功応答は、組織的権限や物理的な変更結果の証明ではない。

勝敗が決まる前の標準表

後世から見ると、SNMPは実用的な勝者、CMOTは大きすぎた別案として整理されがちだ。しかしRFC 1095が記録した1989年4月には、IABの標準表に二つの名前が同じ位置で載っていた。CMOTとSNMPはどちらもDraft Standardであり、どちらもRecommendedだった。

ネットワーク管理に対応するIP/TCP実装は、少なくとも一方を採用することが期待された。IABは、実装者と利用者が二つのプロトコルを試し、経験を報告するよう求めた。ここでの「推奨」は、完成した市場の判定ではなく、実装と実験への政策的な招待だった。

一年早いRFC 1052を見ると、二つの役割は同じではない。SNMPは、既に動くソフトウェアがあるため短期の基盤とされた。CMIS/CMIPは、ISOの枠組みに基づく長期の管理システムとして、開発・導入・試験を進める役割を与えられた。

急成長するネットワークには、待たずに使える道具が必要だった。同時に、インターネットで得た実装経験を国際標準へ返す回路も残したかった。二本立ては優柔不断ではなく、緊急性と将来性を別々に扱う方法だった。

同格の標準状態を、同規模の普及と読み替えてはいけない。RFC 1109は1989年6月時点で、SNMPについて複数の実装と運用例を挙げる一方、公開利用できるCMOT実装は会議で報告されなかったとする。計画中の製品やデモはあった。RFC 1095が示すInterop ’88の試作は、実現可能性と複数ベンダー間の可能性を示したのであり、普及率を示したのではない。

共通MIBは、同じ対象を指すための橋だった

二つの方式をつないだ中心は、パケット形式ではなく管理情報だった。RFC 1052は独立したMIB作業グループを置き、その成果をSNMP側とNetman側の両方に提供するよう求めた。RFC 1109によれば、両グループはおよそ100個の変数をInternet管理の必須オブジェクトとして合意した。

同じIPカウンターや経路表エントリーが、質問に使うプロトコルによって別の意味になる事態を避けられる。短期のSNMPから長期のCMIPへ滑らかに移行するという当時の構想も、この意味の連続性を前提にしていた。

ただし、同じ名詞を知っていても会話は成立しない。インスタンスの指定、操作範囲、フィルター、イベント通知、エラー、セッション確立、保護方法は、MIBの名前だけでは決まらない。オペレーターが使う画面や自動化も共通化されない。

RFC 1109は、管理システムの有効性を決めるのはプロトコルだけでなく実際の管理ツールだと指摘した。当時のSNMPとCMISは、過去の情報を問い合わせたり、30分後の操作を直接表現したりできなかった。

MIBは「何を観測対象として呼ぶか」をそろえた。RFC 1095のプロファイルは、その意味を独立実装の間でどう運ぶかを決める必要があった。

相互運用性は、層と層の継ぎ目に宿る

CMOTは、CMIPをTCPソケットに載せるだけの方式ではない。ASN.1がデータを表し、ACSEがアプリケーション・アソシエーションを扱い、ROSEがリモート操作を運び、CMIS/CMIPが管理サービスとメッセージを規定する。Internet SMI/MIBが対象を与え、RFC 1085の軽量プレゼンテーションが下位との接続を担う。

RFC 1095は、機能単位、アプリケーション・コンテキスト、オブジェクトのクラスとインスタンス、スコープ、フィルター、同期、PDUを選び取る。そしてACSE、ROSE、CMIPをどのようにシリアライズするかを定める。

軽量プレゼンテーションの狙いは、ISOのプレゼンテーション、セッション、トランスポート各層を丸ごと実装せずに、ISOのアプリケーション要素をTCP/IP環境で使うことだった。削ったのは実装負担であって、互換性の判断ではない。

「CMIPを実装」という表示だけでは、コンテキスト、機能、符号化、MIBの版、トランスポートが分からない。プロファイルは広い規格群から一つの交点を選び、相互運用を試験可能にする。逆に言えば、その交点の外側にあるアプリケーション品質や組織の権限までは保証しない。

TCPとUDPは同じ証拠を残さない

RFC 1085はTCPによるサービスを「high-quality」、UDPによるものを「low-quality」と呼んだ。低品質は本当に低品質だ、という強い注意も置いた。プレゼンテーション層を経由しても、UDPにTCPの接続性、順序、回復が加わるわけではない。

RFC 1095のCMOTは両方を利用できた。TCP/UDPとも管理側に163、エージェント側に164のポートを割り当て、UDPでは当時の条件でIPフラグメントを避けるためPDUを484オクテットに制限した。宛先の発見はディレクトリ、ローカル表、あるいはアソシエーションの試行に頼る場合があった。

したがって「CMOTのアドレス」だけでは運用情報が足りない。どのトランスポートか、どの役割か、どのプロファイルか、その対応表はどこから来たかを保存する必要がある。TCP接続の成立とUDPデータグラムの受信は、経路について異なる事実を示す。どちらも送信者の組織的な権限は示さない。

障害も層別に扱うべきだった。パケット損失、プレゼンテーション不一致、アソシエーション拒否、未対応のCMIS機能、アクセス拒否、管理対象内部の問題は、同じタイムアウトに見えることがある。「CMOT障害」という一行は原因を消す。

一つの管理ドメインの外へ、権限は運ばれない

RFC 1095はmanager、agent、managed objectを説明し、OSI管理の五つの機能分野を支える基盤を示す。一方、実際の管理アプリケーションが各作業をどう実現するかは標準化しない。複数ベンダーの最小限の相互運用面を共通化し、オペレーター向け製品は競争に残した。

さらに、管理ドメイン間の関係と相互作用を対象外とした。規定されるのは一つの管理ドメインである。この境界はIPサブネットより制度的だ。

管理ドメインは、どのシステムが管理者として命令でき、どの装置がそれを受け、どの方針と責任が適用されるかをまとめる。ルーティングはパケットを他組織へ届けられるが、管理権限を委任しない。

CMOTは要求の形式を定められる。しかし他組織のmanagerがその操作を行う資格や、結果への責任分担は定めない。ドメインをまたぐ管理には、プロファイルの上に別の合意が要る。

プロトコルが双方向に同じ役割を実装できても、制度上の力が対称になるわけではない。権限には範囲、根拠、期限がある。

アソシエーション成立は委任状ではない

ACSEでは、管理操作の前にアプリケーション・コンテキストと機能単位を交渉する。受諾された事実は、二つのスタックが互換な会話条件を見つけた証拠になる。

しかし、それは操作者の身元や委任の証拠ではない。RFC 1095では、アソシエーション単位と要求単位のアクセス制御パラメータは任意だった。アソシエーション確立時の利用を推奨し、将来のTCP/IP認証を期待した一方、要求ごとのフィールドを受信側が無視することも許した。暫定的な簡易手段は、暗号化されないパスワードである可能性さえあった。

問題の存在を認識していたことと、問題を解決済みにしたことは違う。RFC 1109も、利用者アクセス制御と管理コマンド・応答の送信元認証を、CMOTとSNMPの双方が扱い切れていない課題として挙げた。

到達可能なら試行できる。プロファイルが合えば会話できる。認証されれば、ある方式のもとでprincipalを割り当てられる。認可されれば、その操作が許される。順序を飛ばしてはいけない。

応答の成功と、装置の変化は別の時点にある

CMISは読み取り、属性変更、イベント通知を構造化できた。それでもRFC 1095が必須とした同期はbest-effortで、atomic synchronizationは任意である。物理装置に対する万能なトランザクションではなかった。

アソシエーションが成立し、変更操作に成功応答が来たとする。そこから分かるのは、プロファイルに従うスタックが要求を処理し、agentが定義された結果を返したことまでだ。基板のモードが変わった、トラフィックが移った、再起動後も設定が残った、利用者のサービスが改善した、とはまだ言えない。

結果には別の読み戻し、イベント、独立カウンター、永続化確認、外部観測が要る。同じagentが命令結果と確認値の両方を返すなら、その共通した証拠源も記録する。

これはプロトコルの価値を否定する話ではない。CMOTはメッセージと意味を標準化する。装置の計測・制御実装が意味を動作へ変換する。ハードウェアとネットワークが結果を生む。各境界はそれぞれ検証されるべきだ。

RFC 1189は、プロファイルにも版があることを示した

1990年10月、RFC 1189がRFC 1095を廃止・更新した。CMIS/CMIPが最終的なISO標準へ進んだため、チュートリアルを削り、MIBの意味を別文書へ移し、新しい実装合意を採用し、旧アプリケーション・コンテキスト名との互換性を残しつつ交渉方式を変えた。

これはプロトコル名だけでは運用状態を表せないことを示す。基礎規格が変われば、どの版と選択肢が会話できるかをプロファイルが改めて指定する。

1989年の二重推奨は過渡期だった。それでも、同じものを名付けること、同じ意味を運ぶこと、それを変更する権限を持つこと、変更結果を確認することを分けた構造は残る。RFC 1095は最初の二つを接合し、後の二つを勝手に主張しなかった。

出典