要約
- 1983 年から 1992 年に公開された手順は、様式、技術要件、責任管理者、修正経路、連絡窓口について記述していた。本稿で調査した文書サンプルにおいては、失敗したドメインまたは数値識別子申請のための、一般的かつ独立した不服申立窓口を確立してはいなかった。
- 登録ユーザ、ドメイン、割り当て済みネットワーク番号の一覧は、完了済みまたは現在の記録を保存している。それらは、提出済み、不完全、遅延、取下げ、拒否、修正、再審査、エスカレーション、逆転、その他終結した申請の全母集団を明らかにしない。
- NIC の通信、電話支援、上位ドメイン管理、政府助成、IANA の権限、連邦政府の監督は、特定の問題解決に役立った可能性がある。しかし本サンプルには、それらのいずれかの経路が、理由付きで記録された結果を伴う申請者の不服申立として機能したことを証明する申請レベルの事例は含まれていない。
- したがって権限マップは不均等である:NIC 職員は記録を処理し修正できた。ホストおよびドメイン管理者はローカルの申請を承認または修正できた。スポンサーは接続性に影響を与えられた。IAB はポリシーを推奨できた。IANA は番号割り当ての権限を保持し委任していた。個別の上訴管轄権および逆転義務は確立されていない。
- 記録上の対立が少ないことは、善意の説明とも懐疑的な説明とも両立する。問題は通常、信頼関係を通じて正確に解決されたかもしれないし、あるいは、手続履歴よりも割り当てを保存することに最適化された記録から、失敗した申請者が消えてしまったのかもしれない。利用可能な全体母数では、この二つを区別できない。
成功したリストの背後に隠れた分母
公開されたネットワーク番号表は、到着の記録である。それは公式登録簿に登載された識別子と、時には移行中に変更されたエントリを示す。ドメイン表も同様に、登録を完了した名前を示す。いずれの表も、結果に至る前の全ての試行を記録してはいない。
これが分母問題である。初期インターネット管理の制度史においては、割り当てではなく申請を数える必要がある。関連する母集団には、初回提出、重複、技術的に不完全な様式、追加情報を求められて差し戻された申請、取下げ、修正、遅延、実質的な拒否、再申請、スポンサーの介入、再審査、エスカレーション、逆転、そして記録された処分なしに終わった案件が含まれる。一意な識別子を保存するために構築された登録簿は、その母集団の一部しか提供しない。
通常の経路のほうがはるかに再構築しやすい。
期間直前のベースラインとして、1982 年 3 月 1 日付のRFC 810は、国防総省のネットワーク、ゲートウェイ、ホストの名称とアドレスについて、使用前および DoD ホストがトラフィックを流す前に、Network Information Center と交渉し登録することを要求した。それは電子的および電話の連絡経路を特定した。暫定期間中、NIC は非 DoD ネットワークおよびホストから提供された同等の情報の維持も試みるとしていた。この指示は登録が行われる場所を確立した。それは申請台帳や不利な結論に異議を唱えるための経路については記述していなかった。
1984 年 10 月に公開されたRFC 920は、ドメインを確立するための要件を規定した。ドメインは単なるラベルではなく、管理上の実体であった。技術的能力と組織的権限を持つ責任者、信頼できるネームサービス、適切な階層を通じた登録が必要とされた。下位レベルのドメインは、その直上の管理者を満足させなければならなかった。文書には、提案ドメイン、連絡先、サーバ構成、予想規模、管理体制に関する質問票が含まれていた。
1987 年 11 月のドメイン管理者ガイドであるRFC 1032は、作業手順をより明確にした。管理者は質問票を入手し、記入して NIC Hostmaster に送付した。Hostmaster 担当者は情報を完全性についてレビューした。ガイドは、認可までに数回の電子通信のやり取りを想定していた。修正は後で提出でき、申請者は電子メールやフリーダイヤルのホットラインを通じて質問できた。
これらの文書は、手順、管理デスク、および支援チャネルが存在したことを証明する。しかし、各段階でどれだけの申請が止まったかは示していない。最終的なドメイン記録は、完全な初回提出、定型的な明確化、繰り返される技術的修正、上位ドメイン管理者の介入、または以前の提案の置き換えを経て成立した可能性がある。いったんドメインが登録簿に現れると、それらの履歴は同じ可視的な結果に収束する。
同じ問題がネットワーク番号の公開にも当てはまる。1988 年 8 月に発行されたRFC 1062は、割り当て済みネットワーク番号を列挙し、研究、防衛、非防衛政府、商用ユーザを区別した。また、移行使用のための変更番号も一部示していた。この情報は割り当てと再番号付与を記録している。それは全ての申請、ましてや失敗した申請を特定するものではない。
表の空白番号は、拒否された申請者の証拠ではない。登録された番号は、元の申請が完全であったことの証明ではない。変更マーカーは、変更が要求されたのか、課されたのか、争われたのか、単に技術的なものだったのかを明かさない。表は運用状態を保存するのであって、その状態に至った経路ではない。
したがって、目に見える対立が少ないことは、二つの物語を支持しうる。善意の説明は、管理者と技術的に熟達した申請者は一般に互いを理解し、通信を通じて誤りを修正し、深刻な紛争を生じることは稀だったというものである。懐疑的な説明は、現在の割り当てを中心に組織されたシステムには、失敗した試み、書かれなかった説明、失望した申請者を保存する運用上の理由がほとんどなかったというものである。どちらの物語も、成功した登録のクリーンなリストを予測する。
残されたリストは、両者を選別できない。
承認・却下の二元論ではなく、状態機械
最小限の分析的な並びは以下のとおりである:
提出 → 不完全 → 追加情報要求 → 遅延 → 拒否 → 修正 → 再審査 → エスカレーション → 逆転 または 最終
この表記は、全ての申請が全ての状態を通過したことを示唆するものではない。実際の経路は分岐する。不完全な申請は修正されて続行されるかもしれない。完全な申請が取り下げられるかもしれない。拒否が再審査されずに最終化するかもしれない。エスカレーションは、識別子の決定よりも、スポンサーシップや接続性に関するものかもしれない。この並びの価値は、異なる手続上の出来事を「却下」という言葉にまとめてしまうのを防ぐ点にある。
提出とは、特定可能な権限主体が申請を受領したことを意味する。証拠には、受信した様式、メッセージ、書簡が含まれ、できれば受領日と、どのサービスが求められていたかを判断するに足る文脈が伴う。後の登録は何らかのプロセスが成功したことを証明するが、最初の提出日や内容を確立するものではない。
不完全は、処理上の条件を指す。必須フィールド、責任ある連絡先、サーバ構成、承認が欠落していることがある。RFC 1032 は、NIC がドメインを認可する前に質問票の完全な記入を求めた。この規則は当該カテゴリーを文書化しているが、不完全と分類された名前付き申請を示すリンクされた申請ファイルは、本サンプルには含まれていない。
追加情報要求は、積極的な管理行為である。RFC 1032 が数回の通信のやり取りを想定していたことは、明確化が通常の処理の一部であったことを示している。ただし、特定のケースでは、送付された問い合わせ、それに関連する申請、そして回答が必要となる。二回目の提出だけでは、最初の提出が質問を促したかどうかは明らかにならない。
遅延には日付と、未解決のまま継続している申請が必要である。期間は、スタッフの処理時間、申請者の応答時間、スポンサーレビュー、技術的準備、ポリシーの検討に分割されなければならない。初期計画が議論されてから数か月後に登録されたドメインは、自動的に遅延申請とはみなされない。文書化された開始、中断、終了イベントがなければ、遅延は立証されない。
取下げとは、申請者が申請を終わらせたことを意味する。この状態には、申請者に確実に帰属できる表明または行動が必要である。沈黙は曖昧である:申請者は計画を放棄したかもしれないし、仲介者を変えたかもしれないし、電話で解決したかもしれないし、返答を受け取らなかったかもしれない。
拒否は、割り当てが行われなかったことではなく、実質的な不利な決定である。直接的な記録は、決定権限者、適用された要件、理由、結果の通知を特定しなければならない。不完全なテンプレート、未回答の質問、不適格な接続要求、ローカルの当事者に差し戻されたドメイン紛争は、それぞれ異なる出来事である。
修正は、データ、要求された構成、または補足情報が変更されたことを意味する。修正は必ずしも異議を意味しない。それは通常の品質管理かもしれない。当時の文書は修正手順を直接的に確立しているが、それらの手順を不服申立に変換してはいない。
再審査は、当初の担当者または管理単位が既に下した結論を再検討したことを意味する。申請者が不足データを提供した後の処理継続は、それと似ているように見えるが、必ずしも不利な決定の再審査ではない。ケース記録は、以前の立場と後の再検討を示す必要がある。
エスカレーションとは、問題が別の権限主体または制度的レベルに移ったことを意味する。Hostmaster が上級の同僚に相談するかもしれない。申請者がスポンサーに働きかけるかもしれない。DDN プログラムスタッフが関与するかもしれない。ポリシー上の問題が IANA や連邦ネットワーク機関に届くかもしれない。単に上級職員を通信の写しに加えただけではエスカレーションとは証明されず、またエスカレーションは審査を証明しない。
逆転には、二つの両立しない決定が必要である:特定可能な以前の結果と、それを変更した後の結果である。修正された綴り、新しいサーバアドレス、再番号付与、修正された申請は、覆された決定を記録が確立しない限り、逆転ではない。
最終は最も危険なラベルである。公開された手続が決定を最終と宣言するかもしれないし、完全なケースファイルが利用可能な審査が終了したことを示すかもしれない。残された最後のメッセージは、最終性を証明しない。それは保存された最後の項目であって、発生した最後の出来事ではないかもしれない。
したがって、本サンプルにおける証拠状況は非対称である:
| 申請状態 | サンプルが確立していること | ケースレベルの状況 |
|---|---|---|
| 提出 | 公開された様式とチャネルが存在した | 完全な個別申請ファイルは調査されていない |
| 不完全 | ドメイン認可には完全な情報が必要だった | プロセスは文書化されているが、特定の名前付きケースはない |
| 情報要求 | 反復的な通信が期待されていた | プロセスは文書化されているが、連鎖したシーケンスはない |
| 遅延 | 遅延は日付の入ったケースイベントを通じてのみ定義できる | 観測されず |
| 取下げ | 申請者に帰属する終結が必要 | 観測されず |
| 拒否 | 実質的な決定と理由の提示が必要 | 観測されず |
| 修正 | ユーザテンプレート、ドメインデータ、公開番号エントリは修正可能だった | 直接文書化されているが、不服申立としてはない |
| 再審査 | 1990 年にシステムレベルでポリシーが再検討された | 申請者レベルのケースは観測されず |
| エスカレーション | 管理者、スポンサー、政府機関を通じた制度的チャネルが存在した | 可能な経路だが、適格なケースは観測されず |
| 逆転 | 対立する当初の決定と後の両立しない決定のペアが必要 | 観測されず |
| 最終 | 明示された、または実証可能な終局処分が必要 | 観測されず |
この表は頻度を推定するものではない。公開手続サンプルにおける各状態の証拠上の位置を記録するものである。必要な直接記録が確立されていないため、本サンプルでは拒否、遅延、エスカレーション、逆転、最終処分のいずれも歴史的ケースとして提供されていない。
文書サンプルとそれが除外するもの
対象期間は 1983-1992 年である。RFC 810 は、ホスト登録規則の継承されたベースラインとして 1982 年 3 月時点のみが使われる。1993 年発行の RFC 1400 は、明示的な申請状態の可視性が後に公開手続にどのように入ったかを示す短い比較としてのみ登場する。
サンプルは、公開手続および制度的権限のサンプルであり、個別申請のコーパスではない。その単位は文書または公開された文書的成果物である。それは以下から成る:
- RFC 920、RFC 1032、RFC 1062、RFC 1174、RFC 1359
- 1983 年 10 月 20 日の NIC 文書「Instructions for Network User Registration Drive」(コンピュータ歴史博物館のDefense Communication Agency Materials; 6 of 13のデジタル化バンドル 67-73 ページに保存)
- 1985 年 5 月 17 日付「How to Reach the NIC」、NIC KNACKS第 2 号(Defense Communications Agency Materials; 3 of 13のデジタル化バンドル 94 ページに保存)
- コンピュータ歴史博物館の 2011 年Guide to the SRI ARC/NIC Records、コレクション X3578.2006
- James Pelkey による Jon Postel へのインタビュー(1988 年 2 月 18 日録音)
- 米国会計検査院(GAO)による DNS と IANA 機能に関連する連邦契約の後の法的沿革
文書が含まれたのは、1983-1992 年に関連する申請要件、管理チャネル、修正プロセス、割り当て権限、スポンサーシップの区別、ポリシー勧告、または監督関係を記述している場合である。RFC 1062 は、申請マニュアルとしてではなく、公開された成果物のアーティファクトとして含まれている。検索補助ツールはアーカイブの全体像を定義するために使用されており、コレクション内の記録の代用ではない。Postel のインタビューは文書化文化に関する限定的な文脈を提供するが、識別子のケースの証拠ではない。GAO の意見は後の法的沿革であり、実際に調査した契約連鎖に限定されている。
いくつかの証拠群は、本サンプルの範囲外である。それは 281 ボックスにおよぶ SRI ARC/NIC コレクションのボックスごとの調査ではない。全てのドメイン申請、ホストテーブルの更新、番号要求、ホットラインログ、月次報告、スポンサーレター、内部メッセージをレビューしたとは主張しない。検索補助ツールの記述を、いかなる申請の結果の証明としても扱わない。統計的にサンプリングされた申請ファイルは含まれていない。
本サンプルはまた、現在のレジストリデータからの推測も除外する。後の WHOIS レコードや存続する委任は、同時代の通信なしに初期の申請を再構築することはできない。口頭の記憶は、直接記録と照合されない限り、申請としては数えない。割り当て行は結果であって、申請単位ではない。
SRI ARC/NIC 検索補助ツールは、281 ボックス内の 351 リニアフィートを記述し、資料の大部分は 1968-1990 年のものである。関連するシリーズには、NIC 提案と契約、正式な月次報告、契約成果物、リファレンスおよびホットライン運用、命名とアドレッシング、TAC ユーザアクセス登録、ネットワーク連絡先の管理、その他電子メールと通信が含まれる。
ガイドは、コレクションに NIC 月次報告の完全なセットが含まれていると述べているが、それらに一意な申請分母が含まれているとは述べていない。電話、メッセージ、更新、登録の月次合計でも、個々の申請へのリンクが必要である。10 件のメッセージは 10 人の申請者を表すかもしれないし、一人の申請者に関する 10 回のやり取りかもしれない。ホットラインの通話は、文書アクセス、ログイン問題、ホスト更新、識別子要求のいずれかかもしれない。集計された活動は、処分の系列ではない。
ガイドはまた、1989 年までのその他通信をマッピングしている。通信は異なる場所から収集され、多くの主題をカバーしているため、その存在は完全性を確立できない。申請はその返信から分離されているかもしれない。電話での会話は残存するメモがないかもしれない。記録は申請者別ではなく、従業員、日付、サービス別に整理されているかもしれない。物理的アーカイブの調査で例外的なケースを回収できる可能性はあるが、本稿はその作業が行われる前の発生率の主張は行わない。
有効な申請レベルの調査は、明示的な包含ルールを必要とするだろう:例えば、特定の四半期に受け取られた、成功か否かを問わず全ての初回セカンドレベルドメイン申請。カウント単位はメッセージではなく一意な申請であるべきだ。重複、改名された提案、再提出、転送されたケース、仲介レジストリを通じた申請は事前に定義された取り扱いが必要となる。各状態は日付と文書基準を必要とする。欠落したメッセージや電話連絡には保存コードが必要となる。本サンプルにはそのようなカウントを支えるものは何もない。
したがって分母は未定義である。報告された承認率、拒否率、逆転率、平均遅延は存在しない。個別の不服申立の分子も存在しない。この限界は修辞的なものではなく方法論的なものである:散文の確信がいかに強くとも、調査されていない申請ファイルを作り出すことはできない。
混同してはならない三つの管理母集団
残された文書は、関連するが異なるサービスを記述している。それらを組み合わせると、想像上の共通不服申立システムが作られてしまうだろう。
第 1 の母集団はネットワークユーザ登録および TAC アクセスである。1983 年 10 月 20 日付の NIC「Instructions for Network User Registration Drive」は、MILNET および ARPANET のホストを使用する個人と、一部については MILNET 端末アクセスコントローラを通じたアクセスを対象としていた。ホスト管理者は、自分のホストに関連付けられたユーザのテンプレートを受け取り、既存データを修正し、適格なユーザを追加し、削除をマークし、結果をレビューし、資料を NIC に返送した。TAC アクセスの要求は、ホスト管理者のメールボックスを通じた承認が必要だった。
これはスポンサー側およびホスト側の承認システムだった。DDN プログラム管理室(DDN-PMO)は、ローカルホストは政府ガイドラインの範囲内で責任を持って自己管理することが期待されており、問題が発生した場合はホスト管理者と協力すると述べていた。この文言は、DDN-PMO と管理者の間に問題解決チャネルを確立するが、ホスト管理者が承認を拒否した個人に属する権利を確立するものではない。
第 2 の母集団はドメイン登録である。RFC 920 と RFC 1032 は、申請者、責任ドメイン管理者、直属の上位機関、NIC の間で責任を割り振った。技術的な準備、信頼できるサーバ、有能な連絡担当者、組織区分、管理責任が重要だった。NIC は完全性をチェックし、技術的な質問に答えることができた。上位ドメイン機関は、加入について階層的判断を行使した。
RFC 1032 は重要な管轄境界を引いた。それは、組織のために特定のトップレベルまたはセカンドレベルドメインを登録する権利が誰にあるかをめぐる紛争において、NIC は審判として行動しないと述べた。そのような対立は、登録開始前に解決されるべき私的なローカル問題として扱われた。NIC 担当者は技術的ガイダンスを提供できたが、仲裁はしなかった。
この境界は、救済手段が存在しなかったことの証明ではない。それは紛争の場所を他所に置いた:組織内部、上位ドメイン階層、契約関係を通じて、あるいは独立した管轄権を持つ法廷を通じて。しかし RFC 1032 は、代替の審判所を指定せず、意見の相違が真に解決されたかどうかを誰が判断するのかも述べなかった。
第 3 の母集団は数値識別子割り当てである。RFC 1062 は割り当て済みネットワーク番号を公開した。1990 年 8 月発行のRFC 1174は、IANA を数値識別子の割り当ておよび割り振りの第一次的な権限を持つ組織とし、その機能は USC の情報科学研究所(ISI)によって遂行されると述べた。そして、SRI の Internet Registry を、ネットワークに関する情報を収集・登録し、委任された割り当て作業を行うものとして説明した。
数値割り当ては、接続性とも区別されなければならない。RFC 1062 は、インターネットプロトコルを使用する独立ネットワークは、接続インターネットの外側にありながら番号を受け取ることができ、相互接続の許可は別途申請しなければならないと述べた。後に RFC 1174 は、「接続」状態を、連邦政府のスポンサー組織による制裁とし、連邦支援システムにリンクする許可と説明した。
したがって組織は、望む接続を得られないまま一意な番号を取得することができた。スポンサーによる相互接続制裁の拒否は、必ずしも Internet Registry による番号割り当ての拒否ではなかった。可能なレビュー担当者も異なっていた。IANA と Internet Registry は数値割り当ての連鎖を占め、スポンサー機関やバックボーン事業者は接続性の連鎖を占めた。
1992 年 8 月発行のRFC 1359は、キャンパス向けにもう一つの制度的層を追加した。それは、組織が IP サービスプロバイダと協力するよう助言し、プロバイダをアドレスクラスや申請手続きに関する助言の源として説明した。プロバイダは、申請者が準備するのを助けることで不完全な提出を防ぐかもしれない。この文書は、プロバイダがレジストリの決定に不服申立する様子を示してはいない。
したがって、ユーザ登録、TAC アクセス、ドメイン加入、数値割り当て、ネットワーク接続は、異なる申請者、ルール、権限、可能な救済手段を持っていた。ある母集団で文書化された修正は、別の母集団での審査を証明することはできない。
直接的な例外記録:修正と処理継続
本サンプルにおける最も強力な例外証拠は修正に関するものである。
1983 年 10 月 20 日の「Instructions for Network User Registration Drive」は、具体的なシーケンスを定めていた。NIC は、既にその識別データベースに存在する人物のためにテンプレートを準備する。ホスト管理者はそれらのテンプレートを取得し、誤ったデータを修正し、欠落しているユーザを追加し、削除をマークし、結果のリストをレビューし承認して、レジストラに返送する。NIC は提出物を編集し、WHOIS 識別データベースに入力する。
文書はフォーマットについて厳格だった。データは、手作業の編集を減らすために、指定されたテンプレートで返送されなければならず、それ以外の形式の資料は受理されないとされた。これは直接的に文書化された不受理条件であるが、それはユーザ登録データの形式に適用されるものであり、IP アドレスやドメイン申請の実質的な拒否ではない。
指示は重複の扱いにも及んだ。複数のホスト管理者が同じ個人についてテンプレートを提出した場合、NIC は重複を解決する用意があると述べた。これもまた、管理的な品質管理である。この情報源は、競合するスポンサー間の聴聞や申請者の不服申立については記述していない。
TAC アクセスは別個の承認レイヤーを追加した。NIC は、担当ホスト管理者のメールボックスから該当するテンプレートが到着した時点で、申請を承認されたものとみなした。このメカニズムは、制度的関係とオンライン環境を実用的な認証方法として利用した。それは署名入りの紙のフォームを入手する遅延を避け、ユーザに対してホスト管理者に異議を唱える方法を伝えるものではなかった。
したがって、文書化されたシーケンスは以下のとおりである:
既存データ → 管理者レビュー → 修正または追加 → 承認 → 構造化された再提出 → NIC 処理
全ての矢印には定められた管理機能があるが、いずれも以前の実質的な拒否に対する独立した審査ではない。
ドメイン申請は同様に反復的だが、異なる統治の経路を有していた。RFC 1032 は完全な情報を要求し、認可前の数回のやり取りを想定していた。Hostmaster の質問は申請を処理中に留め、申請者の回答は技術的または管理的な不備を修正するかもしれない。後の更新は登録情報を最新に保つことができた。
ガイドは、成功しなかった処理継続がどの時点で拒否になるかを定義しなかった。申請者が Hostmaster を満足させられなかった後に、終了通知を要求しなかった。再審査の窓口や独立したレビュー担当者を設けなかった。これらの省略は、スタッフが結論を説明したり再検討したりしなかったことを証明しない。それらは、公開手続が、対応する通信なしに個々の結果を分類することを歴史家に許さないことを意味する。
RFC 1062 は第三のタイプの修正を提供する:変更されたネットワーク番号である。古い番号は、移行マーカー付きで一時的に可視のままにされることがあり、この公開は、連続性情報が保存される一方で、レジストリ状態が改訂されたことを実証する。しかし、変更の理由、要求者、決定者、不一致の程度は特定されない。
これらの記録は三つの狭い知見を支える。初期の管理は、データが誤り得ることを認識していた。修正された情報が既存の記録を置き換えたり補足したりするメカニズムを提供していた。番号が変更された後、移行中の出力を時として保存していた。
それらは、拒否された申請者、不服申立、逆転を提供するものではない。
逆転マップ
不服申立の調査は、各アクターに記録によって裏付けられた動詞のみを割り当てるとき、より明確になる。一部のアクターは情報を受け取ったり修正したりできた。一部はローカルの提出を承認できた。一部はポリシーを推奨できた。識別子機能に関する権限を保持することは、自動的に上訴管轄権を生み出すわけではなかった。
| アクターまたは機関 | 文書化された能力 | 何が依頼または助言され得たか | 審査または逆転の状態 |
|---|---|---|---|
| NIC および Hostmaster スタッフ | 様式を受領し、完全性をチェックし、通信し、記録を修正し、登録データを維持した | 申請者は技術的および処理上の質問をすることができ、スタッフは不足情報を要求できた | 事務的な修正と処理継続は文書化されている;独立した不服申立義務とケースの逆転は未確立 |
| ホスト管理者 | ユーザ登録テンプレートをレビューし、修正し、承認した;TAC アクセス要求を承認した | ユーザは管理者に提出の修正やスポンサーを依頼できた | ローカルな再審査は可能性があるが、管理者自身の決定に対する中立的な審査は未確立 |
| 上位ドメイン管理者 | 下位ドメインが確立される前に満足させられなければならなかった | 申請者は準備状況を明確化し、階層内での加入を求めることができた | 自らの立場を変更することは可能;独立した上訴レイヤーは文書化されていない |
| NIC マネジメント | サービスメールボックスや第一線スタッフの上位で活動した | サービスの苦情はマネジメントに向けられることができた | 苦情チャネルは役割によって文書化されているが、ケースレビュー規則と逆転義務は未確立 |
| Jon Postel と IANA 機能 | IANA は主要な数値割り当て権限を有し、割り当て作業は Internet Registry に委任された | レジストリスタッフや申請者は数値権限についての明確化を求めることができた | Postel/IANA への申請者向け不服申立ドケットや強制的な逆転手続きは確立されていない |
| DCA と DDN-PMO | DDN 関連の NIC 作業に資金を提供し指揮した;1983 年のユーザ登録プログラムを承認した;問題があればホスト管理者を通じて対応した | 管理者は運用上または承認上の問題を提起できた | プログラムや契約者のパフォーマンスには対応し得たが、一般的な識別子上訴管轄権は未確立 |
| DARPA | 異なる文脈でポリシー、スポンサーシップ、研究プログラム、名前付きドメインの役割を持った | プロジェクト参加者や契約者はポリシーやスポンサーシップの質問を提起できた | 個別の NIC 決定を審査する一般公表された義務は確立されていない |
| 政府スポンサー | 接続状態システムの下で、連邦支援インフラへの接続を制裁した | 申請者はスポンサーシップの確認や更新を求めることができた | スポンサーシップを変更し得るが、それは番号割り当てを必ずしも逆転させるのではなく、接続性に影響を与える |
| インターネット活動委員会(IAB) | ポリシー勧告を策定し伝達した | 連邦ネットワーク機関にシステムポリシーについて助言することができた | RFC 1174 は勧告を証明するが、個別の上訴権限は証明しない |
| 連邦ネットワーク評議会(FNC) | IAB の勧告を受領した | 省庁間のポリシー提案を検討することができた | 採択、実施、拘束力ある指示、申請者ケースの逆転は RFC 1174 によって証明されていない |
| 連邦工学計画グループ | RFC 1174 の中で承認された勧告を策定した | 連邦ネットワーク機関に助言することができた | 個別審査管轄権は示されていない |
| 契約担当官 | 該当する政府契約を管理し執行することができた | 政府職員はパフォーマンスや成果物の問題を提起できた | 運用可能な申請者権利条項や登録結果を覆す権限は確立されていない |
| 裁判所 | 独立して裁判可能な法的紛争を決定することができた | 管轄権と訴訟原因が存在すれば、原告は救済を求めることができた | NIC または IANA の識別子決定の逆転を命じた 1983-1992 年の適格な判決はサンプルに現れない |
| 行政裁決または苦情チャネル | 法律、規則、契約、またはプログラムルールが権限を付与する場合に行動できた | 影響を受ける当事者は、助成または契約機関に苦情を申し立てることができた | 一般的な公表された技術的不服申立や保証された本案審査は確立されていない |
このマップには、依頼する多くの方法と、強制する少ない方法が含まれている。NIC スタッフは、自分たちが維持する記録を修正することができた。ホスト管理者はユーザを承認できた。上位ドメイン管理者はローカルな判断を修正できた。スポンサーは接続に影響するスポンサー決定を変更できた。政府の顧客は契約者のパフォーマンスに対応できた。IAB はポリシー変更を勧告できた。
ここでの証拠に基づけば、それらのいずれの能力も、失敗した登録申請を別の者が審査し、記録された最終決定を下すという、一般的な申請者の権利を創出しなかった。
NIC 職員:公表された第二審のない処理権限
NIC と Hostmaster の担当者は、いくつかのサービスにとって最初の可視的な決定点を占めた。その機能には、様式の受領、必要情報のチェック、質問への回答、データベースの維持、修正の適用が含まれた。ドメイン管理において、彼らは、NIC がレジストラまたは代理人となり、上位ドメイン機関が実質的責任を保持する階層の中で行動した。
公開指示は、処理におけるスタッフのかなりの裁量を支持している。完全性は純粋に機械的な概念ではめったにない。質問票が全てのフィールドを含んでいても、信頼できるサーバ運用や組織的権限を証明できないことがある。スタッフは、さらなる説明が必要であると決定できた。公開ガイダンスは、困難なケースが上級 Hostmaster に割り当てられたのか、集団で議論されたのか、上方に付託されたのかを示さない。
同じスタッフによる再審査は有効であったかもしれない。申請者がより良い証拠を提出し、Hostmaster が立場を変えれば、実際上の問題は解決された。歴史的な分類は依然として以前の記録に依存する。明示された不利な結論がなければ、そのシーケンスは処理継続である。後の理由付けがなければ、何が結果を変えたのかを知ることは不可能である。
1985 年 5 月 17 日発行のNIC KNACKS号「How to Reach the NIC」は、ユーザ支援、コンピュータ運用、WHOIS 更新とユーザ登録、ホスト変更、ニュースレター資料、契約や管理の問題について、差別化されたチャネルを示した。また、リファレンスおよび運用スタッフによってバックアップされたホットラインについても説明した。これはサービスルーティングの証拠である。記録が間違っていると考えた人は修正を送る場所があった。ホストに問題がある人は Hostmaster 機能に連絡できた。より広範な懸念はマネジメントに向けられることができた。
マネジメントのメールボックスは苦情チャネルであり、自動的に不服申立オフィスではない。情報源は、マネジメントが登録決定を再開し、異なる証拠基準を適用し、理由を示し、結果を保存しなければならないとは述べていない。チャネルは優れた非公式の審査を生み出したかもしれない。そのパフォーマンスは測定されないままである。
Postel、IANA、および委任された数値権限
RFC 1174 は、数値権限に関する期間中の最も明確な声明を提供する。それは、IANA がインターネットの運用に必要な数値識別子の主要な権限を持つとし、その機能は USC の情報科学研究所で遂行されると述べた。SRI の Internet Registry を、登録情報を維持し、委任された責任の下で割り当て作業を行うものと説明した。
委任は垂直的な関係を創出するが、その正確な救済上の帰結は、委任条件と実務に依存する。IANA は委任された作業の範囲を定義し、割り当てポリシーを調整し、割り当て権限が誰にあるかという質問に対処することができた。これらの能力は、申請者が SRI レジストリの決定を Jon Postel 個人に不服申立できることを確立するものではない。
レビューされた指示のいずれも、指定期間内に IANA に異議申立を提出し、本案についての決定を受け取るようにとは述べていない。サンプルには、Postel が申請者の拒否を受け取り、元の記録を審査し、異なる割り当てを命じたことを示す申請レベルのケースは存在しない。逆を推測することも同様に安全ではない。Postel の立場と小さなプロフェッショナル・コミュニティは非公式な協議を可能にしたが、可能性は記録された手続きではない。
James Pelkey による1988 年 2 月 18 日の Postel インタビューは、技術的熟議の保存に関する文脈を提供する。Postel は、議論されたが採用されなかった技術的アイデアをめぐる完全な議論が、公開文書に常に捕捉されるとは限らなかったことについて議論した。この観察は技術的アイデアと RFC の歴史に関するものであり、識別子の拒否、不服申立、逆転が同じ方法で取り扱われた証拠へと転用することはできない。
インタビューはしたがって、文書化文化についての警告であり、申請結果の情報源ではない。それは、例外的なケースを再構築する前に対応が必要であることを補強するが、そのようなケースの頻度や公正さについては何も証明しない。
IAB と連邦ネットワーク機関:勧告は判断ではない
RFC 1174 は、インターネット活動委員会(IAB)の議長から連邦ネットワーク評議会(FNC)の議長に宛てられた。それは、識別子割り当ての分配と、旧来の接続状態ポリシーの変更に関する勧告を含んでいた。
メモは、中央集権的な IANA および Internet Registry 機能を保持しつつ、ネットワークおよび自律システム番号のブロックを承認された組織に委任することを推奨した。また、識別子登録を接続状態の制限から分離することを推奨した。Internet Registry はポリシー情報を収集し、DNS の包含はもはや同じ連邦接続承認に結び付けられないことになる。
これは、ポリシーレベルでの制度的再考の真正な証拠である。それは、軍、政府、助成研究環境向けに設計された管理アレンジメントが、成長する商業的かつ国際的なインターネットにもはや適合しなくなったことを IAB が認識したことを示している。また、IAB が FNC に対し、提案された対応を伝達したことを示している。
動詞が重要である。IAB は勧告した。FNC は勧告を受領した。文書は、Internet Registry が変更を行うよう指示されるべきであると提案した。RFC 1174 だけでは、FNC の採択日、実施指令、提案された全ての変更の完了を確立しない。
より重要なことに、メモは申請者ケースを裁定しなかった。それは Hostmaster の理由をレビューせず、識別子を回復せず、以前の拒否の再審査を指示しなかった。ポリシー改革は、影響を受けた人々の名前やファイルを保存することなく、蓄積された問題に対応することができる。それは、以前の結果をそのままにして、将来に向けて運用されるかもしれない。
この区別は、一般的な分析上の誤りを防ぐ。システムポリシーを推奨できる機関の存在は、同じ機関が個別の不服申立を聴取したことを証明しない。逆に、RFC に申請者ドケットがないことは、連邦職員が非公式に介入しなかったことを証明しない。勧告は制度的発言力を確立するが、ケース管轄権を確立しない。
DCA、スポンサー、および登録と接続の違い
1983 年のユーザ登録指示は、DDN-PMO が登録ドライブの背後にいたことを示している。ホスト管理者は承認されたユーザに責任を持ち、DDN-PMO は問題が発生した場合には彼らと協力すると述べていた。これは直接的な問題解決声明であったが、関係は管理者を通じて走っていた。
ホスト管理者と意見が合わない個人は難しい立場に立たされた。DDN-PMO はガイドラインを明確化したり、システム問題に対処したりすることができたかもしれない。文書は、個人が管理者をバイパスして独立した審査を得られるとは約束しなかった。承認者は、ローカルの制度的代表者でもあった。
政府スポンサーシップは、接続性に関して異なる形で重要だった。RFC 1174 の接続状態の歴史は、米国政府スポンサー組織による制裁について述べている。スポンサーは、ネットワークが接続資格を持つことを確認し、支援を撤回し、または資金提供活動の範囲を明確化することができた。そのような行動は、Internet Registry が既に番号を割り当てていたとしても、実質的なアクセスを決定する可能性がある。
スポンサーへのエスカレーションは、したがって正確なラベリングが必要である。スポンサーに適格性を確認するよう依頼することは、数値割り当てに対する不服申立ではない。スポンサーに自らの決定を変更するよう説得することは、スポンサーシップ連鎖内での再審査である。スポンサーにレジストリに連絡するよう依頼することは、制度的アドボカシーかもしれない。直接のケースファイルのみが、いずれが発生したかを確立できる。
連邦契約者や大学にも同じ正確性が当てはまる。契約者は、ネットワーク問題を政府業務への障害として提起することができた。大学の研究者はプログラムオフィサーに支援を求めることができた。軍のホストには管理者とプログラム管理関係が存在した。これらの構造は、照会のための可能な経路を創出した。本サンプルには、それらが結果を変えた頻度を示す比較可能な申請データは含まれていない。
二つの契約連鎖、いずれも自動的な申請者救済ではない
連邦資金は監督を生み出すが、それ自体では不服申立権を創出しない。
第一の関連連鎖はDCA-SRI/NICである。SRI ARC/NIC 検索補助ツールは、DCA が資金提供した NIC の作業、契約提案、成果物、月次報告、進行中レビューを特定している。1987 年の DCA 資料には契約レビュー会議が含まれ、NIC タスクとサービスチャネルが記述されている。これらの記録は、政府顧客が契約者の活動を監視していたことを確立する。
本稿は、全ての登録サービスを管理する実施中の SRI 契約条項を調査していない。したがって、それらの契約が申請期限、記録保持義務、申請者苦情プロセス、または特定の登録判断を覆す契約担当官の権限を課していたとは主張しない。成果物とサービスパフォーマンスの政府監督は、申請者に強制力のある権利を与えることなく、相当に実質的であったかもしれない。
第二の連鎖はDARPA-USC/ISI/IANAである。はるか後に発行されたGAO 決定 B-327398は、GAO が IANA 機能が開発され遂行された 1970 年代-1990 年代の DARPA 契約の写しを入手できなかったが、1995 年に開始された後の契約タスクに関する情報を回収したと報告した。この発見は、初期の DARPA-USC 条件についての結論を制限する。
それは、別個の DCA-SRI 契約記録が欠落していることを確立するものではない。二つの契約者、政府関係、機能は区別されなければならない。SRI コレクションは、NIC パフォーマンスに関する問いに答えるかもしれない契約資料をマッピングしている。GAO の証拠ギャップは、歴史的な DARPA-USC/IANA 契約に関するものである。
契約担当官は、適用可能な契約が実際に含むいかなる義務も執行することができた。その力は通常、政府の契約上の利益を保護するであろう。申請者は依然として、登録問題が契約パフォーマンスの問題となるための経路を必要とするだろう。条項、苦情、政府の行動、結果がなければ、「契約担当官レビュー」は、文書化された救済手段ではなく、可能な制御メカニズムにとどまる。
後に不服申立と称された六つの異なるもの
制度史はしばしば、最初の問題により良い結果が続くあらゆる出来事に対して「不服申立」を用いる。その語彙は、誰が行動し、何が変わったのかを不明瞭にする。
修正は、データや様式を修復する。1983 年のユーザ登録指示は、修正、追加、削除、重複スクリーニング、再提出を直接文書化した。RFC 1032 はドメインデータの更新と反復的な通信を文書化した。修正は争われた決定なしにも発生しうる。
非公式な再審査は、元のスタッフメンバーまたはオフィスが以前の見解を再検討するときに起こる。電話での説明、新たな技術的証拠、組織的権限の明確化が再審査を促しうる。当時の密度の高い連絡インフラはこれを尤もらしくするが、本サンプルにはそれを実証する完全な申請者ケースが含まれていない。
スポンサーエスカレーションは、問題を承認、資金、または接続制裁を提供する組織に移す。スポンサーは資格を明確化し、他機関を擁護し、または自らの立場を変更するかもしれない。結果は、レジストリの決定を覆すことなく、アクセスに影響を与えるかもしれない。
苦情は、サービスの失敗、遅延、不整合、スタッフの行動を報告する。1985 年の連絡シートは、管理問題を通常のサービスチャネルから分離し、より広範な懸念が行き先を持っていたことを示している。それは、苦情が識別子要求を再開するとは述べていなかった。
公表された不服申立は、影響を受ける当事者が指名されたレビュー担当者に対して決定に異議を申し立てることができる、ルールに基づく経路である。通常、異議申立が可能な決定、異議申立の提出先、誰が回答を発するかを特定する。ここで調査された手続サンプルは、1983-1992 年の失敗したドメインおよび数値識別子申請のための、その種の一般に公表された不服申立を特定していない。
強制力のある救済は、法律、契約、または拘束力あるプログラムルールの下で行動を強制できる権限から来る。裁判所、行政機関、または契約担当官は、管轄権、法的利益、適用可能な義務が存在する場合にそのような救済を提供しうる。登録マニュアルはそれを約束せず、サンプルには期間中に NIC または IANA の識別子結果を覆す適格な判決や行政命令が含まれていない。
これらのカテゴリーは、一つの事実上のシーケンスで重複しうる。申請者が様式を修正し、Hostmaster スタッフに再考を依頼し、スポンサーを巻き込み、マネジメントに苦情を言い、最終的に外部の法的請求を追求するかもしれない。ラベルは、シーケンス全体を「不服申立」として扱うのではなく、各段階での証拠に従うべきである。
実用的救済としての電話とアーカイブの盲点
最も強力な善意の代替説明は、NIC のアクセシビリティから始まる。
NIC は電子チャネルを公開し、電話支援を運用していた。RFC 1032 はドメイン認可前の通信を想定していた。1985 年の「How to Reach the NIC」シートは、異なる主題を異なる役割に向け、支援、登録、ホスト変更、運用、マネジメントを含んでいた。検索補助ツールは、電話および電子メールの質問に回答し、月次報告で活動統計を報告するリファレンスおよびホットライン運用について記述している。
小さく、技術的に接続されたコミュニティは、多くの問題を会話で解決したかもしれない。申請者が電話をかけ、サーバの準備ができていないことを知り、構成を修正し、再提出する。ホスト管理者が承認を明確化する。サービスプロバイダがアドレスクラスの要件を説明する。スポンサーが、ネットワークが資金提供活動に含まれることを確認する。
参加者の視点からは、そのような電話は正式な手続きよりも有用だったかもしれない。スピード、文脈、信頼は、非公式の管理を非常に効果的にしうる。
歴史家の視点からは、同じ電話は欠落した遷移である。受信フォームは残っているかもしれない。最終的な割り当ては残っているかもしれない。それらを結び付けた説明は残っていないかもしれない。ケースノートが作成されなければ、研究者は結果が日常的な助言、再審査、スポンサーシップ、または新たな申請の後に生じたのかを判断できない。
電話記録は、残っている場合でも注意深い解釈を要する。通話ログは日付、大まかな主題、発信者クラス、フォローアップが必要かどうかを特定するかもしれないが、申請、助言、権限、最終結果を省略しうる。通話のカウントは、ケースリンケージなしには不服申立のカウントにはなりえない。
電子メールはより多くの詳細を提供するが、完全性の保証はない。メッセージは申請とは別にファイルされるかもしれない。参加者は電話に移行するかもしれない。返信は質問なしに残るかもしれないし、その逆もありうる。スレッドは交渉を記録しながら、最終決定を記載しないままにしうる。
この保存問題は両方向に作用する。それは、審査が決して起こらなかったという主張を妨げる。それはまた、非公式の審査が一貫して機能したという主張も妨げる。連絡インフラは観察可能だが、解決の質はそうではない。
誰が実質的な再審査にアクセスできたのか?
制度上のマップは、分布的な問いを示唆するが、分布的な知見ではない。
軍事ネットワークは、ホスト管理者、連絡担当者、プログラム管理関係、政府スポンサーを持つことができた。連邦契約者は、技術代表または契約連鎖を通じて未解決のネットワーク問題を提起することができた。資金提供を受けた大学は、キャンパス管理者、研究スポンサー、そして 1992 年までには中位ネットワークやサービスプロバイダに頼ることができた。
商業または国際的な申請者もまた、専門家中介者や直接的な職業上の関係を持ち得た。RFC 1174 は、インターネットが元の連邦および助成研究の母集団を超えて拡大したことを明示的に認識した。一部の国際ネットワークは研究協力に深く統合されていた。制度カテゴリーだけではアクセスを決定できない。
仮説は、実質的な再審査が部分的に関係に依存したかもしれないということである:正しい管理者を知っていること、質問ができるスポンサーを持っていること、あるいはレジストリ手続きに詳しいプロバイダを通じて作業すること。この仮説は、文書化されたチャネルが役割ベースで階層的であったため、尤もらしい。
それはテストされていない。サンプルには、軍事、政府、学術、商業、国際の申請者に分割された申請分母が含まれていない。完全性、経過時間、なされた質問、スポンサーの関与、最終結果の比較可能な尺度は存在しない。
信頼できる仲介者が、経験の浅い申請者が正確な申請を提出するのを助けることによって不平等を減少させたかもしれない。彼らはまた、救済を関係性に依拠するものとし、既に管理ネットワークに接続されている機関に利益をもたらしたかもしれない。両方の効果が同時に作用し得る。
防御可能な比較には、申請レベルのデータと、技術的準備、要求されたリソース、スポンサーシップ要件、申請の完全性の統制が必要となる。その証拠がなければ、平等な扱いも不平等な扱いも結果として報告されるべきではない。
技術的階層の外側にある裁判所と機関
裁判所は、あらゆる管理上の不便に対する不服申立デスクではない。それは、法律が管轄権を供給し、請求者が認識可能な利益を持ち、適切な被告に救済を提供するよう命じることができる場合に行動する。
初期のドメイン紛争は、組織的権限、契約、商標、または他の法的利益を含むかもしれない。連邦契約者は、自らの契約の下で権利を有するかもしれない。政府スポンサーの行動は、別個の法律またはプログラムルールの対象となるかもしれない。これらの可能性は、識別子フォームを超えた事実に依存した。
当時の技術ガイドは、失敗した申請者が裁判所に Hostmaster の技術的判断の審査を求めることができるとは述べていなかった。それらはまた、全ての NIC または IANA の行動が最終的な行政処分であることを確立しなかった。契約者ステータス、委任された技術的権限、連邦スポンサーシップ、政府資金は、単一の公法カテゴリーに崩壊しない。
行政チャネルも同じ注意を要する。DCA、DARPA、DDN-PMO、または他の連邦機関は、そのプログラムまたは契約責任の範囲内で苦情を受領することができた。それが申請者の請求を決定しなければならないのか、契約者に登録変更を強制できるのか、あるいは何らかの強制力ある救済を提供するのかは、準拠する権限に依存する。
本サンプルには、識別子拒否とそれを覆す裁判所の判決、行政命令、または契約決定をペアにする、1983-1992 年の直接記録は存在しない。外部救済は抽象的に法的に可能なままであり、関連するケース母集団において歴史的に未証明である。
反実仮想 A:決定を保存し、理由を付加する
1983 年から 1992 年までの全ての実質的な識別子と接続の決定が変更されなかったと想像せよ。同じ完全な申請が成功し、同じ技術的欠陥が修正を必要とし、同じスポンサールールが連邦支援インフラへのアクセスを管理した。
記録のみを変更せよ。各一意な申請に受領日と耐久性のある識別子を与えよ。処理が止まったときには、短い理由と責任オフィスを保存せよ。同じオフィスが再考する場合には、第二の決定を第一のものにリンクせよ。問題がスポンサー、IANA、マネジメント、または別の権限に移る場合には、紹介と最終結果を記録せよ。
そのような記録は、承認率が動かなくても監査可能性を改善するだろう。研究者は、欠落フィールドを実質的な拒否から区別できるようになる。再申請は、修正、置き換え、または再審査として識別できる。経過時間は、申請者の応答、スタッフ処理、スポンサーレビュー、未解決期間に分割できる。ポリシー変更は、問題を露呈したケースのタイプにリンクできる。
追加の記録は、誤り検出を改善するかもしれない。比較可能な理由は、一貫性のない分類を示すかもしれないし、あるいは明らかに異なる結果が異なる事実に基づくことを示すかもしれない。それは可能性であって、測定された歴史的効果ではない。
近代的な行政法の義務が既に全ての初期インターネット登録を管理していたとは主張されない。この反実仮想は、より狭い制度上の問いを投げかける:同時代の人々や後の歴史家が、基礎となる権限構造を変更することなく一貫性をテストすることをどのような証拠が許したであろうか?
日付の入った理由と結果のログ自体は独立性を創出しないだろう。レビュー担当者は依然として同じオフィスに属するかもしれない。また、公平性を保証するものでもない。それは、評価可能なほどに経路を見えるものにするだろう。
反実仮想 B:真に低い対立
今度は、第一審の管理が通常は正確であったと仮定せよ。申請者は技術的能力を持ち、要件は広く理解されており、ほとんどの問題は信頼できる通信を通じて解決された。実質的な拒否や深刻な紛争は稀だった。
そのような良性のシステムは、どのような痕跡を残すべきか?
ほとんどの不完全な申請の後には、特定可能な質問と迅速な修正が続くだろう。再提出は通常、可視的な技術的または管理的な変更に対応するだろう。完了後の経過時間は短いか、サーバの準備、スポンサーシップ、その他の外部依存によって説明されるだろう。スポンサー接触は、以前の判断を置き換えるよりもむしろ、しばしば適格性を明確化するだろう。苦情の痕跡は、既知の申請母集団と比較して稀だろう。
取下げられた申請は、沈黙の拒否から分離されるためには、申請者側の説明を必要とするだろう。電話解決は、通話を申請にリンクする同時代のメモを必要とするだろう。統計的に防御可能なサンプルは、完全性と技術的準備を統制した後では、未解決の不一致がほとんどないことを示すべきである。
良性のインフラの一部は可視的である。RFC 1032 は通信を期待した。NIC は支援と管理チャネルを維持した。ホスト管理者はユーザ記録を修正できた。DDN-PMO は問題があれば管理者と協力すると述べた。RFC 1359 はプロバイダを申請アドバイスの源として扱った。RFC 1174 は、接続制裁を分離しながら広く一意な番号を割り当てることを意図したポリシーを記述した。
観測されないままなのは、それらのチャネルがどのように機能したかである。一意な申請の数は不明である。情報のために差し戻された数、取下げられた数、拒否された数、再審査された数、エスカレーションされた数、逆転された数も同様である。発信者クラスや最終結果の比較は存在しない。
失望した申請者が消え去ったシステムは、深刻な対立がほとんどないシステムと同じ公開割り当てリストを生成しうる。区別する証拠は、登録簿のクリーンさではなく、申請通信と処分記録にある。
1992 年以降への狭い視野
1993 年 3 月に発行されたRFC 1400は、期間後の限定的な比較を提供する。それは、登録テンプレートの解析と検証、元の申請者による修正、7 日間の応答窓口後の失効、トラブルチケット番号、チケットが保留中かどうかと誰が対応しているかを示す公開ステータス情報について記述していた。
これらの機能は、処理状態をより観察可能にした。それらは独立した上訴機関を創出しなかった。パーサーエラー、検証、修正、最終的なスタッフ処理は、独立した権限による審査ではなく、管理の一部にとどまった。
この比較は、ただ一つの結論のみを支持する:公開手続は申請識別子と中間状態を露出し得た。1993 年のその登場は、それ以前の内部追跡がなかったことを証明せず、実質的な紛争がどのように審査されたかにも答えない。
結論として
三つの命題は分離されたままでなければならない。
第一に、ここで調査された公開手続は、1983 年から 1992 年の期間中、失敗したドメインまたは数値識別子申請のための、一般的で独立した不服申立窓口を特定しなかった。それらは申請、責任管理者、技術的要件、修正、通信、ローカル紛争の境界、制度的権限を規定したが、指名された第二審のレビュー担当者と記録された最終決定への一般的な申請者経路を確立しなかった。
第二に、非公式な解決は制度的に可能であり、通常の問題については尤もらしい。NIC は到達可能だった。スタッフは通信を期待した。管理者とスポンサーは定義された役割を占めた。プロバイダは申請者に助言できた。マネジメントと政府機関は、その責任の範囲内で懸念を受領できた。これらのチャネルは多くのケースを迅速に解決したかもしれないが、サンプルはそれらの使用や結果を測定しない。
第三に、分母は依然として不明である。サンプルには、不完全、遅延、取下げ、拒否、修正、再審査、エスカレーション、逆転、最終のケースを数えるための申請レベルのコーパスが含まれていない。適格な拒否と逆転のファイルも含まれていない。証拠の欠如は、組織的な虐待の告発も、実証された一貫性の主張も妨げる。
初期インターネットの管理者たちは、急速に変化する技術的および制度的境界を越えて、困難な調整問題を解決していた。システムは有能で協調的でありながら、弱い手続的アーカイブを残すことがあり得る。それは、その行為を再審査と名付けずに誤りを修正できた。それは個別の不服申立を聴取せずにポリシーを変更できた。それは、後の歴史家が評価できない関係を通じてその支援を分配しながら、効果的な支援を提供できた。
したがって、欠落した不服申立デスクは、特定のオフィスが存在すべきだったが存在しなかったことの証明ではない。それは、通常の経路が失敗した後に何が起こったのかを決定するために必要な、理由、レビュー担当者、結果の欠落した連鎖である。
目に見える対立が低いことは、良好な管理を反映しているかもしれない。それは私的な解決を反映しているかもしれない。それは、残存する記録から消えた申請者を反映しているかもしれない。直接の申請ファイルが分母を提供するまで、これらの説明は分離されたままでなければならない。
出典
- RFC 810, “DoD Internet Host Table Specification,” 1 March 1982:https://www.rfc-editor.org/rfc/rfc810.html
- RFC 920, “Domain Requirements,” October 1984:https://www.rfc-editor.org/rfc/rfc920.html
- RFC 1032, “Domain Administrators Guide,” November 1987:https://www.rfc-editor.org/rfc/rfc1032.html
- RFC 1062, “Internet Numbers,” August 1988:https://www.rfc-editor.org/rfc/rfc1062.html
- RFC 1174, “IAB Recommended Policy on Distributing Internet Identifier Assignment and IAB Recommended Policy Change to Internet ‘Connected’ Status,” August 1990:https://www.rfc-editor.org/rfc/rfc1174.html
- RFC 1359, “Connecting to the Internet,” August 1992:https://www.rfc-editor.org/rfc/rfc1359.html
- RFC 1400, “Transition and Modernization of the Internet Registration Service,” March 1993:https://www.rfc-editor.org/rfc/rfc1400.html
- Network Information Center, “Instructions for Network User Registration Drive,” 20 October 1983, internal pages 1-7, digitized bundle pages 67-73 inDefense Communication Agency Materials; 6 of 13:https://archive.computerhistory.org/resources/access/text/2023/07/102707743-05-06-acc.pdf
- DDN Network Information Center, “How to Reach the NIC,”NIC KNACKS, Number 2, 17 May 1985, digitized bundle page 94 inDefense Communications Agency Materials; 3 of 13:https://archive.computerhistory.org/resources/access/text/2023/07/102707743-05-03-acc.pdf
- Computer History Museum,Guide to the SRI ARC/NIC Records, collection X3578.2006, 2011:https://archive.computerhistory.org/resources/access/text/finding-aids/102706170-SRI/102706170-SRI.pdf
- James Pelkey, interview with Jonathan “Jon” Postel, recorded 18 February 1988:https://archive.computerhistory.org/resources/access/text/2016/05/102738139-05-01-acc.pdf
- US Government Accountability Office, B-327398, “Department of Commerce—Property Implications of Proposed Transition of U.S. Government Oversight of Key Internet Technical Functions”:https://www.gao.gov/products/b-327398

