RFC 790 とアドレスリストに隠された政治

概要

• RFC 790 は、いくつかの番号系列が現在の運用参照として維持されており、開発者は割り当てを受けるために Jon Postel に連絡するよう指示されていることを直接確立しているが、一般的なネットワーク適格性ルールや割り当て権限の分担については何も公表していない。
• RFC 820 は、研究、防衛、商用のカテゴリを追加し、ネットワーク番号空間の推奨配分、研究申請者向けのゲートウェイ準備条件の提案、機関間の責任分担の見通しを提示している。
• RFC 820 はまた、その勧告がまだ完全には実施されておらず、Postel が依然としてすべての割り当てを調整していると述べており、合意、提案されたポリシー、および実務慣行を同じ制度上の状態として扱うことはできない。
• 公開された表からは、申請者の母集団ではなく、割り当て、移行、内部的な不整合が明らかになる。リクエスト、拒否、撤回、使用状況、および当時の通信記録がなければ、申請者の扱い、分配の動機、または意思決定を隠蔽する意図を立証することはできない。

RFC 790（1981 年 9 月付）の最初のページと、RFC 820の検討テキストの対応する段落を比較する。RFC 790 の導入段落では、現在の情報は Jon Postel から入手できるとし、「番号の割り当ても Jon が担当する」と付け加えている。検討対象の RFC 820 テキストの同じ段落では、個人の文法を保持しつつも、「これらの割り当ては、付録 A に文書化された DARPA/IPTO と DDN/PMO 間の合意に従い、同じコーディネーターが担当する」という但し書きが挿入されている。

追加された条項は、数字の列が支配的な文書の中では小さく見えるかもしれない。付録 A は小さくない。そこには 1982 年 9 月の会合で達した合意が報告されており、ネットワーク番号空間を研究開発、国防総省、商用利用に分割すること、将来の制度的責任を指定すること、研究ネットワーク向けの適格性条件を提案すること、そして最後に、この取り決めはまだ完全には実施されていないことを認めている。

この並置は正確な問いを投げかける。後の文書は、以前の目録では見えなかった権限を暴露したのか？それは新しい割り当てポリシーを発表したのか、実務で既に進行中の取り決めを文書化したのか、異なるネットワークアーキテクチャへの移行を管理したのか、あるいは単に常に調整を必要としてきた作業についてより完全な編集上の説明を提供しただけなのか？これらのページでは、その可能性のいくつかを検証することはできるが、レイアウトだけから選択を行うことはできない。

したがって、これは技術的な表が密かにインターネットを立法したという主張ではない。あるエントリが共有された運用記録の一部となる前に、何が起こらなければならなかったのかを問う調査である。答えは番号系列によって異なる。未使用のプロトコルコードを選択することは、ネットワークをどのクラスと管理カテゴリに含めるかを決定することと同じ操作ではない。ポートを記録することは、実験ネットワークが運用可能になったかどうかを決定することと同等ではない。連絡先を公開しても、申請者、裁定者、受益者は特定されない。中心的な課題は、文書がどのような制度的前提を支持しているかを問う前に、これらの機能を分離することである。

2 つの成果物、1 つのカタログの不一致

RFC 790 は、南カリフォルニア大学情報科学研究所の J. Postel による、1981 年 9 月付の 15 ページのネットワークワーキンググループ文書である。この文書は、ネットワークプロトコルの実装で使用されるいくつかの系列から、現在割り当てられている値を記録したものであると述べている。リンク、ソケット、ポート、プロトコル、またはネットワーク番号が必要な開発者は、割り当てを受けるために Postel に連絡するよう指示されている。

この文書は、割り当てられたネットワーク番号、インターネットバージョン番号、インターネットプロトコル番号、ポートまたはソケット番号、ARPANET リンク番号と続く。参考文献と責任者のディレクトリがそれに続く。項目の横にある括弧付きのコードは、文書または連絡先を指している。この形式は少なくとも 3 つの直接的な目的を果たす：数値の衝突を避けること、実装者に値が何を意味するかを伝えること、そして簡潔な行が不十分な場合に連絡先を提供することである。

RFC 790 はまた、定期的に更新されることを宣言している。この約束は、そのステータスにとって基本的なものである。それは最終的な言葉として残るように設計されていなかった。以前の Assigned Numbers 文書を置き換えたものであり、それ自体が後に置き換えられるものである。「現在の」ものとしての主張は、特定の運用上の瞬間に関するものであり、恒久的な権威や不変の歴史的真実ではない。

ネットワーク番号のセクションは 2 ページから 4 ページを占めている。3 つのアドレスクラスを説明し、それらのビットレイアウトを示している。クラス A は先頭のゼロ、7 ビットのネットワーク番号、24 ビットのローカルフィールドを使用する。クラス B は上位パターン10、14 ビットのネットワーク番号、16 ビットのローカルフィールドを使用する。クラス C は110、21 ビットのネットワーク番号、8 ビットのローカルフィールドを使用する。これらは根本的に異なる容量を持つ技術的カテゴリであるが、異なる容量の存在だけでは、申請がどのように評価されたか、または節約が割り当ての理由だったかどうかを立証することはできない。

名前付きのクラス A の行は、混合された不完全なスナップショットを形成している。それらには、研究ネットワーク、パケット無線実験、軍事施設、公衆データネットワーク、大学、請負業者、およびいくつかの国の商用事業者が含まれている。この表は、これらのエントリが出現した母集団を特定していない。識別子を望んだネットワークのセンサス、申請者のリスト、または公開された割り当てにつながらなかった申請の記録ではない。

検討対象の RFC 820 の成果物は、22 ページとより長い。テキストのヘッダーには J. Postel と J. Vernon と表示され、1983 年 1 月となっている。現在のRFC エディターカタログエントリでは、RFC 820 を「Assigned numbers, August 1982」とラベル付けし、J. Postel のみをリストしている。この分析では、検討テキストのヘッダーとページ番号によって節を特定しつつ、カタログの不一致を保持する。入手可能な情報源は、一方の日付と著者の慣習を他方の訂正として黙って採用することを正当化しない。

