要約

  • RFC 873は、米国防総省がメーカー供給のISO系プロトコル群を待つという1982年の案に、完成時期と調達実務の両面から異議を唱えた。
  • 同じ枠組みを名乗る二社の製品でも、曖昧な層間動作や選択式の機能が違えば、相互接続の追加費用は顧客に回る。

調達書に「メーカーがサポート」と書けば、誰かが面倒を引き受けてくれそうに見える。ところがパケットは契約書の肩書きを読まない。RFC 873 でMichael A. Padlipskyが問うたのは、1982年の米国防総省が買おうとしていたネットワークの中身だった。ISOの参照モデルに沿った、将来メーカーが供給する一式を待てば政府の費用を抑えられるという意見があった。Padlipskyは、その一式が何を含み、何年待ち、二社の実装が食い違った時の修正を誰が払うのかを順番に確かめようとした。

まず、箱に入るはずの物を数える。彼の説明ではX.25だけでは計算機同士の資源共有に必要な機能をまかなえない。ほかの接続やアドレスの仕様を足しても、当時National Bureau of StandardsとISOが別々に進めていた全体像には届かない。二つの取り組みにも差があった。販売資料では「一式」と呼べても、実際の機能と接点はまだ部品ごとに交渉中である。調達担当者が一つの名称を発注しても、技術担当者は複数の未決事項を引き取ることになる。

次は時計だ。国防調達にはもともと長い準備期間がある一方、1982年のISO系プロトコル群は完成していなかった。層によっては紙上の提案が中心で、実運用の試験を経ていない。標準化の工程は年単位になるとPadlipskyは見た。国防総省はその時点でネットワーク契約を進めていた。他方、ARPANETの考え方に沿うプロトコルには、同省が使う複数のOSで既に動く実装があった。既存のコードを維持するには費用がかかる。それでも、完成を待つという選択にも時間の請求書が付いていた。

「サポート」という言葉の範囲も調べなければならない。RFCは、層と層の境界で何を渡すか、送信のたびに全部の層を通るのか、一つの層に幾つのプロトコルを許すのか、急を要する情報をアプリケーションまでどう届けるか、といった疑問を並べる。参照モデルはシステムを説明する助けになる。しかし二台の製品をつなぐには、同じ問いに両者が合う答えを出す必要がある。メーカーがそれぞれ誠実に仕様を読んでも、読み方の幅が残れば相互運用には後から調整作業が要る。

選択機能の例はさらに分かりやすい。一社が採用したオプションを、もう一社は許された範囲で省く。前者の顧客がその機能に依存すると、買った二つの装置は話が通じない。アプリを直すか、設定を変えるか、新しい開発費を出すか。Padlipskyは、その支払い先として利用者を見ていた。オプションという設計上の余地は、互換性の判断を先延ばしにし、購入後の現場へ送る。

機械そのものの財布にも目を向けた。CPU時間とメモリは、ネットワークで共有したい資源でもあった。各層を必ず通る設計や、余分な状態を抱える実装は、その資源を使う。Padlipskyは定期的な確認メッセージが運用費に響いた過去の例を出している。これはすべての製品を一つの数字で裁く材料ではない。購入前にどれだけ処理量と記憶容量を使うか測れ、という具体的な問いを生む材料だ。

文章には辛口の冗談が多いが、メーカーに悪意があるという筋書きには頼っていない。設計者の置かれた環境が、小さく効率的な実装を十分に後押ししない可能性を指摘している。最後には、無料の昼食はない、という勘定が待っている。保守、製品間の調整、CPU、メモリは別々に支払われる。また、TCP/IPを供給し始めたメーカーが増えているとも書いた。メーカーから買うかARPANET系を使うかという二択は、議論の最中に市場側から崩れ始めていた。

RFC 873は1982年の調達論争をその場の言葉で残す。国防総省が後に結んだ全契約の結果を語る資料ではない。ここで役立つ問いは明快だ。今日納められる完全な機能は何か。どの実装は既に動いたか。両社のオプションは合うか。合わなければ誰が直すか。保証書に社名が書かれていても、相手のホストとの握手は実際に試して確かめるしかない。