概要
- 初期のホストテーブルは、限定的な連鎖を通じて実質的な権限を獲得した。すなわち、ARPA が ARPANET のために Network Information Center を調達し、SRI が共通記録を維持し、参加サイトがホスト情報を提供・消費し、後に DCA がそのサービスを運用上の DoD 環境に統合した。
- RFC 810 は、DoD ホストが渡すトラフィックに関連して使用される名前とアドレスについて、登録の前提条件を公表した。しかし、現存する仕様書は、監視、パケット拒否、制裁、遵守率、あるいは特定の遮断された通信を実証していない。
- 公開記録は、初期の完全な契約書、ホストテーブル要求ファイル、異議決定、修正結果、上書き記録、執行報告書、あるいは救済策を提供しておらず、それらがなければ、NIC の無制限な裁量権、またはすべての外部ネットワークに及ぶ公的権限のいずれも確立できない。
1974 年 3 月 8 日、Network Information Center はすべての ARPANET サイトに対し、ローカルホストテーブルの変更を要請した。この指示は、SRI の Augmentation Research Center の Bill Ferguson によって発表されたRFC 620「Request for Monitor Host Table Updates」に掲載された。NIC サービスは、8 進数表記でネットワークサイト 53 に位置するOFFICE-1に移動していた。サイト 2 はSRI-ARCのままであったが、そのニックネームはARCとなり、よく知られたニックネームNICは代わりにサイト 53 を指すことになった。この通知は、TENEX モニタテーブル用の正確なエントリを提供し、他のオペレーティングシステムを実行するサイトには同等の変更を行うよう指示した。
RFC 620 は指示を記録しているが、コンプライアンスの確認事例ではない。この RFC は、作業を実行した特定のオペレーター、実行しなかったサイト、またはその結果生じた停止を特定していない。それでもオペレーターは、文書によって暗示される必要な役割である。つまり、各サイトの誰かが、そのオペレーティングシステムに適した方法で、ローカルで使用されるマッピングを変更しなければならなかった。テーブルが古いままだと、NICをサイト 2 に関連付け続け、名前ベースの試行を意図された NIC サービスから遠ざける可能性があった。その結果はマッピングの変更から生じるが、RFC は実際のルックアップ失敗や誤った接続の発生を報告していない。
この通知は、一見単純な名前の背後にある管理構造を明らかにしている。SRI は新しい関連付けを発表できたが、その発表はすべてのリモートマシンを書き換えるものではなかった。各サイトは指示を受け取り、それを解釈し、自身のシステムを変更しなければならなかった。維持された記録、配布チャネル、ローカル実装が収束した場合にのみ、共有ネーミングは機能した。
1974 年 3 月 25 日、RFC 627は、より定期的な配布メカニズムを発表した。公式ホスト名のオンライン ASCII ファイルがOFFICE-1で利用可能になり、そのアドレスは 10 進数で 43、RFC 620 で使用された 8 進数の 53 と同等であった。NIC はこのファイルを維持し、毎週追加や変更を組み込むことになっていた。各ネットワークホストは、ファイル転送プロトコルを使用して新しい情報を取得する責任を負った。変更、追加、修正、コメントは、ネットワークメール、電話、または NIC 識別システムを通じて Elizabeth “Jake” Feinler に送ることができた。
これら 2 つの 3 月の文書は、要求から決定に至る完全な取引を保存していない。しかし、これらを前後の記録と組み合わせて、日付を分離したまま、最小限の複合再構成を確立することは可能である。
1971 年には、RFC 273で提案された手順に基づき、ホストは連絡担当者を通じて優先正式名を選択した。連絡担当者は選択を伝達したが、この文書は技術連絡担当者がサイトのすべての組織的決定を下す権限を個人的に有していたことを立証していない。提案された命名スキームは、ニックネームがネットワークコミュニティ内で一意であることを期待し、重複や極端に長い名前が選択された場合の議論を想定していた。このスキームは、NIC の拒否権、却下テスト、最終決定ルール、上書き、または上訴を規定していなかった。
1974 年 1 月、RFC 608は、公式ホスト名を、ホストと NIC の間の交渉によって得られる文字列として記述した。この RFC は、文字と形式の制約を確立し、Feinler の NLS ソースファイルを特定し、機械可読な ASCII 版の定期的な生成を提案した。しかし、争われた交渉がどのように終了したか、議論が失敗した場合に誰が優勢になったかは説明していない。
1974 年 3 月、RFC 627 は、利用可能なファイル、更新の毎週の組み込み、修正チャネル、および各ホストが新しい情報を取得する責任を確立した。1982 年になって初めて、RFC 810は、DoD ホストテーブルの利用者が、それを必要なローカル形式に変換する責任を負うことを明示的に述べた。これらの 1971 年、1974 年、1982 年の記述を 1 つの観察されたルーチンに圧縮したり、すべてのステップを同じ職員に帰属させたりするのは不正確である。
したがって、防御可能な複合像は控えめなものとなる。ホストは連絡担当者を通じて希望する名前を伝達した。公表された慣行がその名前の形式を規定し、ニックネームの一意性が期待され、重複や長い選択は議論を促す可能性があった。SRI はソースを維持し、そこから共通ファイルを生成した。各サイトはファイルを取得し、その内容をローカルシステムに組み込んだ。1982 年までに、ローカル変換の責任は利用者が負うと明示された。提案された名前が争われたままである場合、修正が異議を申し立てられた場合、またはサイトが指示を拒否した場合に何が起こったかは、手続きに関する RFC だけからは回復できない。
これがホストテーブルの権限における最初の境界である。共通記録は、参加システムが認識する名前を決定することができたが、基盤となるコンピュータが存在するかどうか、物理回線が設置されたかどうか、または組織がネットワークに参加を認められたかどうかを決定するものではなかった。その効果は運用上のものであり、名前ベースの使用にとっては時に深刻であったが、すべての接続性を掌握するものではなかった。
4 つの異なるテーブルと共通ファイルの必要性
オンラインホストファイルは、観察された調整問題に対処した。1973 年 12 月、RFC 606は、SRI-ARC、BBN-TENEX、USC-ISI、PARC-MAXCという 4 つのアクセス可能な TENEX システムについて記述し、それらのホスト名とアドレスのマッピングが互いに異なっていたと述べた。いずれも完全ではなく、著者は各々が公式リストから何らかの点で逸脱していると考えた。
その証拠は、すべての ARPANET サイトが不正確なテーブルを持っていたという主張に拡大解釈されるべきではない。これは、4 つの特定のシステムにおける不一致を立証するものである。その限定的な発見でも、個別のメンテナンスのコストを示すには十分であった。それらのマシン間を移動する人は異なる答えに遭遇する可能性があった。1 つのローカルセットに対して書かれたプログラムは、別のマシンに移されたときに失敗する可能性があった。新たに追加または名前変更されたホストは、あるサイトでは認識されるが、別のサイトでは未知のままであるかもしれない。
RFC 606 は、NIC によって維持される中央生成の機械可読ファイルを提案した。この RFC は、エントリ内の 2 つの中核的事実（ホスト名とホストアドレス）を、ホストステータス、プロトコル動作、ニックネームなどのオプション属性から区別した。著者は、属性は完全である必要はなく、プロトコル交渉、口コミ、またはホストの特性を発見する他の方法を置き換えるべきではないと警告した。この提案は意図的に具体的であり、互換性のないローカルリストを解決することを目指し、ネットワーク参加のための包括的な憲法を確立することではなかった。
RFC 608 は中央ファイルのアイデアを受け入れ、ARPA の情報処理技術局（Information Processing Techniques office）からの支持を得ていると報告した。Feinler は SRI の NLS 形式でソースを維持し、一方でプログラムが ASCII 配布ファイルを定期的に生成することになっていた。当初、生成されるエントリには公式名、10 進数のホストアドレス、ステータスが含まれることになっていた。他の情報は、データが利用可能になり次第追加される可能性があった。この文書はまた、ARPANET 外のホスト用のネットワークプレフィックスを許可しており、著者らが既に ARPANET ホスト集団よりも広い比較セットを想定していたことを示している。しかし、実際に含まれたすべての外部ホストを特定しているわけではない。
ソースと配布の区別は重要であった。NLS は、構造化情報を維持するために使用される SRI のシステムであった。ASCII 版は、異機種ホストによる取得と処理のために設計された。SRI-ARC は、これらの通知のいくつかが発行された組織的・コンピューティング的文脈であり、一方OFFICE-1は 1974 年 3 月に NIC ユーザーと公開ホストファイルにサービスを提供するマシンとなった。後の文書では、DoD テーブルとネームサービスを提供するホストに対してSRI-NICを使用した。これらのラベルは技術的および組織的変更を示しており、一つの不変のマシンの交換可能な名前として扱うべきではない。
RFC 627 は提案を発表されたサービスに変換した。ホストが公式名をモニタで使用することを奨励し、各ホストがファイルを取得する責任を負わせた。ニックネームはオプションであり、名前からアドレスへの変換を提供するシステムはそれらを使用するよう推奨されたが、必須ではなかった。この文書は追加と修正のチャネルを提供したが、チャネルの存在は、要望が拒否された場合にかかった時間、要求された証拠、利用可能な救済策を証明するものではない。
アーキテクチャは使用時点では分散されたままであった。SRI が参照ファイルを維持したが、リモートサイトはそれをいつ取得し、どのようにインストールするかを決定した。最近修正されたマスターは、古いローカルコピーと共存する可能性があった。オペレーターは公式ファイルをローカルエイリアスで補完することができた。数値アドレスを知っている人は、欠落した名前をバイパスすることができた。テーブルは不一致を減らしたが、パケット交換サブネットそのものにはならなかった。
それでも、誤ったエントリは実質的な影響を与える可能性があった。名前ベースのプログラムは、意図したマシンではなく記録されたアドレスにトラフィックを向けるかもしれない。エントリがないと、ソフトウェアは要求された名前を変換できないかもしれない。遅延したローカル更新は、廃止された結果を保存するかもしれない。正確な動作はローカルのオペレーティングシステムとアプリケーションに依存した。RFC は、すべての省略が切断を生み出した、あるいはすべての不正確なエントリが同じエラーを生み出したという普遍的な主張を正当化しない。
3 月の移転は、より狭い命題を示している。NICがOFFICE-1に移動した後、RFC 620 の変更を実装したサイトは、ニックネームをサイト 53 に関連付けるだろう。古いままのサイトはそれをサイト 2 に関連付け続けるかもしれない。SRI のサービス移動はリモートテーブルとは独立して発生したが、共有ニックネームの有用性はリモートでの採用に依存していた。記録は、他のマシンがそれに基づいて行動したために重要であった。
名前はホストから始まり、無制限の NIC 拒否権ではなかった
共通ファイルは、NIC が望む任意の名前を割り当てることを可能にする決まったルールから生まれたわけではない。1971 年の RFC での議論は、命名についての実質的な不一致を記録している。
RFC 226は提案されたニーモニックのセットを回覧し、異議を求めた。競合する提案が続いた。一部の参加者は短いコールサインを好み、他の参加者は機関やプロジェクトのアイデンティティを保存する名前を望んだ。議論は単に表面的なものではなかった。名前はコマンド、文書、ユーザーの習慣に現れた。命名ルールは、したがって、文字だけでなく不便さと認識を分配した。
RFC 237において、NIC は、命名標準を維持するための論理的な組織であり、ネットワークワーキンググループが構文と現在のリストを確定した後に、新しいホストに名前を割り当てることを提案した。これはサービスオペレーターによる制度的提案であった。これは NIC が自らの役割をどうあるべきと考えていたかの証拠であり、接続されたすべての組織または上位の公共当局がその主張全体を受け入れた証拠ではない。
RFC 273 は、以前の提案が受け入れられなかったことに対応した。この RFC は、ホストが連絡担当者を通じて、自身の正式名を選択すべきであり、重複や極端に長い名前を選択した場合には議論の対象となる可能性があると述べた。1 つの機関のホストは、同じ機関のニーモニックを使用することが期待された。ニックネームはネットワークコミュニティ内で一意であるべきであるとした。
この文言は、地域的な選択と中央での議論の可能性を確立している。誰が最終的な拒否を発行できるかは定義していない。重複は共有ニックネームの目的を損なうが、技術的な非互換性だけでは管理的な救済策を明らかにしない。NIC がサイトを説得して別の名前を選ばせたかもしれないし、スポンサーが介入したかもしれないし、サイトが非公式の慣行を受け入れたかもしれないし、あるいは一部の不一致が未解決のまま残ったかもしれない。これらの可能性を区別するには完全なケースファイルが必要である。
1971 年 12 月に発行されたRFC 289は、ほぼすべてのサイトが希望する名前を回答したと報告した。そのタイトル「What We Hope Is An Official List of Host Names」は、この作業の暫定的な性格を保持している。出現しつつあるリストは、限られた ARPANET コミュニティ内での要請とサイトの応答を反映していた。それは一方的な私的発明でも、世界的な公的委任の結果でもなかった。
連絡担当者の役割も注意を要する。RFC 273 は、連絡担当者をホストが名前を選択し伝達するチャネルとして使用した。後にComputer History Museum の SRI ARC/NIC 記録のガイドは、技術連絡担当者は一般的にサイト管理を代表して発言する権限を持っていなかったと述べている。アーカイブガイドは、後に Host Administrator という役割が作成され、その保持者がサイトの行動を承認できるようになったと説明している。このガイドはより長い期間をカバーしているため、1971 年のすべてのやり取りに単純に逆行投影することはできない。しかし、「連絡担当者」を組織の経営幹部と同義語として扱うことに対して警告を発している。
安全に言える最大限のことは、公開された 1971 年の手続きにおいてホストが元の選択者であり、連絡担当者が伝達チャネルであり、NIC が共有結果を維持したということである。構文と期待される一意性が、共通の名前空間で機能できるものを制約した。文書は包括的な裁定システムを開示していない。
その限定的な裁量はそれでも意味があった。名前が文書や機械可読ファイルに現れると、他の場所のユーザーはそれを信頼できた。ホストは名前を変更できたが、そうすることでソフトウェア、文書、ローカル知識にコストがかかった。安定性が実質的な権限の源となった。センターは、その維持された答えを無視するのを難しくするために、広範な法的権力を必要としなかった。
ARPA のサービス契約と DCA への移管
制度的な連鎖は、より広いインターネットではなく、連邦研究プログラムから始まった。
ARPANET は、米国国防総省の Advanced Research Projects Agency を通じて確立された特定のパケット交換ネットワークであった。ARPA は研究プログラムに資金を提供し、請負業者を選定し、参加研究センターを支援した。この機関は 1972 年に Defense Advanced Research Projects Agency となった。したがって、「ARPA」はネットワークの確立と初期の命名論争に適切であり、「DARPA」は後の期間の記録に現れる。
1978 年に作成されたARPANET Completion Reportによると、スタンフォード研究所（Stanford Research Institute）は、ARPANET のための Network Information Center を開発・運営する契約を受けた。作業は 1969 年のネットワーク実装と並行して開始された。この報告書は、参加者および配布リストを維持し、技術文書をアーカイブし、ホストリソースに関する情報を提供し、SRI の NLS システムへのアクセスを提供し、ARPANET プロトコル仕様を維持するサービスについて説明している。
これによりスポンサーと請負業者の関係が確立された。ARPA は、自らが支援するネットワークと研究コミュニティのために情報サービスを調達した。SRI は契約が要求することを何でも実行する義務を負い、ARPA は契約された履行に対する対応する権利を有していた。公開報告書は、初期の作業明細書、修正、受入基準、制裁、データ条項、またはホスト名決定ルールを再現していない。したがって、その義務の完全な法的内容を立証することはできない。
ARPANET に接続されたサイトは、制度的に多様であった。大学、研究所、政府研究所、軍事施設、民間請負業者が含まれていた。法的形態の多様性は、すべてのサイトが非加盟の公的オペレーターであることを意味しなかった。多くは、連邦政府の資金提供、契約、または承認されたミッション関係を通じて参加した。同時に、基礎となるサイトの文書がないため、接続されたすべての組織がホストテーブルの遵守を要求する同一の契約条項を持っていたと主張することはできない。
ARPA から Defense Communications Agency への移管に関する最も強力な直接的な説明は、段階的かつ日付が付けられている。Completion Report は、ARPA-DCA 間の覚書に基づき、ARPANET の管理が 1975 年 7 月 1 日に DCA に移管されたと説明している。また、1975 年 12 月 31 日までの 6 か月間の段階的移行期間が記録されており、その間、ARPA は DCA を支援し続け、DCA が管理役割を引き受けた。詳細な移行計画は 6 月までに完了していた。
報告書によると、移管されたネットワークは、政府業務に使用される DoD 施設として運用されることになっていた。DCA は、ARPANET スポンサーを含む費用分担の取り決めを通じて、運用と保守に資金を提供することになっていた。DCA は当初、ネットワークの運用、保守、および NIC 機能のために BBN および SRI と契約する予定であった。報告書は、DCA が後日、確かに最初の年以降は、他の請負業者を保持できることが明確に示唆されていたと述べている。
これは、請負業者選択のレベルでの制度的な置き換え可能性の証拠である。しかし、DCA がすべての NIC 記録の完全な移植可能コピー、請負業者が作成したデータに対する無制限の権利、テスト済みの移行パッケージ、またはあらゆるサービス障害に対する強制可能な救済策を所有していたことを証明するものではない。顧客は原則として別のプロバイダを選択できるかもしれないが、スタッフの知識、ソフトウェア、アーカイブ、現在の記録、サイト関係を移転する際に、手ごわい実際的な障害に直面する可能性がある。
1978 年の DCA 出版物であり、ARPANET Information Brochureとして索引付けされている文書も、管理移管日を 1975 年 7 月 1 日としている。後の Computer History Museum のファインディングエイドは、矛盾する遡及的な説明を示している。つまり、ARPANET の運用は 1973 年に DCA に引き渡され、DCA 契約資金が 1974 年以降 SRI NIC を支援したという。
この矛盾は可視化されたままにすべきである。Completion Report の正式な覚書の年表は、正確な移管日と段階的移行を提供している。ファインディングエイドは異なる要約日付を提供するが、それらを調整する基礎となる文書を提供していない。また、NIC は 1973 年に別個のプロジェクトになったとも述べているが、これは ARPANET 管理の移管とは異なる制度的変更である。関連する契約や管理記録がなければ、1973 年の運用に関する声明と 1974 年以降の資金提供に関する声明を、単一のシームレスな年表に変換することはできない。
正式な移管後も、DARPA は ARPANET を使用する研究を引き続き支援でき、一方 DCA は運用ネットワークを管理した。DoD は親政府環境であり、DARPA と DCA はその中で異なる機能を持っていた。SRI は政府そのものになるのではなく、NIC サービスを提供する請負業者であり続けた。参加サイトはホストを運用した。ホスト連絡担当者や後の連絡役割は情報や指示を伝達した。これらの役割を区別しておくことで、調達権限が普遍的な権限と誤解されるのを防ぐことができる。
ARPANET への参加承認はホストテーブルの決定ではなかった
ホストテーブルは運用環境内のマシンを記録したが、SRI の記録保守は SRI に ARPANET に誰が参加できるかを決定する唯一の権限を与えるものではなかった。
1978 年 12 月の ARPANET Directoryは、加入者カテゴリとサービス取得のプロセスについて説明していた。その枠組みは、参加承認とスポンサーシップを DCA のネットワーク管理構造内に置いた。将来の加入者は、許容される政府目的、スポンサーシップ、利用可能な施設を必要とした。これらの決定は、特定の管理ネットワークへのアクセスに関係していた。
この区別は基本的である。DCA は ARPANET 加入者の資格を管理することができた。SRI は、参加後または参加前後に使用されるディレクトリとホスト情報を維持することができた。ホストテーブルエントリは、便利な共有使用のために必要かもしれないが、ホストを記録することは、組織の接続を承認し、Interface Message Processor をインストールし、回線を供給し、ミッションを認可するのと同じ制度的行為ではなかった。
ARPANET 集団もまた、DoD インターネットと同一視されるべきではない。ARPANET は 1 つのネットワークであった。DoD インターネットは、ARPANET、パケット無線システム、衛星システム、および他のネットワークがインターネットプロトコルと共通の調整情報を使用できるインターネットワーキング環境であった。より広く出現しつつあるインターネットはさらに広範であり、法的、契約的、技術的関係が一様でない、変化するネットワーク、実験、およびオペレーターの集合であった。
1981 年 9 月までに、RFC 790は、ARPANET、UCLNET、CYCLADES、TELENET、British Post Office EPSS、DATAPAC、TRANSPAC、LCSNET、TYMNET、およびさまざまなパケット無線、衛星、ローカル、実験システムを含む多数の名前付きネットワークに割り当てられたインターネットネットワーク番号をリストした。この RFC は、南カリフォルニア大学情報科学研究所（University of Southern California’s Information Sciences Institute）の Jon Postel をネットワーク番号割り当ての連絡先として特定した。
このリストは、割り当て番号環境が ARPANET ホストのリストを超えて拡張されたことを証明している。しかし、それだけでは、すべての名前付きネットワークがその時点で運用上相互接続されていたこと、政府のスポンサーシップから独立していたこと、商用、非 DoD であったこと、または SRI のホストテーブルプロセスによって統治されていたことを立証するものではない。割り当て文書に表示される番号は、ネットワークの契約ステータスや実際のトラフィックの完全な説明ではない。
これにより、後の歴史がしばしば曖昧にする機能も分離される。USC-ISI での Postel の割り当て番号の役割は、ネットワークとプロトコルパラメータに関係していた。SRI はホストテーブルとネームサービスを維持した。DCA は ARPANET を管理し、NIC サービスを委託した。DARPA は引き続き研究スポンサーシップを行った。これらの事実のいずれも、1 つのアクターを出現しつつあるインターネット全体の唯一の著者にするものではない。
したがって、「最初のインターネット台帳」という表現には定義された比較が必要である。ホストテーブルは、コンピュータ組織によって維持された最初のディレクトリでもなければ、1974 年のファイルは世界的な公共インターネットのための登録簿でもなかった。それは、ARPANET からインターネットへの系譜における、初期の共有された機械可読な名前とアドレスの参照であった。1982 年までに、その後継形式はネットワーク、ゲートウェイ、インターネットアドレスを組み込み、そのオペレーターによってグローバルなホスト名とアドレスのデータベースと説明された。その歴史的重要性は、その参照の範囲の拡大と組織間の依存性にあり、すべてのネットワークに対する証明された権限にあるのではない。
1982 年の DoD ルール：公表された前提条件であり、強制の証明ではない
RFC 810 は、範囲と制度的言語の変化を示した。1982 年 3 月 1 日に、SRI International の Network Information Center の Feinler、Ken Harrenstien、Zaw-Sing Su、Vic White によって発行されたこの RFC は、以前の ARPANET ホストテーブルが DoD コミュニティやインターネットワーキングのニーズをもはや満たしていないと述べた。新しい形式には、ネットワーク、ゲートウェイ、ホストのエントリ、インターネットアドレス、オペレーティングシステム、プロトコル情報が含まれていた。
テーブルは、FTP および Host Name Server を通じてSRI-NICホストから利用可能であった。RFC はサーバーを、DCA に代わって ARPANET NIC によって維持されるサービスとして特定した。また、翻訳の責任を明示的にユーザーに割り当てた。テーブルを消費する者は誰でも、それをローカルで必要な形式に変換しなければならなかった。
7 番目の前提条件は、ホストテーブル記録の中で最も強力な運営言語を含んでいた。DoD ネットワーク、ゲートウェイ、ホストの名前とアドレスは、使用される前に、そして DoD ホストによってトラフィックが渡される前に、NIC と交渉され登録されなければならなかった。これは、DoD ホストの動作を統治する公表された前提条件であった。これは 1974 年の公式ホスト名の使用を奨励するものよりも、登録を運用に直接結びつけていた。
この文は強制を文書化していない。RFC 810 は、登録を検査するモニター、登録されていないトラフィックを拒否するルータールール、違反に対する制裁、遵守率、または遮断された特定の通信を特定していない。この違いは重要である。仕様は、オペレーターがどれだけ一貫してそれを実装したかを証明することなく、要求される行為を定義できる。
この文書は、非 DoD 情報を異なる方法で扱った。暫定期間中、NIC は、提供された場合、および相互通信するネームサーバーが整うまでの間必要な限り、非 DoD ネットワークおよびホストについて同様の情報を維持しようと試みることになっていた。この文書は、実際に含まれたすべての非 DoD エントリを特定しておらず、すべての外部オペレーターに同じ明示的な前提条件を課してもいなかった。
新しい形式はまた、段階的な導入があった。RFC 810 は、1982 年 5 月 1 日を切り替え日として指定した。5 月中は、既存のHOSTS.TXTパスが依然として旧版を保持し、新しい形式のテストファイルが別途利用可能であった。6 月と 7 月の間、メインパスは新しい形式を保持し、旧形式の資料は別のパスを通じて引き続きアクセス可能であった。8 月 1 日以降、RFC 608 で指定された古いHOSTS.TXT形式はもはやサポートされなくなった。
この重複は、公表された設計を即時の普遍的な実装から区別した。プログラムは適応する時間があった。移行期間中、ローカルシステムは異なる版のままである可能性があった。スケジュールは互換性リスクの積極的な管理を示しているが、すべてのホストが時間通りに変換を完了したことを証明するものではない。
RFC 811は同じ日に発行され、オンラインの Hostnames Server を指定した。プログラムはホスト名またはアドレスを問い合わせるか、テーブル全体を要求することができた。サーバーはホスト、ゲートウェイ、またはネットワークレコードを返すことができた。要求された名前がない場合、定義されたエラーはERR: NAMNFD: Name not found:という形式をとった。他のエラーも可能であり、TMPSYSは一時的なシステム障害を意味し、後で再試行するよう要求した。
これらの意味論は SRI-NIC サーバープロトコルに属する。これらを、ダウンロードされたコピーを使用するすべてのローカルリゾルバに投影すべきではない。エントリを欠くローカルコピーに対するローカルルックアップは、失敗するか、補足マッピングを使用するか、ユーザーに促すか、または他のシステム依存の方法で動作する可能性がある。名前がローカルコピーに存在しないことと、サーバーからのNAMNFD応答は関連する状態であるが、必ずしも同一のイベントではない。
RFC 811 は、そのデータベースを古い ARPANET のHOSTS.TXTファイルの拡張であり、分散化された名前とアドレスの変換サービスへの道程における暫定的な解決策であると説明した。その制度的な主張は 2 つの理由で重要である。SRI がサービスを恒久的なアーキテクチャではなく移行メカニズムとして理解していたことを示し、テーブルの人口と目的が元の ARPANET リストを超えて拡大していたことを確認している。しかし、普遍的なカバレッジを独立して証明するものではない。
1980 年代初頭までに、NIC はますます Defense Data Network 環境と関連付けられ、歴史的コレクションは後にサービスのために DDN-NIC という名前を使用している。その後のラベルを 1969 年の契約や 1971 年のホスト名論争に遡及させるべきではない。SRI-ARC、SRI NIC、SRI-NIC、DDN-NIC は、関連するが時間的に異なる組織的およびホストの文脈を記述している。
アーカイブが示しうるもの、そして未だ欠けているもの
RFC シリーズは、提案、仕様、発表において異常に豊富である。個々の管理事例の記録としてははるかに弱い。
Computer History Museum のファインディングエイドは、関連するコレクションを特定している。NIC の提案と契約、進捗報告書、命名とアドレス指定の記録、ホストテーブル、参照サービス資料、通信、および公式ネットワーク連絡先に関する記録である。初期の NIC 契約はタスクに分解されておらず、後の契約はより精巧になったと述べている。また、技術連絡担当者、Host Administrators、Node Site Coordinators、および情報やアクションメッセージが流れる他の連絡先について説明している。
ファインディングエイドは、記録の存在、おおよその主題、配置を確立する。すべての契約、手紙、決定の内容を開示するものではない。その説明は、ホスト名の要求が特定の方法で許可、拒否、またはエスカレーションされたことを証明できない。基礎となる文書を開いて比較する必要がある。
ここでは、ホストの提案された名前、NIC の質問、サイトの応答、最終的な処分を示す完全な要求ファイルは提示されていない。重複に基づく NIC の拒否、成功した上訴、スポンサーの上書き、または修正救済策を示す保存された事例はない。包括的な登録簿は処理時間やエラー率を提供していない。RFC 627 の連絡先詳細は修正チャネルが存在したことを証明するが、それを通じて提供された結果を証明するものではない。
欠落している契約は別の理由で重要である。連邦契約は、すべての記録の所有権、技術システムに対する権利、または請負業者が作成したデータに関する無制限の権利を付与することなく、履行に対する権利を付与できる。成果物、データライセンス、移行支援、救済策を指定するかもしれないが、これらの結果は実際の条項に依存する。
はるか後のGovernment Accountability Office の連邦インターネット機能の配置に関する分析は、履行権、データ使用権、権利、所有権を慎重に区別した。その 2016 年の意見は、後の DNS と IANA の配置に関するものであり、SRI の 1970 年代の契約の欠落している条件を提供するものではない。ここでのその価値は方法論的である。連邦の資金提供だけでは、すべての財産権や移行権を推論するために使用できない。
Completion Report は、1 つのより狭い結論を支持している。DCA は当初 NIC 機能のために SRI を保持する意図があり、後で別の請負業者を使用することができた。これは、想定されたプロバイダの置き換え可能性を示している。しかし、遅延、データ紛争、ソフトウェア変換、失われた制度的記憶、またはサービス中断なしに置き換えが起こり得ることを立証していない。
RFC 810 のトラフィック条件についても実装記録は存在しない。公表されたルールから実証された強制に移行するには、DCA 指令、ホストソフトウェア、監査ログ、インシデントレポート、制裁、または文書化された遮断されたフローが必要である。そのような資料がなければ、記事はルールの述べられた範囲を特定できるが、その観察された力を特定できない。
沈黙は両方向に作用しなければならない。公表された上訴手続きの欠如は、非公式のエスカレーションが存在しなかったことを証明しない。電話、ネットワークメール、NLS のやり取り、スポンサー介入が RFC なしで紛争を解決した可能性がある。逆に、公表された苦情の欠如は、すべての参加者がプロセスを正当と見なしたか、すべての更新がタイムリーであったことを証明しない。
結果として生じる不確実性は、単に好古的であるだけでなく、制度的なものである。要求が透明なサイト確認を通じてルーチンに修正された場合、サービスはより事務的で協調的に見えるだろう。NIC が説明なしにエントリを拒否でき、スポンサーレビューが存在しなかった場合、同じファイルは異なるガバナンスの意味を持つことになる。公的証拠は、一般的な説明としていずれの極端も支持していない。
ローカルリストの代替案とその現実のコスト
共通ファイルに対する歴史的に実行可能な代替案は、現代のドメインネームシステムではなかった。それは RFC 606 以前に既に見られた慣行、すなわち各サイトが独自のマッピングを維持し、個人的なコミュニケーションを通じて変更を入手し、リモート情報を自身のオペレーティングシステムに翻訳することであった。
4 つのサイトでは、これは管理可能であり得た。管理者は互いを知っており、プロトコル設計者は定期的に会合し、修正は電話、文書、またはネットワークメールで伝わる可能性があった。サイトは中央の出版物を待たずにローカルエイリアスを採用できた。2 つの組織が頻繁に通信する場合、中央マシンが利用できなくても共有情報を最新に保つことができた。
保守負荷は急速に増大した。10 サイトで、各々が他の 9 つのエントリを維持すると、最大 90 の有向ローカルマッピングがあり得た。100 サイトでは、最大 9,900 の有向マッピングがあり得た。これらの数値は、各サイトが保持する有向コピーを表しており、90 または 9,900 の個別の二者関係ではない。実際に必要とされるマッピングの数は通信パターンに依存するが、新しい宛先ごとに情報が古くなる可能性のある場所が増えた。
ホストの追加やアドレス変更は複数の管理者に伝える必要があった。それぞれが別々のスケジュールで、異なるローカル形式で適用するだろう。修正はあるサイトでは確認されるが、別のサイトでは見逃され、第三のサイトでは不正確に変換される可能性がある。オペレーターは、自分がどの版を持っているかを特定し、競合する報告を比較し、明らかなサービス障害がネットワーク、リモートホスト、または古いマッピングに由来するかどうかを判断する必要があるだろう。
RFC 606 は、観察された警告を提供している。4 つの名前付き TENEX システムは既に不完全で分岐したテーブルを持っていた。それらの違いによって引き起こされた障害の定量化はしていない。分岐自体が、複製された保守と一貫しない回答を示している。
共通ソースはその負荷を軽減した。影響を受けるホストは、認識された 1 つのチャネルを通じて情報を伝達できた。SRI は 1 つの版を生成できた。各サイトは同じファイルを取得し、日付付き参照とローカル状態を比較できた。不一致を調査するサポートオペレーターは、そこから開始する焦点を持っていた。
共通ファイルはすべての配布コストを排除したわけではない。各サイトは依然としてストレージ、取得ソフトウェア、ローカル変換、更新ルーチンを必要とした。毎週の公開は、報告された変更と次の版への掲載との間に遅延をもたらした。提供ホストまたはネットワークパスが利用できない場合、取得は失敗する可能性があった。ローカルインストールは、取得成功後も遅れる可能性があった。このアーキテクチャはコンパイルを集中化したが、すべての運用タスクを集中化したわけではない。
また、1 つの共通ソースが真実を保証したわけでもなかった。SRI は正確な情報を提供するためにホストと連絡先に依存していた。サイトから提供された誤ったアドレスがマスターに入り込む可能性があった。正しい中央更新が古いローカル展開によって損なわれる可能性があった。それを決定する手続きが不明確な場合、競合が持続する可能性があった。参照は不一致を可視化し、重複を減らしたが、検証の必要性を廃止したわけではなかった。
ローカルリストの代替案は、組織が無制限の命令の理論を必要とせずに NIC ファイルに従った理由を説明する。1 つの維持された答えは、多くの独立して再構成されたものよりも消費するのが安価であった。ソフトウェアと文書は、共通の名前を使用する場合により信頼性が高くなった。結果として生じる依存は、維持された記録に運用上の力を与えた。
複数の配布者を持つ共通台帳
第二の時代に実行可能な代替案は、1 つの正規ファイルを保持しながら、ストレージと取得をより広く分散させることであったろう。
このアイデアは同時代の文書に現れた。RFC 623は、NIC がマスターを保持し、別のホストが頻繁に更新されるセカンダリコピーを維持することを提案した。その著者は UCSB を志願し、毎日の同期を提案した。目的は可用性であった。NIC ホストがファイルを提供できない場合、ユーザーはセカンダリを試すことができた。
RFC 625は、1 つ以上のホストがコピーを維持すべきであるという原則を受け入れ、UCSB を将来のセカンダリとして歓迎した。FTP を専用の取得プロトコルに置き換えることには反対した。RFC 627 は、3 月後半に発行され、依然としてセカンダリコピーを維持したいホストは NIC に連絡するよう呼びかけた。
これらの記録は、提案され受け入れられた複製設計を確立している。UCSB または別のホストが機能するミラーを運用したことを証明するものではない。確認には、運用通知、サーバーログ、アーカイブされたセカンダリファイル、ホストマニュアル、または後の報告書が必要である。提案は配備として書き換えられるべきではない。
そのようなセカンダリが運用されていた場合、時代に適したリソースが必要だったであろう。サイトはファイル用のストレージ、更新を取得するためのスタッフまたは自動化された手順、およびその版を有用に保つのに十分な頻度のスケジュールを必要とした。ユーザーはどのホストに連絡するか、最新の正規版をどのように認識するかを知る必要があった。セカンダリは、そのローカルコピーが SRI のものと異なる場合に何をすべきかのルールを必要とした。
停止は調整を困難にする可能性があった。セカンダリが SRI は利用可能なまま 2 つの更新を逃し、その後古い版で戻った場合を想定する。ユーザーが可用性を通貨と誤解するのを防ぐために、タイムスタンプやシーケンスの慣行が必要になるだろう。争われている修正が到着したときに SRI が利用できなかった場合、セカンダリは変更を公開できるか、単に最後に確認されたマスターを提供し続けるかを知る必要があるだろう。
複製はまた、修正権限を未解決のままにした。ミラーはエントリを決定することなく正規ファイルを配布できる。それに独立した編集権を与えると、競合するマスターの可能性が生まれるだろう。その問題を回避するには、自らの事実を証明する組織、共有名前空間を調整するセンター、コピーを提供する配布者、紛争を処理するレビュー担当者の間で明確な分割が必要である。
サイト確認は、現代のインフラがなくても強化できたかもしれない。毎週の公開前に、NIC は提案された変更を影響を受ける連絡担当者または権限のあるサイト連絡先に送ることができた。日付付きの変更通知が生成されたファイルに添付される可能性があった。セカンダリキーパーは、発表された変更を自分たちが受け取ったファイルと比較できた。サイトは、日付のないローカルコピーではなく、特定の版に対して不一致を報告できた。
これらの手順はコストを課しただろう。連絡先は応答しなければならなかった。修正は確認を待つ可能性があった。スタッフはログを維持し、未回答の要求を調整しなければならなかった。急速に変更するホストは、毎週のサイクルが遅すぎると感じるかもしれないし、より頻繁な配布は計算、ネットワーク使用、オペレーターの作業負荷を増加させる。正式なレビューは、緊急の修正を遅らせる一方で、説明責任を改善する可能性がある。
請負業者の移行はより大きな問題を提示した。DCA の別のプロバイダを選択する能力は、SRI のシームレスな置き換えを保証しなかった。後継者は、現在の正規ファイル、それを生成するソフトウェア、形式と公開スケジュールの文書、未解決の要求、修正履歴、連絡先リスト、スタッフの知識、および提供環境へのアクセスを必要とした。契約が成果物またはデータ使用権を指定しなかった場合、移行は法的にも運用的にも困難になる可能性がある。
現存する公開文書は、これらの移行資料が強制可能な成果物として存在したかどうかを立証していない。それらは、別の請負業者が想定されていたことを示しているが、テスト済みの移行メカニズムが整っていたことを示していない。紙面上の置き換え可能性と運用上の継続性は別個の達成事項であった。
この代替案はガバナンスの選択を明確にする。単一の論理的答えは、単一の物理的配布者を必要としなかった。正規版は、ミラー、サイト確認、保存された変更、交換可能なサービスプロバイダと共存できた。それぞれの追加は、最終的な調整の必要性を排除することなく、コストと責任をシフトさせたであろう。
日付付き権限の連鎖であり、普遍的な権限ではない
1969 年から 1983 年の間、ホストテーブルの権限は一連の異なる関係を通じて蓄積された。
1969 年、ARPA は ARPANET のために Network Information Center を調達した。これにより、連邦顧客、SRI 請負業者、および定義されたサービス集団が確立された。これは SRI をすべてのコンピュータネットワークの代表にしたわけではない。
1971 年、ホストは公表された慣行の範囲内で連絡担当者を通じて名前を選択するよう招かれた。ARPANET 参加者間の議論と応答は、限定的なピア受け入れを提供した。NIC の提案された役割はローカル選択によって狭められたが、共有名前空間は依然として互換性のある結果を必要とした。
1973 年と 1974 年初頭、分岐したローカルテーブルが機械可読な共通ファイルを促した。RFC 606 と 608 は提案とソース設計を文書化した。RFC 620 と 627 は、特定のサイト全体の変更指示、利用可能な ASCII ファイル、毎週の更新、ローカル取得責任、修正チャネルを文書化した。それらは一般的な NIC の拒否権や完全な紛争システムを文書化しなかった。
1975 年 7 月 1 日、Completion Report に記述された ARPA-DCA 覚書によると、ARPANET の管理は DCA に移管され、12 月 31 日までの段階的移行が続いた。DCA は当初 NIC 機能のために SRI を保持し、別の請負業者を検討することができた。ファインディングエイドの矛盾する 1973 年の運用移管声明と 1974 年以降の資金提供に関する説明は未解決のままである。
1978 年までに、DCA の加入者枠組みは、ARPANET 参加を SRI のホストテーブル保守ではなく政府のネットワーク管理内に置いた。これにより、加入者を承認する権限と、ホスト情報を記録し配布するサービスが分離された。
1981 年までに、割り当て番号環境は ARPANET を超えた多くのネットワークをリストし、ネットワーク番号割り当ては USC-ISI の Postel と特定されていた。そのリストへの掲載は、すべてのネットワークが DCA や NIC と 1 つの法的または運用的関係を共有していることを立証しなかった。
1982 年 3 月、RFC 810 はより広範な DoD インターネットホストテーブルを指定し、DoD ホストが渡すトラフィックに関連して使用される名前とアドレスについて、使用前の登録を条件として公表した。非 DoD 情報の別個の暫定的取り扱いは境界を示した。ルールは明示的であったが、その強制は未証明のままである。5 月から 8 月の切り替えは、仕様、移行、完了したローカル実装が異なる段階であることをさらに示した。
RFC 811 のサーバーは、維持された答えをオンラインクエリを通じて利用可能にし、中央データベースを分散ネーミングへの中間的な橋渡しと説明した。このサービスは SRI-NIC への依存を増大させたが、アーキテクチャが恒久的に中央に留まることを意図していないことを認めた。
したがって、ホストテーブルは 3 つの場所で最も強力に実証された権限を行使した。SRI は、完全な条件が入手できない契約の範囲内で、連邦顧客に対して履行義務を負った。DCA は、自身が管理する DoD 環境に対して運用要件を発行できた。参加するマシンとユーザーは、一貫した名前ベースの通信のために共通記録に依存した。
これらの関係の外では、テーブルの到達範囲は相互運用性と採用から生じた。外部ネットワークは、通信を容易にするために情報を提供したり共通ファイルを使用したりするかもしれない。その依存は重要であったが、RFC 810 はそれを DoD の前提条件と同等とは説明しなかった。検討された記録は、世界中の構成員が SRI に一般的な権限を委任したことを示していない。
テーブルはまた、それが記録したすべてを創り出したわけでもなかった。スポンサーはネットワーク参加を承認し、請負業者とサイトはマシンとソフトウェアを提供し、回線とパケットスイッチがトラフィックを運び、他の当局がネットワーク番号を処理し、ローカルシステムが公開されたマッピングを消費した。NIC の記録は名前を一般的に認識可能にするのに役立ったが、基盤となる組織、物理的接続、またはすべての数値割り当てを創り出したわけではなかった。
その実質的な権限はそれにもかかわらず相当なものであった。多数のマシンによって消費される共有記録は、立法府や公的会員組織がそれを創設しなくても、行動を制約することができる。予測可能な認識を望むホストは、命名慣習に従う理由があった。最新の回答を望むサイトは、共通ファイルを取得する理由があった。DoD ホストは、公表された登録前提条件によって対処された。非 DoD オペレーターは、他のシステムが維持された答えを期待するため、逸脱がコスト高になると感じることができた。
未証明のままであることも同様に重要である。現存する公開証拠は、NIC がリストしたアドレスを所有していたこと、任意の外部ネットワークを自由に排除できたこと、すべての非準拠サイトに制裁を課したこと、またはすべての欠落エントリを物理的切断に変換したことを示していない。完全な上訴構造、修正救済策、上書き階層を明らかにしていない。すべての NIC データの移植可能な政府所有権を確立していない。
初期のホストテーブルは、調達、ネットワーク管理、機械依存が出会う場所で権威的であった。それは具体的な問題を解決した。互換性のないローカルマッピングが共有名を信頼できなくしたのである。中央コンパイルは、1 つの答えを配布、比較、使用しやすくした。その達成が、名前とアドレスが市場資産になる前に、記録が力を獲得した理由を説明している。
それは、記録のオペレーターが、記録が記述できるすべてのネットワークに対する権限を受け取ったことを証明しない。歴史的な連鎖は、より狭い結論を支持する。SRI は、スポンサー付きネットワークのために連邦政府が委託した参照を維持し、その参照は DoD インターネット運用に埋め込まれ、より広範な依存がその実用的な到達範囲を拡大した。台帳の有用性がそれを強力にした。その公的権限は未確立のままであった。