RFC 820 は以前の目録機能を保持しているが、その範囲を拡大している。ARPANET 環境から ARPA インターネットへの移行に言及し、自律システム番号を追加し、イーサネット番号や公衆データネットワークマッピングを含め、ネットワーク表を大幅に拡大している。ここで最も重要なのは、1 ページ目で番号割り当てを DARPA/IPTO–DDN/PMO 合意に従属させていること、そして 19～22 ページでその結果としての勧告と実施ノートを掲載していることである。

両方の RFC は現在、レガシーストリームの「歴史的」に分類されている。RFC 790 は RFC 820 によって廃止され、RFC 820 は RFC 870 によって廃止された。これらの現在の分類は、使用時に文書が無効または無関係だったことを意味しない。定期的に発行されるレジストリ出版物は、割り当てや慣行が変化するために時代遅れになる。後の廃止はそのドキュメンタリーライフサイクルの一部であり、以前のスナップショットの遡及的な取り消しではない。

後の比較が限界を定義するのに役立つ。RFC 943（1985 年 4 月発行）は、ARPA インターネットコミュニティのプロトコルで使用される番号の公式ステータスレポートであると明示的に説明している。また、ARPA または DDN インターネットに接続されたネットワークと、インターネットプロトコルを使用する独立ネットワークを区別している。この後の明確化を RFC 790 に輸入することはできない。それは言語と分類装置が発展し続けたことを示している。

2 つの主要な成果物の決定的な違いは、それぞれの違いに一つの原因があると偽ることなく、以下のように要約できる：

この比較は文書の変化を確立する。次の問いは、それぞれの言葉と表がどのような管理を必要としたかである。

「Assigned」、「registered」、「current」、「official」は同義ではなかった

RFC 790 の冒頭の指示は、開発者が自己選択した値を報告するよう招く以上のことをしている。それは「番号の割り当てを受けるために」Postel に連絡するよう言っている。新しい値が安全に共有リストに現れるためには、誰かがリクエストを知り、衝突をチェックし、値を選択または確認し、結果を伝え、記録を更新する必要があった。その最低限のシーケンスは調整された管理である。

すべての系列が同じように重大な決定を伴ったわけではない。多くのプロトコルまたはポートのリクエストでは、基本的な行為は未使用のコードポイントを見つけ、相互運用性を維持することだったかもしれない。このテキストは、すべての開発者の組織的メリットが評価されたと主張する根拠を提供しない。「割り当て」という言葉は操作を示すが、その存在だけで背後にある基準や判断の深さは明らかにならない。

ネットワーク番号は異なる。なぜなら RFC 820 はそれらを管理利用カテゴリと推奨適格性条件に結び付けているからだ。付録 A は、研究開発コミュニティ内では、標準 BBN ゲートウェイソフトウェアを取得中である証拠、または Exterior Gateway Protocol 要件を満たすゲートウェイを実装もしくは取得中である証拠を示す申請者にのみネットワーク識別子が付与されると述べている。さらに、Berkeley BSD 4.2 UNIX ソフトウェアを取得していることが後者の証拠とみなされるかもしれないと付け加えている。

この文言は単なる一意性チェックよりも強い。技術的準備の証拠に推奨される付与を条件付けている。しかし、それは推奨されるポリシーの一部であり、すでに普遍的な運営ルールであることの証明ではない。付録は完全な証拠基準、判断方法、上訴プロセス、または条件の下で評価された申請の記録を指定していない。最終ページでは、勧告はまだ完全には実施されていないと明示的に述べている。

「Current」は別の機能を果たす。両文書とも現在割り当てられている値を記述していると主張し、現在の情報を入手できる場所を読者に伝えている。この設定では、現在性は同期に関する主張である：実装者は、互換性のないプライベートリストに頼るのではなく、維持されたリファレンスを参照できるべきである。それは各エントリの元々の根拠、制度的経緯、または現在の保有者が完全に文書化されていることを意味しない。

RFC 820 は自律システムセクションで「registered」を使用している。Exterior Gateway Protocol は自律システムを識別する 16 ビットのフィールドを提供し、その値は文書に登録されている。初期の表はほぼ空である：ゼロは予約、1 は BBN ゲートウェイを識別し、2 から 65,534 までは未割り当て、65,535 は予約である。ここでの登録は、ある識別子系列の初期段階での共通記録を説明している。それをネットワーク付録に無差別に適用することはできず、そこでは分類と推奨される申請者証拠が異なる考慮事項を加える。

「Official」は RFC 943 で明確になるが、RFC 790 や RFC 820 の冒頭のステータス文言ではない。その後の定式化は、ARPA インターネットコミュニティ内での認識を表している。それは、リスト維持の以前の行為すべてを正式な政府決定と同等にするものではなく、また、レポートが運用されたコミュニティの外でエントリが同じ重要性を持っていたことを立証するものでもない。

したがって、これらの言葉は重複するが分離可能な機能を識別する。割り当ては選択または確認を含むことができる。登録は値を記録する。現在性は維持を表現する。公式ステータスは定義された運用コミュニティでの認識された地位を特定する。Assigned Numbers の系譜におけるそれらの近接性は、それらを一つの普遍的な権威に統合するものではない。

1 つの出版物は複数の異なるレジストリを含んでいた

「Assigned Numbers」というタイトルは複数の系列を一つの文書に集めているが、それらの衝突問題と制度的利害は交換可能ではなかった。

インターネットプロトコル番号は IP ヘッダの 8 ビットフィールドを占め、パケットが運ぶ次のレベルのプロトコルを識別した。その番号を調整することで、異なる実装がフィールドを一貫して解釈できるようになった。RFC 820 の付録 A は、DoD 標準、研究用途、商用、国内、国際標準のためにプロトコル番号空間の一部を予約することを提案した。これはプロトコル識別子に関する調整であり、組織へのホストアドレス容量の割り当てではない。

ポート番号は論理接続の終端にあるサービスコンタクトポイントを識別した。RFC 790 はまだ AHHP ソケットと TCP ポートの両方を議論していたが、RFC 820 は TCP を中心とし、可能な限り UDP と再利用するポートリストを提示した。よく知られたポートを割り当てることで、サービスは実装間で相互運用可能になった。それは名前付きのプロトコル作成者やサービス連絡先をネットワークブロックの保有者にしなかった。

ネットワーク番号は異なる役割を果たした。それらはインターネットアドレッシングアーキテクチャにおいてネットワークを識別した。選択されたクラスはローカルアドレスフィールドの幅を決定した：クラス A は 24 ビット、クラス B は 16 ビット、クラス C は 8 ビットである。したがって、ネットワーク割り当ては単なるラベルとしてだけでなく、アドレス容量とルーティング処理においても異なった。RFC 820 のカテゴリコード、移行マーク、ゲートウェイ準備の推奨は、このより制度的に差別化された操作に適用された。

自律システム番号は別の異なる系列だった。それらの目的は、Exterior Gateway Protocol のためにゲートウェイのグループを識別することだった。RFC 820 でのそれらの登場は、ドメイン間調整の初期の開発を記録しているが、ネットワーク番号適格性の一般原則を提供するものではない。

ARPANET リンク番号は Host/IMP インターフェース環境に属していた。RFC 820 の付録は不要な使用を排除し、インターフェース間の相互運用性の問題を研究することを推奨した。そのタスクは別のプロトコルフィールドと別の運用依存関係に関わっていた。

名前登録は、ポートテーブルが名前関連のサービスを含んでいることだけを理由に推測されるべきではない。RFC 790 はポート 42 をネームサーバに、ポート 43 を Whois に割り当てている。RFC 820 はそれらのサービス連絡先を含み、ホスト名またはメールボックスネームサーバのポートを追加している。これらはサービスに到達するためのエントリであり、ホスト名やドメインのレジストリではない。人々のセクションも同様に責任者のディレクトリであり、名前レジストリや申請者台帳ではない。

Computer History Museum の SRI ARC/NIC レコードのファインディングエイドは、制度的区別を強化する。これは、SRI ネットワークインフォメーションセンターによる ARPANET ホストテーブルの維持と、その後の命名の移行を別の活動として説明している。また、Assigned Numbers とグローバルアドレス割り当ての管理が、1987 年に USC-ISI から SRI NIC 契約に移管されたと述べている。このファインディングエイドは後のアーカイブの文脈であり、SRI が 2 つの RFC に記述された 1981 年から 1983 年の割り当て機能を運用した証拠ではない。

一つのリファレンス出版物に系列をまとめることは運用上理にかなっていた。開発者は関連する定数や連絡先を一箇所で見つけることができた。しかし、共通のフォーマットは、リストされたすべての番号を同じ種類の付与にするものではない。ネットワーク番号付録から導き出されるガバナンスの結論は、別のセクションがそれ自身の証拠を提供しない限り、その付録に固着したままでなければならない。

管理カテゴリは技術クラスを置き換えなかった

RFC 820 は 2 つの異なる分類を重ねている。1 つ目はアーキテクチャ上のものである：クラス A、B、C はアドレス形式を定義する。2 つ目は管理上のものである：R,D,Cは研究開発、DoD、商用利用を識別する。これらを混同すると誤った比較を生む。

2 ページで、検討テキストの RFC 820 はクラス A の先頭ビットがゼロであること、クラス B の先頭パターンが10であることを正しく説明している。その散文はクラス C の上位 3 ビットを1-0-0と記述しているが、隣接する図は1 1 0を示しており、そのクラス C の範囲は 192 で始まり、その上位ビットは110である。RFC 790 もクラス C のパターンを110と印刷している。したがって、RFC 820 の1-0-0というフレーズは内部的なテキストエラーであり、異なるアドレスアーキテクチャの証拠ではない。

3 つの技術クラスは、予約されたエンドポイントや他の除外を除いて、それぞれ 128、16,384、2,097,152 の可能なネットワーク番号値を含んでいた。それらのローカルフィールドは、ネットワークごとに(2^{24})、(2^{16})、(2^8)の数値アドレス値を含んでいた。これらの違いはクラスの選択を重大なものにしたが、どちらの RFC もリストされたネットワークのホスト利用率を提供していない。

管理コードは別の質問に答える：文書が割り当てられた識別子に関連付けた利用カテゴリはどれか。研究コードは小規模または大規模なクラスを意味するものではない。商用組織が研究プロジェクトに参加することもあり、請負業者のネットワークは組織の法的性格ではなく、ネットワークの利用によって分類される可能性がある。連絡先の雇用者、ネットワークの説明、カテゴリコードは交換可能な証拠として扱うことはできない。

付録 A は、利用可能なクラス空間を 3 つの利用に分割することを推奨している。クラス A では、8 ネットワークを研究開発、24 を DoD、94 を商用利用に割り当てる。クラス B では、1,024、3,072、12,286 とする。クラス C では、付録は研究に 65,536、DoD に 458,725、商用に 1,572,862 を印刷している。

これらは提案された割り当てであり、完了した配分の記述ではない。6 ページの作業表は、割り当てられた研究クラス A 識別子が 26、防衛が 4、商用が 1 であると報告している。26 の研究エントリは、付録の推奨割り当て 8 の 3.25 倍である。いくつかのエントリは古い移行番号としてマークされている。この不一致は、文書の実施が不完全であるという明示的な声明と整合している。

また、文書には数値的な不一致も含まれている。6 ページの「Maximum Allowed」の要約は、クラス C の防衛割り当てを 458,752 としているが、20 ページの付録 A は 458,725 と印刷している。その差は 27 識別子である。

6 ページの数字を使用すると、提案されたクラス C カテゴリの合計は次のようになる：

• 研究識別子 65,536、
• 防衛識別子 458,752、
• 商用識別子 1,572,862；

合計 2,097,150。これは、最初と最後の値を予約した後の 2,097,152 値のクラス C ネットワーク番号空間と一致する。

付録 A の印刷された 458,725 を代わりに使用すると、2,097,123 となり、6 ページの合計より 27 少ない。文書は説明を提供していない。再構築は、一方を黙って修復するのではなく、両方の印刷された主張を保存すべきである。

付録 A はさらに、運用可能になった実験ネットワークは、番号再割り当てが困難を引き起こす場合には、再番号付けする必要はないと推奨している。それらの識別子は代わりに研究から防衛または商用ステータスに移動できる。全体的なカテゴリ割り当ては一定のままであり、特定の識別子が状態を変更することが意図されていた。したがって、付録はカテゴリを単純な連続パーティションとして割り当てることを避け、責任機関間で追跡される特定の割り当てを推奨している。

これは分類、継続性、調整に関するポリシーの推奨である。それは特定のネットワークがどのようにして既存の行を取得したかを証明するものではない。カテゴリコードは表に印刷された結果を記録しており、理由の残存声明ではない。

勧告、合意、実務慣行は同じ付録に共存していた

付録 A は、それが 1982 年 9 月の会合で DDN/PMO と DARPA によって達せられた合意を要約していると述べて始まる。その後、繰り返し勧告の言葉を使用している。

ネットワーク識別子について、物語は、研究、防衛、商用利用の割り当てがそれぞれ DARPA、DCA PCCO/DDN、および国立標準局の責任になることを推奨している。しかし、数値表では ARPA が研究割り当て者として名前が挙げられ、防衛と商用の割り当て者にはTBDが印刷されている。

したがって、3 つの制度的状態が見える。機関は要約されるのに十分な合意に達していた。文書は責任の将来の配分を推奨した。重要な事務所レベルの責任は表では未解決のままだった。

4 つ目の状態は 22 ページに現れる：実務慣行。実施ノートは、ポリシーの勧告は完全には実施されておらず、現在 Postel がすべての番号割り当てのコーディネーターを務めていると述べている。付録が予期した制度的分担が何であれ、申請者と実装者は依然として中央の調整ポイントに直面していた。

ゲートウェイ準備に関する文言は、このシーケンスの中に位置づけられなければならない。それは、推奨される取り決めの下での研究コミュニティ内で「ポリシーとなるもの」を述べている。それは提案された適格性条件の直接的な証拠である。RFC 790 の以前のすべてのエントリ、RFC 820 のすべてのエントリ、またはすべてのタイプの番号リクエストがすでにその条件の下で処理されていたという直接的な証拠ではない。

同様に、困難条項は推奨される移行ルールである。それはポリシー設計者が再番号付けの運用コストを認識していたことを示している。どのTマークの変更が自発的であり、義務付けられ、交渉され、または新しいカテゴリ割り当てとは無関係の理由で行われたかを特定するものではない。

それでも付録は重要な制度的発見を支持している。その著者は実質的な割り当てと中央の追跡を区別することができた。異なる機関が異なるカテゴリで割り当てを行うことができ、一方で DDN/PMO または指定された者が、割り当てが勧告の範囲内に留まることを確実にするために、組み合わされた記録を追跡管理した。共通の記録管理者は、すべての決定の唯一の源泉である必要はなかった。

そのアーキテクチャはまた、未解決の問題を抱え込んでいた。ネットワークがカテゴリを変更した場合、誰かがカテゴリのバランスを更新しなければならなかった。割り当て者がその量を超えた場合、修正または例外手続きが必要となったであろう。2 つの機関が同じリクエストを自らの管轄内にあると見なした場合、その重複を解決する方法が必要となったであろう。RFC 820 は追跡を推奨するが、完全な管轄コードを公表していない。

したがって、この文書は部分的な形での管理理論を含んでいる：差別化されたプール、複数の可能な割り当て者、中央調整、継続性保護、一つのカテゴリに対する技術的適格性。また、理論と実際の割り当てのインターフェースがまだ収束していなかったという証拠も含んでいる。

行を申請者に変えずに目録を数える

ネットワーク表は、ドキュメンタリーの変化が公表された割り当てにどのように現れたかをテストすることができるが、それは 3 つの観察単位が分離されたままである場合に限る。

印刷された行は、文書に現れるままの行または範囲エントリである。それは 1 つの識別子、数百の識別子、または移行中に保持された古い番号を記述する可能性がある。重複行は印刷された行のままである。

拡張されたネットワーク識別子は、印刷された範囲が拡張された後に表現される 1 つのクラスフルネットワーク番号である。例えば、RFC 820 の範囲192.001.xxxから192.004.xxxは、第 2 オクテットの 4 つの値に第 3 オクテットの 256 の値を掛けたもの、つまり 1,024 のクラス C 識別子を表す。

一意のリテラル識別子文字列は、同一の印刷されたアドレス文字列が重複を除かれた後の拡張識別子であり、見かけのシーケンスが何を意図していたかを推測することなく処理される。この単位は、転記の矛盾を不可視のうちに修正するのではなく、それを保存する。

これらの単位のいずれも、申請者、受領者、組織、アクティブなルート、ホスト、または財産権の利益ではない。

RFC 790 のクラス A 表は、013 が明示的に未割り当てであることを除き、001 から 044 までの値について名前付き割り当て行を印刷している。これにより 43 の名前付き割り当て行が生成される。それは 43 の争いのない割り当て識別子を生成しない。044 の行は AMPRNET と名前が付けられているが、直後の未割り当て範囲も 044 から始まり、126 まで続く。したがって、この文書は 42 の明確な名前付き識別子と、内部で矛盾する 1 つの識別子(044)を供給している。

クラス B には RFC 790 における名前付き割り当てが含まれておらず、クラス C も同様である。この記述は表を記述しており、世界中のすべての小規模ネットワークの不在を記述しているわけではない。リストされたクラス A ネットワークには、複数の実験、関連施設、テストネットワークが含まれている。名前付き行は、法的に独立した 1 つの受益者の証拠ではない。

RFC 820 は 6 ページに印刷された「Network Totals」の要約を提供している：

この印刷された要約を使用すると、研究は(1,078 / 1,097)、つまり 98.267 パーセント、四捨五入して 98.3 パーセントを占める。これは印刷された要約の結果であり、申請者や組織の 98.3 パーセントが研究機関であったという発見ではない。

支配的な寄与は、BBN ローカルネットワークに関連付けられた単一の範囲から来ている。192.001.xxxから192.004.xxxを拡張すると、(4 \times 256 = 1,024) のクラス C 識別子が得られる。これらの 1,024 の識別子は、RFC の印刷された割り当て総数(1,097)の(1,024 / 1,097)、つまり 93.345 パーセント、四捨五入して 93.3 パーセントを占める。

その分母は明示的である：印刷された要約で表された 1,097 の拡張割り当て。この比率は、BBN が 1,024 の個別の申請を行い、1,024 の独立した決定を受け取り、またはすべてのネットワークを外部ルーティングユニットとして使用したことを意味しない。文書は範囲を「BBN ローカルネットワーク」と関連付けているが、その背後にある要求履歴や運用トポロジーについては説明していない。

リテラルな重複排除は異なる結果を生む。クラス C 表では、192.005.022が BRLNET2、BRLNET3、BRLNET4、BRLNET5 に印刷されている。名前は意図されたシーケンスを示唆しており、次の未割り当て範囲は 192.005.026 から始まるが、リテラルな再構築はそれを修正としてマークせずに 023、024、025 を代入することはできない。

192.005.022 の 4 つの出現を重複排除すると、印刷されたクラス C 合計から 3 つの重複出現が除去される：

繰り返される BRL 行は防衛コード化されているため、一意のリテラルカテゴリ合計は研究 1,078、防衛 13、商用 3、全体で 1,094 となる。研究数は 1,078 のままであるが、防衛数は 16 から 13 に減少する。

その差は BBN 範囲に比べて小さいが、方法にとっては決定的である。印刷された要約は情報源の主張として再現できる。一意の文字列カウントは別個のリテラルな読み取りとして再現できる。どちらも他方として提示されるべきではない。

移行エントリは別の複雑さを加える。RFC 820 は、変更を容易にするために古い番号がTを付けられてリストに残る可能性があると説明している。したがって、ネットワークは古いクラス A 識別子と新しいクラス B 識別子の下に現れることがあり、それは独立して配置された 2 つの受領者を表していない。両方をカウントすることは運用上の認識として正しい場合があり、受領者の分析としては誤りである。

文書間の動きは依然として見える。RFC 790 はクラス A 表にのみ名前付き行を含んでいる。RFC 820 は、その要約によれば 31 のクラス A、24 のクラス B、1,042 のクラス C の割り当ての混合を含んでおり、明示的な移行マークとともにそれを示している。いくつかの以前の大きな識別子は置き換えられ、放棄され、または一時的に保持された一方で、より小さなクラスの識別子が登場した。

その変化は、より差別化された割り当てサイズと一致している。それが希少性が各変化を引き起こした証拠ではない。表にはホスト利用率の系列、予測、申請書、決定理由は含まれていない。クラス A 識別子の容量はアドレスフォーマットが許容したものを言うのであり、名前付きネットワークが実際に使用したアドレス数や、管理者がその時点でそのクラスを選択した理由を言うのではない。

BBN の範囲は、利用可能な最大のクラスへの一様な選好という単純な物語に対する重要な反証である。1 つの主要な参加者は、他のエントリに加えて、1,024 の小さなクラス C 識別子を通じて現れている。表は、この配置が実験、ローカルセグメンテーション、ルーティング慣行、管理上の都合、または別の目的を反映していたのかを説明していない。それらは、制度的な卓越性がすべての場合に機械的に 1 つのアドレスクラスを生み出さなかったことを示している。

印刷された商用カウントも誤って読まれがちである。6 ページの要約では 3 つの割り当てだけが商用コード化されているが、付録 A は大規模な将来の商用割り当てを提案している。この対比は、初期段階のポリシー移行、稼働中のインターネットの限られた範囲、コーディング慣行、需要の構成、または不完全な実装を反映している可能性がある。申請や通信がなければ、排除や優遇を立証することはできない。

後の割り当てデータが修復できることとできないこと

CAIDA のIPv4 割り当ての視覚的歴史は、アドレス空間移動の有用な再構築を提供する。これはまた、後の視覚化が不足している申請者の分母を提供できない理由を示している。

CAIDA は、視覚化の初期部分は Assigned Numbers RFC から派生しており、後の期間は IANA データを使用していると説明している。表現は/8の粒度で動作し、より小さな割り当てをそれらを含むより大きなアドレスブロック内に配置している。割り当てられたアドレス空間は、一部の組織が大きなブロックをより小さな割り当てと交換したために RFC 790 と RFC 820 の間で減少したことに言及している。

その説明は、RFC 820 の移行マークや名前付きクラス A エントリの減少と互換性がある。しかし、その初期の再構築が調査中の RFC シリーズに依存しているため、独立した受領者レベルの裏付けではない。公開日付シーケンスは 1977 年 11 月から 1983 年 1 月まで移動し、関連するサンキーデータは/8ごとにフローを集計している。これらは RFC 790 と RFC 820 の間の各リクエスト、割り当て決定、または受領者の移行を独立して再構築することはできない。

後のレジストリ記録は他の問題を導入する。CAIDA の IPv4 消費方法論に関する別の説明は、1993 年の更新が、正確な以前の日付が利用できない多くのレガシー割り当てに 1993 年 8 月の日付を割り当てたことに言及している。その後の記録はまた、組織の改名、管理責任の移転、修正、ステータス変更を継承する可能性がある。

したがって、現在のレジストリエントリは存続する管理状態の証拠であり、1981 年に申請者が要求したものの手つかずの記録ではない。それは後の継続性を追跡するのに役立つかもしれないが、それ自体では初期の行を生み出した理由、日付、決定単位を復元することはできない。

表は、行き過ぎることなく、いくつかの経験的発見を支持することができる：

• RFC 790 は 43 の名前付きクラス A 割り当て行を印刷しており、そのうち 42 は曖昧さがなく、1 つは後続の未割り当て範囲と矛盾する。
• RFC 820 の印刷された要約は 1,097 の割り当てを報告しているが、リテラルな重複排除により 1,094 の一意のアドレス文字列が得られる。
• 研究は印刷された総数の 98.3 パーセントを占めるが、これは主に 1 つの BBN 範囲が 1,024 の研究コード化されたクラス C 識別子に拡大されるためである。
• BBN 範囲だけでも印刷された要約の総数 1,097 の 93.3 パーセントを占める。
• 古い識別子と新しい識別子は、移行行が運用上の継続性を保持するために共存しうる。
• 作業表はまだ付録 A の推奨カテゴリ割り当てと一致していない。
• これらの文書は、リクエスト、拒否、撤回、または思いとどまらせられた申請の直接の分母を含んでいない。

これらの発見は、目録が管理的に作成されたことを示している。カテゴリ、変更、予約、移行が記録されなければならなかった。それらは、同様の状況にある申請者が同様に扱われたかどうかを明らかにしない。なぜなら、関連する母集団と決定ファイルが存在しないからである。

テキストの差分が 4 つの説明を存続させる

RFC 790 から RFC 820 への動きには、少なくとも 4 つの期間実現可能な説明がある。

1 つ目はポリシー開発である。1982 年 9 月の会合は、成長し多様化するインターネットへのより明示的な対応を生み出したかもしれない。新しいカテゴリコード、推奨プールサイズ、ゲートウェイ準備条件、提案された制度的責任の分割がこの読解を支持する。付録 A はそれらを機関合意に結びついた推奨ポリシーとして直接提示している。

2 つ目は実装管理である。ARPANET 環境から ARPA インターネットへの移行、MILNET の開発、ネットワークの再番号付けや再分類は、まったく新しい分配哲学がなくとも、より精巧な運用文書を必要としたかもしれない。Tマーク、より小さなクラスの割り当て、困難条項がその説明に適合する。

3 つ目は文書化の整理である。以前は通信や作業関係を通じて理解されていた慣行が、より明確に書き記された可能性がある。合計、管理コード、実施ノートは、それらが記述するすべての慣行の始まりではなく、より良い出版物を反映しているかもしれない。

4 つ目は起草の選好である。検討された RFC 820 のヘッダーは、現在のカタログが Postel のみをリストしているにもかかわらず、J. Vernon という追加の名前を表示している。異なる起草プロセスが、日々の決定に比例した変化なしに、より明示的な制度的文章を生み出した可能性がある。カタログ/ヘッダーの不一致は、著者性と編集上の伝達を、特定のポリシー役割を帰属させる根拠ではなく、不確実性の一部としている。

これらの代替案は相互に排他的ではない。付録は同時に合意を記録し、移行を導き、既存の期待を形式化し、より拡張的な編集スタイルを反映することができる。

当時の通信がそれらを区別する可能性がある。Computer History Museum のファインディングエイドは、会議ノート、NIC 進捗報告、命名およびアドレス指定ファイル、時系列の電子メール、ワーキンググループの記録、請負業者から収集されたインターネット月報を特定している。これは、NIC スタッフ、ネットワークユーザー、ワーキンググループ、連邦機関の間の潜在的に関連する通信がアーカイブコレクションに残っていることを示している。

ファインディングエイドは、特定の RFC 790 のリクエストの内容、1982 年 9 月の会合の記録、または付録 A の起草通信の内容を開示していない。それはコレクションの存在と範囲を証明しているが、未開封の記録が何を確立するかではない。

焦点を絞ったアーカイブ調査は、誰が付録を起草したか、カテゴリコードが既に内部で使用されていたか、ゲートウェイ証拠がどのように評価されたか、なぜ一部の割り当て権限がTBDのままだったのか、特定の再番号付けがネットワークによって提案されたのか管理者によって提案されたのかを問うだろう。根底にある記録がこれらの質問に答えるまで、テキストの差分は複数の説明を支持する。

連絡先は決定の連鎖を定義せずに責任を露呈した

両方の RFC は責任者にかなりのスペースを割いている。プロトコルやネットワークの横にある括弧付きのコードは、人セクションの名前、所属、メールボックスを指している。これにより簡潔なエントリが運用上使用可能になった。開発者は、文書化されていないプロトコルが何を意味するか、または名前付きネットワークについて誰に連絡すべきかを誰かに尋ねることができた。

それでも「責任者」という言葉は伸縮自在である。その人はプロトコルの作成者、実装者、サイト連絡先、エンジニア、文書化ソース、レジストリメンテナであるかもしれない。その列は、その人が番号を申請したか、承認したか、ネットワークを制御したか、または単に技術的な質問に答えるのに十分な知識を持っていたかを示していない。

曖昧さは、Postel のコードであるJBPの使用に見られる。それは予約済みおよび未割り当ての範囲、ならびに割り当てられたプロトコル値の横に表示される。これらの位置では、それは受益者を示すことはできない。それはレジストリ状態または技術的定義に対する責任を示す。他のコードは名前付きネットワークに関連する人々を指している。したがって、一つの表記は複数の関係を表している。

連絡先の仕組みは限定的な制度的主張を支持する：初期の調整は特定可能な専門家と到達可能なメールボックスに依存していた。それは個人の評判が割り当て基準であったという主張を支持しない。また、予備的な議論が電子メール、電話、紙の通信、会議のいずれによって行われたかを示すものでもない。

共有リストへの掲載は、割り当てに運用上の可視性を与えた。リファレンスに依存する実装者は重複を避け、関連する連絡先を特定することができた。その実際的な重要性は、リストがすべてのネットワークの技術的存在を創造したとか、財産権を付与したということを立証するものではない。付録 A の提案された複数割り当て者モデルはむしろ、割り当て決定が複数の機関で発生し、追跡のために統合される可能性があることを示唆している。

より完全な台帳は実現可能だったが、コストがかからないわけではなかった

RFC 820 のネットワーク番号部分が、適用される適格性基準、短い理由コード、各改訂の出所、集計されたリクエストの処理結果、例外を決定する権限を有するオフィスの 5 種類の追加情報を保存していたと想像してみよう。

これは現代の公開アプリケーションシステムを必要としなかったかもしれない。期間実現可能な設計は、別個の固定幅付録、紙のフォーム、電子メールテンプレート、集計月間合計を使用することができた。理由コードはゲートウェイ準備、実験、移行、カテゴリ変更、修正を区別することができたかもしれない。改訂列は以前の識別子と発効日を記録することができたかもしれない。機密詳細は制限されたファイルに残し、公共リストは最小限のコードを保持することもできた。

そのような記録は、いくつかの歴史的な質問をテスト可能にするだろう。研究者は完了した割り当てを撤回や拒否と比較し、申請者が要求した再番号付けと管理的開始を区別し、ゲートウェイ基準が一貫して適用されたかどうかを判断することができる。名前付きの例外権限は、提案された責任分担がどこで停止したかを示すだろう。

追加の記録はまた負担を課すだろう。スタッフは一貫して受信データを保存し、理由の語彙を維持し、連続する出版物間で改訂を調整する必要があるだろう。実験的または防衛関連のリクエストは公開に適さない詳細を含む可能性がある。編集ルールはさらなる決定を生み出すだろう。RFC 820 のTBDエントリは、例外権限を特定すること自体が未完成であったことを示している。

SRI NIC ファインディングエイドは、より広い期間におけるメディアの非互換性、印刷物の作成上の問題、急速に陳腐化するリファレンス出版物について説明している。Assigned Numbers の管理は 1987 年まで USC-ISI に留まっていたため、その証拠は RFC 790 と RFC 820 の正確な制作プロセスやコストを確立することはできない。それは、より豊かな文書化が実際の技術的および出版上の制約と相互作用したであろうことを示す期間の文脈である。

したがって、この反事実的条件は、制度の正当性ではなく、残存する証拠を変化させる。基準が不十分に設計されているかもしれず、理由が形式的であり、集計が申請方法を学ばなかった人々を除外する可能性がある。それでも、成功エントリリストと理由付き決定記録の違いは、後の扱いに関する主張を実質的にテストしやすくしたであろう。

今度は設計を逆転させてみよう。一元化されたオフィスがすべての割り当てを決定することなく、一意性を調整することは可能だっただろうか？

RFC 820 自体の推奨は、原則としてイエスと答えている。研究、防衛、商用の識別子は異なる機関が割り当てることができ、指定されたコーディネーターが組み合わされた記録を追跡する。当時はすでに電子メール、電話調整、定期的に更新される文書がサポートされていた。いくつかの実行可能な取り決めが考えられた。

一つの選択肢は、特定の割り当てを共通の追跡者に報告することであり、これは付録 A が好んだ。なぜなら識別子はカテゴリを変更できるからである。もう一つの選択肢は、各割り当て者が定義された範囲を制御し、定期的に更新を公表する分割プールである。三つ目は、スケジュールに従って調整される分散型の説明責任のあるリストの集合であり、一時的な予約メッセージが版の間の衝突を防ぐものである。

各代替案にはコストがあった。単純な分割はカテゴリ変更をより困難にし、未使用の識別子を一つのプールに滞留させる可能性があった。定期的な調整は遅延を導入した。分散リストは矛盾した状態を招くリスクがあった。共通追跡者を通じた特定の割り当ては、いくつかの衝突リスクを低減したが、追跡者を運用上重要にした。

ポイントは、分散化が必ずしも優れていたということではない。衝突制御、実質的な適格性、公表は分割可能であった。共通追跡は運用上価値があり、RFC 820 のアーキテクチャ内で明示的に推奨されていたが、単一の普遍的な目録が唯一の論理的に可能な設計ではなかった。

この区別は、コーディネーターの役割を解釈する際に重要である。指定されたカテゴリ割り当て者が未解決または利用不可能だった場合、共通の記録を維持する人物が実際にはリクエストを処理し続けるかもしれない。その拡大は、排他的権限の主張ではなく、不完全な実装から生じうる。RFC 820 はまさにそのようなギャップを文書化している：分散された責任が推奨される一方で、一人のコーディネーターが依然としてすべての割り当てを処理している。

連邦政府の支援は能力を説明するが、すべてのルールを説明するわけではない

政府の設定は、2 つの文書が自らの用語を確立した後でなければ付け加えることができない。

2016 年の政府説明責任局（GAO）の法的意見は、後に IANA の名称でグループ化される機能は、UCLA の Postel が主導した作業から始まり、1977 年に彼とともに USC-ISI に移動したと述べている。GAO は、この作業が米国国防総省の資金提供を受けた研究プロジェクトの下で実施され、後の DARPA 契約を通じて継続されたと説明している。

その後の説明は、RFC 820 の DARPA/IPTO、DDN/PMO および 1982 年 9 月の会合への直接の言及と一致している。これは、グローバルな技術目録がなぜ米国の管理センターを持ち、提案されたポリシーが研究、防衛、商用利用を区別したのかを説明するのに役立つ。

GAO はまた、1970 年代から 1990 年代にかけての関連する DARPA 契約を入手できなかったと述べている。そのより詳細な契約証拠は後の期間に関するものであり、その法的問題は RFC 790 と RFC 820 の数十年後に生じた。

したがって、この意見は欠落した 1981 年の契約の条項、特定のリクエストに適用された基準、またはすべての参加者が理解した権限の範囲を確立することはできない。連邦政府のスポンサーシップは制度的能力と文脈を説明する。それだけでは、識別子の所有権、普遍的な同意、または各管理選択の正当性を証明するものではない。

主要な証拠はより狭いままである。RFC 790 は割り当てのためのコーディネーターを指名している。RFC 820 は機関合意、推奨される番号空間の分割、将来の制度的責任、提案された研究適格性条件、不完全実施ノートを追加している。後の政府の歴史は環境を裏付けるが、それらの声明を包括的な憲章に変えるものではない。

列が最終的に支持するもの

アドレスリストの中の政治は、単にリストが異なる技術的能力を持つ識別子を分配するために現れるのではない。それらは、文書が分類、適格性、移行、制度的責任、および維持された共通記録に依存することの結果を示すときに可視化される。

RFC 790 は集中された調整インターフェースを確立する。いくつかの番号系列が一緒に公表され、開発者は指名された割り当て連絡先に案内され、結果として得られた値は現在の運用情報として提示された。そのネットワーク表は研究、政府、軍事、公衆データ、商用ネットワークの混合セットを記録するが、一般的な申請者基準や割り当て責任の分担は与えていない。

RFC 820 はより明確な管理層を追加する。ネットワーク識別子を利用別に分類し、移行中に古い番号を保持し、割り当て合計を印刷し、推奨カテゴリ割り当てを提示する。研究申請者にゲートウェイ関連証拠を提案し、困難が生じる場合に再番号付けなしでネットワークのカテゴリ変更を認め、共有追跡取り決めの下で複数の機関による割り当てを想定している。

同じ文書がこれらの勧告を完了した慣行と誤解されるのを防いでいる。防衛と商用の割り当て者は数値表でTBDのままである。作業割り当ては推奨されたクラス A の配分と一致しない。最終実施ノートは、Postel がまだすべての割り当てを調整していると述べている。

表はまた単純な分配物語に抵抗する。RFC 790 の値 044 は内部的に矛盾している。RFC 820 は一つのリテラルなクラス C アドレスを 4 回繰り返し、不整合な防衛クラス C 割り当て合計を印刷している。その 1,097 割り当ての要約は 1,024 識別子の BBN 範囲によって支配されている。移行エントリは同じネットワークを古い番号と新しい番号でカウントすることができる。これらは特定可能な編集上および計数上の問題を伴う運用記録であり、申請者のクリーンなデータセットではない。

したがって、文書はネットワーク番号調整が受動的な転記以上のものを含んでいたという推論を支持する。技術的な一意性は保護されなければならなかったが、カテゴリ割り当て、移行処理、提案された準備条件は管理的判断を必要とした。その判断は連邦政府の支援を受けた制度的設定の中で運用され、検討された RFC 820 テキストでは依然として一人の作業コーディネーターを通過した。

それらはまた、より集中化を弱める推論を支持する。RFC 820 は共有追跡を排他的な実質的割り当て権限と同等視しなかった。その推奨アーキテクチャは、一つの機関が組み合わされた割り当てを監視する一方で、決定が複数の機関で発生することを許容した。この設計は不完全であったが、概念的な区別は存在している。

残る不確実性は些細な限定ではない。公開リストには、申請母集団、拒否の数、撤回履歴、利用率系列、各割り当ての理由が含まれていない。利用可能なファインディングエイドは潜在的に関連する通信を特定するが、その内容を明らかにしない。文書は、このコンパクトな形式が便利さ、出版の制限、継承された慣習、意図的な最小主義、その他の原因に起因するのかを示すことができない。

また、表は成熟した希少性の教義を確立するものではない。それらは有限のクラス空間、予約値、カテゴリ割り当て、アドレスサイズ間の移動を示している。それらは希少性が特定の割り当てを動機づけたこと、または申請者がそのために拒否されたことを示してはいない。後のアドレス枯渇は、初期の配分の結果を増幅させたが、それらの元々の動機を再構築するものではない。

生き残っているのは、実際の運用効果を持つ文書化された管理能力である。リストは値を調整し、特定の割り当てを可視化し、ネットワークを分類し、変更中の継続性の保持を助けた。その記録への依存は、たとえ記録者がすべてのネットワークの正当性の作者であると主張しなかったとしても、その維持を重大なものにする可能性があった。

読書灯の下で、したがって、2 つの文書間の重要な違いは、政治が 1983 年に突然表に入ったということではない。それは RFC 820 が管理機構のより多くを読み取り可能にしたということである：合意、利用カテゴリ、将来の割り当て者、適格性の推奨、移行ルール、そして設計に実装が遅れているという告白。

その機構は、その運用者に隠された動機を帰属させることなく記述することができる。その分配的結果は、範囲を申請者に変えることなく測定することができる。その権限は、クリーンな列が正当性または隠蔽のいずれかの証明であると仮定することなく検討することができる。この 2 文書考古学の最も永続的な教訓は、技術的目録が、調整システムが何を認識したかについての不可欠な証拠でありながら、認識がどのように、なぜ、誰によって決定されたかについての不完全な証拠であり続けるということである。