要約
- 調査した RFC および RIPE 資料の中で最も古い公開数量表は、1992 年 10 月の RFC 1366 である。RFC 1174 は、Internet-Number-Template が 1990 年 8 月までに既に存在していたことを確認しており、1990 年以前のアドレスフォームやマニュアルは網羅的に検索されていない。
- 公表されたルールと運用通信は、次第に把握可能になる入力、量的参照点、パーサチェック、修正手続き、秘密のエンジニアリング計画、明示された例外、そして最終的には不服申立権を文書化している。それらは手続き設計とレジストリ慣行を記述しているが、発見された記録は特定の要求がどのように結末したかを示していない。
- レビューされた実務証拠は、4 件の完全な申請事例ではなく、1 件の部分的な要求議論と 3 件の運用的または制度的観察から成る。元の申請、同時代の基準、修正、理由、最終割り当て、レビュー、結果を変える救済をつなぐ完全な連鎖は特定されておらず、一貫性や成功率・拒否率は未測定のままである。
1994 年 3 月 22 日、PIPEX の Keith Mitchell は、ヨーロッパのローカルレジストリのグループに、アドレス空間に関する厄介な正当化をどう処理すべきか尋ねた。PIPEX は、Mitchell が「いくつかの登録要求」と呼んだ、不特定多数のクラス C ネットワークの要求を受け取っていた。提案された各ネットワークには、明らかに 5〜6 台のホストしか含まれていなかった。そのような状況での PIPEX の通常の対応は、おそらく 1 つか 2 つのクラス C ネットワークを割り当て、サブネット化を推奨することだった。
申請者の述べた障害は技術的なものだった。Mitchell の説明によると、Novell サーバ用のルーティングソフトウェア、または同社の LAN WorkPlace 製品はクラス C 空間をサブネット化できなかった。その前提が正しければ、物理セグメントごとに 1 つのネットワークを割り当てることで、申請者のシステムの運用が容易になるかもしれない。しかし、それは PIPEX の通常のアプローチよりも多くのネットワーク番号を消費することになる。Mitchell は、ローカルレジストリとしてこの制限に対応すべきか、それともベンダーの問題として扱うべきかを尋ねた。
議論はすぐに事実確認になった。Ian Harding は Novell NetWare Supervisor's Guide を指摘し、サンプル構成がサブネット化をサポートしていることを示唆した。Bob Day は「合理的な」即時割り当てを提案し、同じ説明が後の要求ではあまり重視されないという警告を添えた。John Williams はサブネット化されたクラス C 空間を使用したインストールを説明し、プロキシ ARP が関連するアドレス解決問題に対処したと述べた。別のメッセージでDay は、述べられた理由を拒否しつつ、Novell の連絡先を通じて明確な回答を求めるよう助言した。
これは、主張されたソフトウェア制限に対するピアレビューであり、完了した割り当て事例ではなかった。アーカイブには、申請書、申請者の身元、正確な要求数量、ソフトウェアバージョン、ネットワーク図、成長予測、後の修正、グローバル経路集約への影響の評価が欠けている。やり取りは、理由のある処分、割り当て、拒否、レビュー、救済の前に終わっている。
それでも、このやり取りは重要な管理上の瞬間を捉えている。ローカルレジストリは、申請者が提供したからといって技術的な正当化を単に受け入れたわけではなかった。オペレータは主張を文書や実際の経験と比較した。彼らは暫定的な対応を検討し、機器ベンダーが調整コストの一部を負担すべきかどうかを考えた。技術的判断は、完全に私的な会話ではなく、同僚の目の前で行使されていた。
結末が欠けているため、断片はより大きな重みを持つことができない。「合理的な」数量を割り当てるという助言は、数量も結果も提供しない。他の場所での成功した構成は、製品能力に関する広範な主張を弱めるかもしれないが、特定のインストールを変更するコストは未解決のままである。理由を拒否する助言は、要求の拒否ではない。申請者は計画を修正したり、さらなる証拠を提供したり、より小さなブロックを受け入れたり、問題を放棄したかもしれない。開かれた記録はそれらの経路のどれも選択できない。
その境界が歴史的な問いを形作る。ここで検討した期間中、公開フォームと数値ガイダンスは、申請者が開示すべきことを明らかに変えた。一部の事務段階は機械可読で修正可能になった。表は、逸脱が認識できる参照点を作り出した。より難しい問題は、それらの手段が最終判断を定期的に制御したかどうかである。それに答えるには、ガイダンス文書だけではなく、トランザクションが必要である。
この調査の対象範囲
この記事のためにレビューされた公開コーパスには、割り当て番号記録；識別子ポリシー、アドレス管理基準、実装スケジュール、登録処理、レジストリ慣行に関する RFC；RIPE 要求フォームとバージョン発表；選択された RIPE 会議議事録；そして詳細に検討された 4 つの運用的または制度的成果物が含まれる。
RFC シーケンスは、1988 年の割り当て番号記録からRFC 1174、RFC 1366、RFC 1367、RFC 1400、RFC 1466、RFC 1467、RFC 2050に至る。主な申請者向けフォームはRIPE-095とその直接の後継である RIPE-098 である。4 つの実務成果物は、PIPEX の議論、1993 年 3 月 19 日の割り当てと更新管理に関する通知、Daniel Karrenberg による 1993 年 5 月の保守的な割り当て慣行の説明、そしてRIPE-18 議事録である。
これは限定された公開情報源の調査である。アドレス固有の以前のマニュアル、テンプレート、覚書、通信は網羅的に検索されていない。Computer History Museum のSRI ARC/NIC 記録のガイドは、初期の 1990 年代まで及ぶ、より広範な機関史をカバーする 281 箱を特定している。このガイドは、保有可能性の地図であり、未調査のフォームの内容や使用に関する証拠ではない。
したがって、見出しの「最初」は監査中の問いである。RFC 1174 は、Internet-Number-Templateが 1990 年 8 月には既に最新のものであったことを立証している。調査された RFC および RIPE 資料の中で最も古い公開数量表は、1992 年 10 月の RFC 1366 に見られる。この発見は、より以前のフォーム、マニュアル、指示が年代を変える余地を残している。
実務の分母にも同様の抑制が必要である。4 つの成果物は 4 つの完了した事例ではない。1 つは不特定の「いくつか」の要求に関する部分的な議論であり、他は運用管理通知、担当者の例示的な説明、未確認の報告の会議記録である。申請、修正、許可、拒否、制限されたファイルのより広い母集団は、レビューされた資料において信頼できる数がない。
アドレス要求内部の 11 の段階
「処理」のような一語は、管理上異なるいくつかの出来事を隠している。文書は 11 の段階を開示しており、ある段階に必要な証拠を別の段階から単純に借用することはできない。
提出は、要求を担当窓口に回付することから始まる。正しい宛先は、日付、地域、ネットワーク所属、リソースタイプ、および委任されたレジストリの有無によって異なった。誤ったメールボックスに送信されたメッセージは、誰かが技術的必要性を検討する前に転送されるか返送される可能性があった。
構文は、要求の表現形式に関わる。機械または事務員がテンプレートを認識し、その内容を解析する必要があった。古いフォームや形式不正のフィールドは、根本的なネットワーク計画が健全であっても、トランザクションを中断させる可能性があった。
完全性は、提出物が評価に必要な入力を含んでいるかどうかを問う。手段に応じて、それらの入力には現在および予測されるマシン数、サブネット数、既存の保有数、接続計画、トポロジ、ルーティング構成、責任ある連絡先が含まれていた。追加情報の要求は、実質的な問題を未解決のままにする。
技術的必要性は、ネットワーク設計そのものを扱う。担当者は、提案されたすべてのマシンがグローバルに一意なアドレスを必要とするかどうか、クラス C ネットワークのブロックでクラス B を代替できるかどうか、サブネット化が実用的かどうか、そして予測が信頼できる計画に基づいているかどうかを判断しなければならなかった。
グローバルルーティングまたは集約の懸念は、申請者の内部ルーティング問題とは異なるレベルに属する。断片化された経路広告は、インターネット全体のルータとオペレータにコストを課す。PIPEX の議論における Novell の制限の主張は、申請者自身の構成に関するものであり、残されたスレッドにはグローバルな集約の評価が含まれていない。
例外は、通常の基準からの逸脱である。分散したトポロジは、ホスト総数だけが示す以上のネットワーク番号を必要とする可能性がある。機器の制約が提供されることもあるが、担当者はその前提に異議を唱えることができる。公表された例外カテゴリは、たとえ結果としての事例が公開されなくても、裁量のための関連する根拠を狭める。
理由は、要求がなぜそのように動いたかを説明する。パーサエラー、予測の欠落、クラス C 空間がニーズを満たせるとの判断は、異なる説明である。理由記録は、受け入れられた事実と適用可能なバージョンを手続き的または実質的な対応に結びつけるだろう。
修正により、要求者は提出物を修復、明確化、または補足できる。それには、パーサの解釈の修正、エンジニアリング計画の提供、または予測の更新が含まれる場合がある。修正は最初のプロセス内で行われ、最終的な割り当ての問題には触れない可能性がある。
結果は、管理上の処分である：要求どおりの許可、別の数量または形式での許可、参照、情報提供のための遅延、取り下げ、拒否、または未解決の状態。割り当てられたブロックを示す後のエントリは、その履歴の一部のみを明らかにする。
レビューは、割り当てレジストリ、親レジストリ、または他の認可されたレベルによる再検討である。その証拠には、異議が申し立てられている決定、レビュー担当者に提供されたファイル、およびレビュー担当者の評価が含まれるだろう。
救済は、レビューが達成したことを記録する。決定は支持されるか、変更されるか、さらなる作業のために差し戻されるか、または別の処分に置き換えられる場合がある。レビューの存在それ自体は、結果が動いたかどうかについて何も語らない。
PIPEX スレッドは、提出、技術的必要性評価、主張された例外、およびピアによる事実確認に達している。その正確な到達範囲を説明することは、それを不完全な事例と呼び、欠けている段階を頭の中で補うよりも有用である。
公開数量表以前
レビューされた一連の資料の中で最も初期のものは、公開された割り当て式を明らかにする前に、運用中の番号レジストリを示している。
RFC 1062『Internet Numbers』は、1988 年 8 月に公式の状況報告として発行された。それは、SRI International によって運用される DDN Network Information Center の Hostmaster を、最新のネットワーク番号情報の情報源として特定した。この文書は、割り当てられたネットワーク番号、自律システム番号、および責任ある連絡先を一覧にした。それは、研究、防衛、政府、および商業環境を区別しつつ、独立した番号のネットワークは別途相互接続許可を求める必要があると述べていた。
その分離は見落としがちである。登録は一意性と連絡先情報を提供し、自動的に接続性を付与するものではなかった。割り当て番号リストはまた、この期間を通じて持続する可視性の不均衡を示している。完了した割り当ては耐久性のある公開記録に入ったが、取り下げられた、リダイレクトされた、または拒否された要求は対応するエントリを残さない可能性がある。登録簿は、元々要求された数量、提供された証拠、または選択されたアドレスクラスの背後にある理由を再構築できない。
1990 年 8 月までに、RFC 1174は「最新の Internet-Number-Template」に明示的に言及した。Vinton Cerf がこの情報文書を執筆し、それは Internet Activities Board の公式見解を代表し、Federal Networking Council への勧告を伝達した。
RFC 1174 は、IANA を University of Southern California の Information Sciences Institute によって遂行される機能として説明した。それは、IANA が数値ネットワークおよび自律システム識別子に関する責任を、DDN-NIC で SRI International によって運用されるインターネットレジストリに委託したと述べた。推奨されるアーキテクチャは、中央の IANA およびインターネットレジストリ機能を保持しつつ、承認された組織がブロックを受け取り、さらに割り当てを行うことを許可した。
2 つ目の勧告は、ますます厄介になっていた「接続」ステータスの概念に対処した。RFC 1174 は、登録フォームから接続ステータスの参照を削除し、許容可能な使用、アクセス、トランジットポリシーに関する情報を追加し、登録されたネットワークをドメインネームシステムに、そのステータスを決定的な条件とすることなく参加させることを提案した。国およびトラフィックポリシーフィールドは、既存のテンプレートへの提案された変更の一つだった。
これらの勧告は、識別子登録とネットワークアクセスポリシーの執行との違いを明確にした。また、フォーム設計が既に制度的ポリシーの手段であったことを示している。この RFC は、当時流通していた正確なテンプレートバージョンを再現せず、その提案された変更の運用的採用の日付も示していない。そのフィールドは定性的かつ管轄に関するものであり、需要をアドレス数量にマッピングするスケジュールではなかった。
1992 年 10 月：数値的参照点
RFC 1366『Guidelines for Management of IP Address Space』は、1992 年 10 月に Merit の Elise Gerich によって発行された。それは情報提供であり、インターネット標準を指定するものではなく、アドレス管理の計画を提案し、後に RFC 1466 によって廃止された。
提案された地域構造は、制度的資格に結び付けられていた。地理的領域のネットワーキング権威は、候補レジストリを正当化することになっていた。組織は確立されており、レジストリ機能の外部で正当性を有するべきである。それは、安定し、タイムリーで、信頼できるサービスのための十分なリソース、IANA およびインターネットレジストリのガイドラインに従うコミットメント、ならびに資格およびサブ割り当て戦略についてインターネットレジストリと調整する意思を必要とした。インターネットレジストリは、ルートであり、認められた委任者のいない地域のためのデフォルトであり続けた。
これらの規定は、技術的委任を地域的な地位と組織的能力に結びつけた。番号のブロックだけでは、オフィスを資格のある地域レジストリにはしなかった。同時に、基準は予期的に述べられており、RFC 1366 には、各候補がどのようにそれらを満たしたかについての継続的な評価は含まれていない。
この文書は、クラス B 検討に強い制限を課した。組織は、2 つの結合条件を満たすことが期待された：32 以上のサブネットと 4,096 以上のホストを文書化するサブネット化計画。RFC 1366 は、後の 24 ヶ月の文言を両方のクラス B しきい値に付加しなかった。また、クラス C ブロックがクラス B を実際的に置き換えられない状況を認め、それらの状況がケースバイケースで考慮されることを許可した。
クラス C 空間について、RFC は、加入者の 24 ヶ月にわたる必要な一意の IP アドレスの予測を、連続したブロックにマッピングした：
- 256 未満のアドレスは 1 つのクラス C ネットワークにマップされた
- 512 未満は 2 つの連続するクラス C ネットワークにマップされた
- 1,024 未満は 4 つにマップされた
- 2,048 未満は 8 つにマップされた
- 4,096 未満は 16 にマップされた
単位は予測される一意の IP アドレスであった。それは従業員、顧客、物理サブネット、または従来の使用可能なホストスロットの数ではなかった。クラス C ネットワークは、通常のホスト構成がネットワークおよびブロードキャストの値を予約するものの、256 の数値アドレス値を含んでいた。
字義通りの文言には未解決の端がある。すべての行が「未満」としており、256、512、1,024、2,048、4,096 といった正確な 2 の累乗は、書かれたとおりに行の外に残る。文書内の他の場所の例は、意図された規模を明らかにする助けにはなるが、表を書き換えるものではない。それを公開参照点と呼ぶことは、それを完全なアルゴリズムと呼ぶよりも正確である。
ある行内では、申請者と担当者は同じ需要の地平線とブロックサイズを参照できるようになった。受け入れられた予測が 1,024 アドレスを下回る場合、公開された行は 4 つの連続するクラス C ネットワークを指す。異なる数量はその行から逸脱するだろう。RFC 1366 は、そのような逸脱に対してケース固有の説明を公表する一般的な義務を課しておらず、受け入れられた予測は非公開のままかもしれない。それでも、表は決定の語彙を狭めた：数量は明示されたベースラインと比較することができた。
残りの作業の多くは、どの入力が信頼できるかを判断することにあった。2 年間の予測は、慎重に導き出されたものか、あるいは願望的なものであり得た。一部のマシンはプライベートまたは非一意の空間を使用するかもしれない。物理的トポロジは、通常のブロックを扱いにくいものにするかもしれない。担当者は依然として技術的証拠を評価する必要があったが、彼らの判断は今や目に見える数値スケジュールの周りで行われた。
付随するRFC 1367は、1992 年 10 月に C. Topolcic によって執筆され、実装スケジュールを提案した。それは、1992 年 10 月 31 日からの手続きの継続、1993 年 2 月 14 日のレビュー、そして 1993 年 4 月 15 日からのアドレッシング計画の下での適切なサイズのクラス C ブロックでの割り当てを求めた。
後の状況報告であるRFC 1467は、1993 年 8 月にそのスケジュールを置き換えた。Topolcic は、ほとんどの管理マイルストーンが時間通りに実施されたと報告したが、CIDR ソフトウェアの配信とインストールは除かれた。報告は、RIPE NCC が地域ブロックを受け取り、インターネットレジストリが 1993 年 4 月 15 日に計画の下で適切なサイズのクラス C ブロックでの割り当てを開始したと述べた。
RFC 1467 は、プログラム内部からの意味のある同時代の証拠である。その説明は、主要な管理マイルストーンが達成されたという帰属する発見を支持する。それは、申請ファイルの検査ではなく、制度的自己報告にとどまるが、その情報源の境界は、それが記録する運用的発展を消し去るべきではない。
InterNIC 境界における事務的規則性
1993 年 3 月、RFC 1400『Transition and Modernization of the Internet Registration Service』は、異なる種類の手続きを記述した。Network Solutions の Scott Williamson が、National Science Foundation の情報サービス賞の後の非 DDN 登録サービスの移行中に、この情報文書を執筆した。
制度的境界は具体的だった。RFC 1400 は、「InterNIC」をその登録サービス構成要素を意味するものとして使用した。DDN ユーザーは、別の経路と承認されたフォームを通じて DDN-NIC から登録サポートを受け続けた。非 DDN ユーザーにとっては、既存の DDN-NIC テンプレートを 1993 年 3 月中に提出することができた。新しい InterNIC テンプレートは 4 月 1 日に有効になった。古いフォームを自動メールボックスに送信すると、解析エラーメッセージと新しいテンプレートが添付されて返送され、一方、人間の Hostmaster 経路では 6 月 30 日まで一時的に古いフォーマットを受け付けた。
自動化されたシーケンスは、いくつかの管理イベントを視界にもたらした。要求者は、記入済みのテンプレートを自動メールボックスに送信した。メールサーバはそれを解析し、検証可能な情報の簡単なチェックを行い、ドメイン名の競合が例として挙げられた。それは、検証またはエラーメッセージを伴う拒否のいずれかを返した。
次に要求者は、情報がどのように解釈されたかを確認した。不正確なデータは、検証が返される前に修正することができた。拒否の後、要求者は登録要求を調整して再提出することができた。修正された検証は再度チェックされた。登録サービスが満足のいく検証を受け取ると、要求は最終処理のためにスタッフに回された。未回答の検証は 7 日後に期限切れとなり、再提出が必要だった。トラブルチケット番号が状況照会をサポートした。
これらのメカニズムは、具体的な方法で事務的処理を制約した。それらは、システムがどのフォームを受け入れたかを開示し、解析問題を露呈させ、解釈された情報の確認を求め、要求者に状況追跡のための参照を与えた。古いフォームは静かにキューに消えることができなかった。機械可読なエラーは、それを稀少性に関する最終判断として提示することなく修復することができた。
自動化の範囲も同様に具体的だった。パーサは表現と検証可能な情報を扱い、スタッフは最終処理を保持した。RFC 1400 は、2 年間の予測の評価、ブロックサイズの選択、またはトポロジが例外を正当化するかどうかの判断を機械に割り当てなかった。したがって、自動化された「拒否」のカウントは、基礎となるトランザクションが分類されない限り、事務的イベントと、現代の読者が拒否と呼ぶかもしれないものとを混在させるだろう。
Network Solutions のプロセス記述として、RFC 1400 は、独立してサンプリングされたパフォーマンス測定値ではなく、請負業者の設計されたシーケンスを記録している。それでも、手続き史への貢献は実質的である。1993 年までに、登録経路の重要な部分は、解析、検証、修正、期限、追跡が可能なほど十分に標準化されていた。
エンジニアリング計画と構造化された逸脱
RFC 1466は、1993 年 5 月に Merit の Elise Gerich によって発行され、RFC 1366 を明示的に廃止した。情報提供の後継は、分散レジストリフレームワークを保持し、申請者に期待される証拠をより具体的にした。
クラス B 検討には依然として、32 以上のサブネットと 4,096 以上のホストが必要とされた。さらに、申請者は、クラス C ネットワークのブロックでネットワークを構築することがなぜ不合理であるかを説明するエンジニアリング計画を提出しなければならなかった。計画は、次の 24 ヶ月間にネットワークが持つホスト数と、同じ期間に各サブネットに現れるホスト数を述べることになっていた。
エンジニアリング計画は、厳格な秘密として保持され、申請が正当化されるかどうかを判断するためだけに使用されることになっていた。ホストとサブネットの証拠がクラス B を正当化できない場合、申請者はクラス C アドレスのブロックを受け取ることになった。したがって、ルールは単純な許可か拒否かの選択ではなく、代替割り当て経路を記述していた。
クラス C の表は上向きに拡張された。8,192 未満のアドレスは 32 のクラス C ネットワークにマップされ、16,384 未満は 64 にマップされた。行が引き続き「未満」を使用していたため、同じ正確な境界の曖昧さが残った。
RFC 1466 はまた、トポロジの例を提供した。10 つの Ethernet に均等に分散された 600 のホストは、エンジニアリング計画がデフォルトの表からの逸脱を支持する場合、各 Ethernet に 1 つずつの 10 のクラス C ネットワークを受け取ることができた。レジストリは、サブネット化の失敗が法外な浪費を生む場合に計画を要求することができた。例外はケースバイケースで決定されることになっていた。
この組み合わせは、構造化された裁量の認識可能なアーキテクチャである。表は、受け入れられた需要と数量の間の通常の関係を述べた。例は、トポロジを逸脱のための関連する根拠として特定した。エンジニアリング計画は、担当者がその根拠を検証するための証拠を与えた。機密性は申請者の内部設計を保護した。
監査言語は、定義された階層の内部で作用した。インターネットレジストリは、地域レジストリに小さなクラス B ブロックを割り当て、それらのブロックからの割り当ての説明を要求し、申請者のエンジニアリング計画を受け取り、それらの計画のガイドラインとの一貫性を監査することができた。テキストは権限と証拠の経路を確立するが、指名された割り当てを変更した監査を特定しない。
合わせると、1992 年と 1993 年のガイドラインは、いくつかの実質的な選択をより議論の余地があるものにした。申請者はデフォルトの行を指し、なぜトポロジがそれを置き換えるのかを説明し、クラス B の主張には組織的規模以上のものが必要であることを知ることができた。しかし、最も機密性の高い証拠は、公的な比較の外に留まるように設計されていた。
14 日間有効だったフォーム
RIPE-095 欧州 IP ネットワーク番号申請フォームおよびサポートノートは、このポリシーの多くを、申請者が記入できるフィールドに変換した。Anne Lord と Daniel Karrenberg がこの文書を執筆し、RIPE-088 の更新として 1993 年 10 月 1 日に発行した。
フォームには 1993 年 12 月 30 日の有効期限が印刷されていた。その日付は、それが最新バージョンであり続ける期間を決定しなかった。RIPE-098 の 10 月 15 日の文書発表は、改訂されたフォームが RIPE-095 を廃止し、ローカルレジストリが 32 以上のクラス C ネットワークの申請について RIPE NCC に相談することを推奨することを追加したと述べた。したがって、RIPE-095 は 14 日間、最新の公開フォームであった。
その 4 部構成は、異なる種類の証拠を分離した。
パート A は、ネットワーク名、組織説明、国、管理および技術連絡先、変更情報、および人物記録を収集した。これらのデータは、割り当てられたネットワーク番号と共に、公的にアクセス可能なレジストリを意図していた。
パート B は、機密の技術情報を収集した：要求タイプ、現在、1 年後、2 年後のマシン数、現在、1 年後、2 年後のサブネット数、インターネット接続計画、既存の IP ネットワーク保有、およびネットワークが運用される国。
パート C は、2 つ以上のクラス C ネットワークを求める申請者に対して、ネットワーク記述を要求した。申請者は、サブネットサイズや関連するネットワークコンポーネントを含む、現在のレイアウトと次の 2 年間の計画を記述することになっていた。より大きな要求は、より多くの詳細を求めた。
パート D は、別の組織を代表して行動する代表者を特定した。これは、フォームに記入する人、サービスプロバイダ、申請組織、およびアドレスの最終使用者が異なる役割を占める可能性があるために重要だった。
フォームの数値例は、従来の使用可能なホスト数を使用した。1 つのクラス C は最大 254 ホスト、2 つは 508、4 つは 1,016、8 つは 2,032、16 は 4,064、32 は 8,128 と関連付けられた。これらの数値は、RFC 1366 のしきい値が 256、512、1,024 などの生のアドレス数量として表現されているのとは異なる。関連するバージョンに対して申請を再構築する際には、「マシン」、「使用可能なホスト」、「アドレス」を区別しておかなければならない。
RIPE-095 はまた、初回の要求と追加のスペースの申請を区別した。追加のアドレススペースを求める組織は、以前に割り当てられたネットワーク、使用済みおよび未使用の番号、インストールされたサブネット、接続されたホスト、および構造的詳細を記述するよう求められた。表明された目的には、利用可能なアドレスプールのより良い利用と、集約のために可能な限り連続したブロックの保存が含まれていた。
制度的ルーティングはフォームの表面に現れた。申請者は通常、最初にローカルレジストリに接近した。クラス B アドレスは地域レベルで割り当てられたので、クラス B の要求が正当化されると考えたローカルレジストリは、それをレビューのために RIPE NCC に転送した。技術情報は、公的なネットワーク管理レジストリに入るのではなく、機密のままだった。
申請者にとって、これは通知におけるかなりの向上だった。期待される証拠は提出前に組み立てることができた。より要求の厳しい要求は、目に見えてより要求の厳しい記述を引き起こした。RIPE-095 から RIPE-098 への急速な変更はまた、積極的な保守と、特定の日付に有効なバージョンを特定することの重要性を示している。
完成した空のフォームは依然として決定ファイルとは異なる。フォームは入力と経路を指定するが、審査官がどの予測を受け入れたか、競合する考慮事項がどのように重み付けされたか、または最終的にどの数量が割り当てられたかを明らかにしない。それらの事実は、トランザクション記録を通じてフォームに結合されなければならないだろう。
BCP 12 と公表された不服申立経路
1996 年 11 月までに、公開フレームワークはクラスレス化され、より精巧になっていた。RFC 2050『Internet Registry IP Allocation Guidelines』は、Best Current Practice 12 として発行され、RFC 1466 を置き換えた。著者は Kim Hubbard、Mark Kosters、David Conrad、Daniel Karrenberg、Jon Postel であり、所属は InterNIC Registration Services、APNIC、RIPE NCC、USC/ISI に及んだ。
IESG のノートは、文書のステータスを注意深く限定した。Best Current Practice としての承認は、ポリシーが当時のレジストリ慣行を正確に表しているという IESG の信念を表明した。それは、承認や推奨を明示的に差し控えた。したがって、RFC 2050 は、ケース監査とは異なるままでありながら、運用的な実務の制度的説明としては、提案された時刻表よりも強い。
この文書は、IANA、地域レジストリ、およびローカルレジストリの階層を記述した。それは、北米に InterNIC、ヨーロッパに RIPE NCC、アジア太平洋地域に APNIC を指名した。また、プロバイダへの割り当てとエンド企業への割り当てを区別した。その区別は、後のルールで使用される時間の地平線と分母の両方を支配した。
インターネットサービスプロバイダにとって、「スロースタート」は、即時の実証された必要性に基づく最小限の初回割り当てを意味した。その後の割り当ては、使用率の検証後に増加することができた。追加の割り当ては、プロバイダが親レジストリに戻る前に、約 3 ヶ月間の割り当て能力を提供することを意図していた。予測される顧客基盤だけではほとんど重みを持たなかった。
3 ヶ月の期間は、プロバイダの補充に属していた。それは RFC 1366 の 24 ヶ月の予測ではなく、同じ集団を支配していなかった。一方はプロバイダが親レジストリから受け取る能力に関するものであり、他方は加入者の予測需要をクラスフルブロックにマッピングした。
再割り当て情報は、別のプロバイダレベルの管理を形成した。サブレジストリは、運用連絡先が見つけられ、使用率がチェックでき、アドレス調査が実施できるように、割り当てを速やかに記録することが期待された。地域レジストリまたは上流プロバイダは、すべての再割り当て情報の約 80％が提出されるまで、別の CIDR 割り当てを行うべきではなかった。このパーセンテージは、ホスト使用率ではなく、関連する割り当て全体にわたる文書化のカバレッジを測定した。
エンドサイトの割り当てには、異なるガイダンスが使用された。基本的なしきい値は、即時使用率 25％、1 年以内に 50％だった。RFC 2050 は、期待される使用率を、ネットワークに接続されたホスト数を、そのネットワーク上で可能なホストの総数で割ったものと定義した。接続されたホストが分子を提供し、可能なホストの総数が分母を提供した。従業員、顧客、再割り当て記録はその計算の外にあった。
エンジニアリング計画には、サブネットマスク、各サブネット上のホスト数、トポロジ、およびルーティング構成を含めることが期待された。以前の保有は、共通の親の下の部門や子会社間で考慮されることができた。展開計画と予測の信頼性も重要だった。128 未満のホストを持つ組織は、通常、地域レジストリから直接スペースを受け取らなかったが、より長いプレフィックスが特定の状況下で発行されることがあった。
プロバイダベースのアドレッシングは、再番号付けの期待を伴った。アドレスは、接続期間中の貸与として扱われた。顧客がプロバイダを変更する場合、推奨は、既存のアドレスを返却し、新しいプロバイダのスペースに再番号付けすることであり、古いアドレスが再利用される前に十分な時間が許容された。目標は集約であり、恒久的に移植可能な権利の承認ではなかった。
RFC 2050 は、保全、ルーティング可能性、および登録の間の緊張を公然と認めた。個々のケースでは慎重な判断が必要だった。地域レジストリは、適切と考える手段によって要求を監査および検証することができ、虚偽の情報に基づく割り当ては無効にされる可能性があった。トランジットプロバイダは、レジストリが基礎となるアドレスを割り当てていたとしても、経路をフィルタリングする可能性があった。したがって、レジストリの割り当てはグローバルなルーティング可能性を保証しなかった。
機密性は、定義された親レジストリの経路を獲得した。割り当てレジストリは、要求者が特に機密として特定した情報を保護しなければならなかった。申請者が、ローカルレジストリが十分なプライバシーを提供できるという保証を欠く場合、親は評価を処理し、適切な数量を下方に伝達することができた。
文書のセクションタイトルは明示的だった：Right to Appeal。割り当てレジストリが必要な方法でそのタスクを実行しなかったと信じる組織は、親レジストリに不服を申し立てることができた。割り当てレジストリは関連文書を提供することになっていた。さらなる不服申立は階層を上って進むことができ、他の手段が尽きた後の最終決定のために IANA が利用可能だった。各レジストリは、割り当て決定に対してどのように不服を申し立てることができるかを明示しなければならなかった。
その文言は、以前の手段よりも明確に修正とレビューを分離した。パーサ修正は最終処理の前に情報を修復した。不服申立は割り当て決定に異議を唱えた。レビューは、その異議に対する親の審査だった。救済は、結果としての処分—元の決定の支持、変更、差し戻し、または置き換え—となるだろう。
レビューされた実務資料には、特定された不服申立ファイルは含まれていない。それにもかかわらず、RFC 2050 は、レビュー経路、文書移転義務、およびエスカレーション経路を公開の場に置いた。この期間の終わりまでに、申請者は、上級担当者に非公式に再考を依頼する機会以上のものを引用することができた。
実務の 4 つの成果物
ここで検討された運用的記録は小さいが多様である。その価値は、各項目をそれが実際に記録しているものに分類することにかかっている。
PIPEX の通信は、唯一の部分的な要求議論である。それは不特定の「いくつか」の要求で始まり、決定前の技術的事実確認を示している。それは、正確な要求数量も、申請者の応答も、処分も保存していない。
2 番目の成果物は、Marten Terpstra の1993 年 3 月 19 日の通知「Typos in assignments」である。Terpstra は、割り当てとレジストリ更新におけるタイプミスが「増加している」、特に 192 と 193 で始まる番号の混乱があると書いた。また、割り当てと通常の更新が誤ったメールボックスに送信されていると述べた。
RIPE NCC は、割り当てアドレスに送信された資料に対して、より厳しいチェックを導入した。ネットワークが既に関連記録に現れている場合、項目は当初拒否され、エラーが NCC スタッフに送信される。スタッフは、問題がおそらくタイプミスであるか、誤った提出チャネルの使用であるかを判断する。誤ったメールボックスに送信された更新は処理のために転送され、タイプミスの疑いがある番号は送信者への連絡を促すことができる。
これは、割り当て通知と更新のための運用的管理である。それは、チャネルエラーと推定されるデータエラーの間で発表された区分を示している。「増加している」には、ベースライン、観察期間、カウントがなく、メッセージには元のアドレス申請にリンクされた完了した修正は含まれていない。それは、申請者の結果の分母ではなく、事務的セーフガードの歴史に属する。
3 番目の成果物は、Daniel Karrenberg の1993 年 5 月 14 日の「Supernet block sizes」に関するメッセージである。Karrenberg は、大きく、弱く実証されたクラス C 要求に対する保守的なアプローチを説明した。レジストリは、後の必要性のために連続したスペースを予約しつつ、求められた量よりも少なく解放することができた。要求者は、初期割り当ての使用を示す証拠を持って戻ってくることができた。予約されたスペースは、12〜18 ヶ月後にリサイクルされることが期待された。
その間隔は、リサイクル前の予約された連続スペースの保持を指していた。それは決定時間でも一般的な予測期間でもなかった。Karrenberg の数値による説明は、強固な実証を欠く 64 のクラス C ネットワークの要求を含み、その例では 16 または 32 の割り当てと同量の予約が続いた。
この一節は、観察された削減ではなく、推奨される慣行の担当者による説明である。それは、申請者、提出されたフォーム、割り当て記録、または最終結果を指名していない。Karrenberg はまた、約 1 年後に「ごく一部」だけがさらなるスペースを求めて戻ってきたと書いた。「ごく一部」は定量化されていない。メッセージは分子も分母も提供していない。
ポリシーの論理は依然として情報に富む。初期の一部を解放することは、弱い予測のコストを削減した。隣接スペースの予約は、後の需要が実現した場合の経路集約の選択肢を保護した。一定の期間後のリサイクルは、その選択肢を無期限に開いたままにしておくコストを制限した。この通信は、あるレジストリ担当者が、不確実性の下で保全と集約のバランスをどのように説明したかを明らかにしている。
4 番目の成果物は、RIPE-18 会議記録である。参加者は、ヨーロッパで拒否された申請が、他の地域レジストリへの再申請後に受け入れられた事例を報告した。グループは、RIPE と InterNIC の基準間の格差への懸念を表明し、Daniel Karrenberg にその懸念を InterNIC に伝えるアクションを割り当てた。
参加者はまた、改訂されたフォームが、親組織、既存のアドレス保有、以前の申請、および以前に断られた要求について尋ねるべきであることに同意した。制度的対応はしたがって具体的だった：報告された問題はアクションアイテムと、後の申請者から収集される情報の提案された変更を生み出した。
議事録は、それらの報告の背後にある申請を提供しない。それらは、申請者、日付、数量、決定通知、変更された事実、後の割り当て、またはレビュー担当者を特定しない。「事例」にはカウントがない。記録は、参加者が何を報告し、グループがどのように対応したかを立証するが、最初の申請と後の申請の間の同等性は未検証のままにする。
合わせると、これらの成果物は、開かれた技術的相談、割り当て更新管理、保守的な割り当ての担当者説明、および報告された地域格差へのガバナンス対応を示している。いずれも、成功率、拒否率、修正率、削減率、例外率、または救済率を生み出さない。
機密性と生存の形状
アドレス要求の私的な半分は、その結果に最も関連する事実を含む可能性がある。エンジニアリング計画は、内部トポロジ、予測される拡張、設備制限、ネットワークセグメンテーション、ホスト分布、そして時には商業的意図を暴露した。それらを自動的に公開することは、率直な予測を妨げる可能性があった。
諸手段は、公開身元データを機密の技術的証拠から分離することによって対応した。RIPE-095 は、管理連絡先と割り当て番号を公開レジストリに置き、技術的詳細は内部使用のために留保した。RFC 1466 は、クラス B エンジニアリング計画に対して厳格な機密性を要求した。RFC 2050 は、特に機密として指定された情報を保護し、割り当てレジストリが十分な保証を提供できない場合の親レジストリの処理を提供した。
機密性は、意思決定の質を向上させることができた。運用的必要性を投機的蓄積から区別しようとする担当者は、組織が競合他社や一般大衆から合理的に差し控えるかもしれない詳細を必要とした。保護された提出は、より完全な説明のためのスペースを作り出した。
それはまた、後の観察者が測定できることを形作った。割り当てエントリは、組織、日付、およびアドレスブロックを特定するかもしれないが、数量を正当化した予測やトポロジは差し控える。逆に、残された空のフォームは、期待される入力を示すが、審査官がそれらをどのように扱ったかについては何も語らない。
保存は、目に見える結果を好む傾向がある。成功した割り当ては公開記録と後の運用的依存関係を生み出した。放棄されたか成功しなかった要求は、私的な通信、電話連絡、または耐久性のあるエントリなしに終わるかもしれない。修正は、以前の草案の横に残るのではなく、それらを置き換えたかもしれない。制限されたエンジニアリングファイルは、公開比較を妨げるアクセス条件の下で存続するかもしれない。
これらの力は、割り当て登録簿が元の申請の代表的なサンプルとして機能できない理由を説明する。それらは、欠落している結果のサイズや方向を確立しない。機密性は、慎重で一貫した審査とも、説明のつかない変動とも両立する。公開証拠だけでは、それらの可能性の間で選択することはできない。
自動化が停止した場所
RFC 1400 と実質的なアドレスガイドラインの対比は、書面による手続きが容易に制御できるものを明確にする。
テンプレートの選択、機械解析、検証、再提出、期限切れ、チケット状況は、比較的决定論的だった。プロセスは、古いフォームを特定し、エラーを返し、修正を促し、検証が 7 日以内に到着したかどうかを記録することができた。Terpstra の割り当て通知も同様に、スタッフが誤ったメールボックスと推定されるタイプミスの番号をどのように区別すべきかを指定した。
実質的な稀少性判断は、観察がより難しい変数を伴った。予測は、計画された調達、組織の成長、まだ展開されていないアプリケーションに依存した。トポロジは、デフォルトの数量を非効率的にする可能性があった。機器の制限は、本物であるか、バージョン固有であるか、一時的であるか、誤解されている可能性があった。集約コストは、申請者ではなく、他のネットワークオペレータに部分的に降りかかった。
書面によるルールは、依然としてこれらの決定を形成した。RFC 1366 は、需要からブロックへのベースラインを提供した。RFC 1466 は、クラス B エンジニアリング計画の内容を特定し、トポロジに基づく逸脱を公表した。RIPE-095 は、どのマシン数、サブネット、保有、計画が重要かを申請者に伝えた。RFC 2050 は、エンドサイトの使用率を定義し、保全とルーティング可能性の間の対立を暴露した。
見えにくいままだったのは、受け入れられた証拠から最終数量への橋渡しだった。機密性は多くの決定的な入力を隠した。公表された例外条項は、その使用の公開登録簿を作成することなく、関連するカテゴリを明らかにした。レビュー経路は、結果としての救済を示すことなく、エスカレーション経路を指定した。
したがって、証拠は事務的境界で最も強い。フォームと自動化は、情報がどのようにシステムに入ったかを明らかに構造化した。表とエンジニアリング計画の要件は、実質的判断の一部を議論の余地のあるものにした。それらが最終的な決定に与えた影響を測定するには、それらの段階を横断して結合された申請者レベルの記録が必要である。
レジストリシステムの変化に伴う権限の移動
この期間は、1 つのオフィスが徐々により多くの書類作業を採用したとは説明できない。異なる組織が異機能を遂行し、それらの機能は移行した。
1990 年、RFC 1174 は、IANA を USC/ISI によって遂行される機能であり、ネットワークおよび自律システム識別子のためのインターネットレジストリを、DDN-NIC で SRI International によって運営される機能として説明した。Internet Activities Board はポリシーを推奨した。それは、それ自体で各番号要求を処理したわけではなかった。
DDN-NIC はまた、防衛ネットワーク環境にサービスを提供した。RFC 1400 は、Network Solutions によって運営される InterNIC 登録サービスへの非 DDN 登録サービスの移行中に、DDN ユーザーのための別個の経路を保持した。「InterNIC」はより広いラベルだが、RFC の手続き上の主張は特に登録サービスに関するものだった。
RFC 1366 と RFC 1466 は、IANA およびインターネットレジストリの権威の下での地域委任を提案し記述した。RIPE NCC はヨーロッパ向けのブロックを受け取り、ローカルレジストリを調整した。ローカルサービスプロバイダは、同時に申請者の接続サプライヤ、助言者、そして最初の審査官であることができた。RIPE NCC は、公表された構造の下でのクラス B 事項の審査を含む、地域機能を保持した。
1996 年までに、RFC 2050 は、階層を IANA、地域レジストリ、ローカルレジストリとして提示し、InterNIC、RIPE NCC、APNIC を指名した。この説明は、それらの機関に所属する著者から来ており、彼らが最新であると言うレジストリ慣行を記述した。
権威は単一ではなく、層状だった。グローバルな一意性は技術的調整に依存した。委任されたブロックは、地域およびローカルオフィスに運用的管理を与えた。政府の賞と契約は特定のサービス構成を支えた。地域の認識とコミュニティ参加は、制度的正当性に寄与した。プロバイダ関係はルーティングと再番号付けに影響を与えた。公開文書は通知と共有された技術的語彙を提供した。
後の地域レジストリモデルを遡及的に投影することは、それらの移行を曖昧にするだろう。技術的調整を無制限の法的権限として扱うことは、異なる歪みを生み出すだろう。各日付において、関連する問いは、どのオフィスがその機能を遂行したか、その役割がどのように生じたか、そしてその前の要求にどの手続きが適用されたかである。
判断が運用上防御可能であり続けた理由
完全に機械的な割り当てシステムは、初期のインターネット成長の不確実性に対してうまく機能しなかっただろう。
現在のマシンは数えられるかもしれないが、2 年間の予測は、依然として計画されている調達、組織の拡大、ネットワークアーキテクチャ、およびサービスに依存した。申請者は、繰り返しの申請や破壊的な再番号付けを避けるインセンティブを持っていた。レジストリは、蓄積を阻止するインセンティブを持っていた。どちらの側も完全な情報を所有していなかった。
トポロジは、単純なホスト数ルールを弱めた。1 つのキャンパス上の 600 のホストは、10 の物理ネットワークに分散した 600 のホストとは異なるエンジニアリング問題を提示する可能性があった。RFC 1466 の 10 イーサネットの例は、同一の総数が異なるネットワーク番号数量を支持するかもしれないことを認識していた。
ルーティングは外部性を加えた。申請者は、サブネット化や再番号付けのローカルな不便を負担した。他のネットワークオペレータは、追加の経路に関連するメモリ、処理、調整の負担を負った。隣接スペースを予約しながら、より小さな初期ブロックを解放することは、集約を保護するかもしれないが、予約自体が希少なアドレス空間のオプションを消費した。
証拠の質も様々だった。ベンダーの制限は、実際のインストールされた制約、古いバージョン、不完全な文書、または誤解を反映している可能性がある。PIPEX のやり取りは、申請者の前提を複数の種類の専門知識と比較することの価値を示している。それはまた、一般的な製品能力が特定の展開のコストを解決したと仮定しないよう警告している。
一方で、利用可能な技術は動いていた。クラスフルアドレスの仮定、CIDR、プロバイダ集約、プライベートアドレス空間、可変長サブネットマスクは、実現可能なネットワーク設計を変えた。RIPE-095 の 14 日間の最新フォームとしての在任期間は、比較的控えめな手続き手段の周りでさえ保守のプレッシャーを示している。
したがって、裁量は、排除されるのを待っていた単なる制度的残渣ではなかった。それは、単一の表に適合しない予測、トポロジ、および外部コストへの対応だった。ガバナンスの問題は、担当者が公表された根拠の範囲内でその判断を用い、重要な逸脱を文書化し、最終決定を意味のあるレビューにさらしたかどうかである。
1996 年までに申請者が知り得たこと
この期間を通じて、申請者のプロセスの見方は著しく明確になった。
公開数値参照点は RFC 1366 に登場し、RFC 1466 で拡張された。申請者は、結合されたクラス B しきい値、24 ヶ月のクラス C スケジュール、および逸脱を正当化できるトポロジの例を見ることができた。
次に、RIPE フォームはそれらの原則を質問に変換した。組織は、マシン、サブネット、既存の保有、接続計画、ネットワークレイアウト、および将来の成長が評価に含まれることを知っていた。それは、どの情報が公開になり、どの技術資料が機密のままかを知っていた。直接申請することとローカルレジストリを通じて進むことの区別は、フォーム上で説明された。
RFC 1400 は、機械処理される提出のための修正経路を暴露した。要求者は、解析された情報を検査し、ミスを修正し、エラーに対応し、再提出し、トラブルチケット番号を使用して状況を確認することができた。Terpstra の通知も同様に、一部の割り当て更新処理をローカルレジストリに見えるようにした。
例外も開示された。RFC 1366 は、クラス C ブロックが実用的でない場合のケースバイケースの扱いを許可した。RFC 1466 は、トポロジを認められた根拠として特定し、エンジニアリング計画を要求した。RFC 2050 は、VLSM と機器ベースの主張に対する詳細な正当化を期待しつつ、例外を認め続けた。
1996 年 11 月までに、申請者は、指名されたRight to Appeal、親レジストリへの文書移転、および IANA への可能なエスカレーションを呼び出すことができた。そのテキスト上のアーキテクチャは、同じオフィスに非公式に再考を依頼するよりも具体的だった。
最も見えにくい要素は、最終的な証拠の橋渡しだった：特定のトランザクションにおいて、どの事実が割り当てられた数量を制御したか。公開手段は、受け入れられた入力、逸脱、結果を結合する公開決定物語をほとんど生み出さなかった。保護されたエンジニアリング計画は、申請者間の比較をさらに制限した。レビューのアーキテクチャは、その結果を変える力が、発見された記録において測定可能になる前に、知ることができるようになった。
依然として必要なトランザクション監査
実質的な制約の説得力のあるテストは、トランザクションをその単位として使用しなければならない。
各観察は、元の申請と、提出日に有効だった正確なフォームおよびガイドラインバージョンから始まるだろう。それは、要求されたリソースと数量、現在および予測されるホスト数、サブネット計画、トポロジ、既存の保有、プロバイダ関係、およびルーティング状況を記録するだろう。
管理側は、責任あるレジストリ、審査官、追加情報の要求、修正、受け入れられた予測、各実質的変更の理由、最終処分、および呼び出された例外を特定するだろう。レビューが行われた場合、記録は異議の根拠、移転された文書、レビュー担当者、決定、および救済を追加するだろう。
公表されたしきい値付近のケースは、特に情報価値が高いだろう。同じバージョンの下での比較可能な要求は、境界の同じ側の受け入れられた予測が比較可能な結果を生み出したかどうかを示すことができる。文書化されたトポロジ逸脱は、裁量が表明された例外に従ったのか、表明されない選好に従ったのかを明らかにすることができる。
バージョン変更は別のテストを提供する。1992 年 10 月の表の前後の、あるいは文書化されたフォーム改訂の周辺での類似の申請は、結果が手段と共に変化したかどうかを明らかにすることができる。ルーティング条件、制度的責任、利用可能な技術の変化は、背景ノイズとして扱うのではなく考慮される必要があるだろう。
事務的性能は別に測定されるべきである。RFC 1400 スタイルの処理の研究は、すべての機械的拒否を拒否されたアドレス申請としてラベル付けすることなく、解析応答、修正された検証、期限切れ、再提出、および放棄を数えることができるだろう。それは、割り当て判断が大部分裁量的なままだったとしても、情報処理がより規則的になったかどうかをテストするだろう。
不服申立は、それ自身の連鎖を必要とする。有効な観察は、元の決定、根拠、移転されたファイル、親レジストリのレビュー、および結果としての処分を結合するだろう。支持された決定は依然としてレビューを示すだろう。結果を変える力を伴う救済は、不服申立に帰属する変更された割り当て、差し戻し、または代替結果を要求するだろう。新しい事実を伴う再申請は、異なるカテゴリに属する。
サンプリングは、成功したアドレス保有者のリストではなく、オフィスの境界、日付、および記録シリーズから始めるべきである。公開割り当て登録簿は、不均衡に完了した割り当てを露出する。制限された、欠落した、破壊されたファイルは、宣言された方法の下で記録される必要があるだろう。機密資料は、保護された条件の下で分析され、決定を評価するために必要な変数のみを公表することができるだろう。
そのような研究は、削減、遅延、修正、例外、不服申立、および救済を推定することができるだろう。また、予測誤差、さらなるスペースのための後の戻り、およびレジストリ間の差異を検討するかもしれない。ここでレビューされたガイダンス文書と 4 つの実務成果物は、その監査を設計するには十分だが、その結果を計算するには十分ではない。
より把握可能な手続き、最終的な制約は依然として未測定
1988 年から 1996 年にかけて、アドレス管理はより公開的で理解可能な構造を獲得した。申請者は、システムへのより明確な経路、要求される証拠の事前通知、量的参照点、修正メカニズム、逸脱の表明された根拠、機密計画の保護、そして最終的には公表された不服申立経路を得た。RFC 1400 は事務的取り扱いに実質的な規律を課した。RFC 1366 と RFC 1466 は、いくつかの実質的逸脱を認識可能にした。RIPE はフォームを保守し改訂した。RFC 1467 は、管理的実装の制度的説明を記録し、RFC 2050 は文書移転とレビュー義務を伴う成熟した階層を記述した。
これらの変化は、システムを Hostmaster との完全に非構造的なやり取りへの依存から遠ざけた。それらはまた、レジストリが急速に拡大するネットワークにわたって予測、トポロジ、既存の保有を比較するのを助けた。アドレス保全、経路集約、申請者のコスト、不確実な成長が異なる方向を指し示す可能性があるため、判断を保持する運用的ケースは強固なままだった。
開かれたトランザクション証拠はより狭い範囲を持つ。それは、1 つの部分的な要求議論と 3 つの運用的または制度的観察から成る。PIPEX 通信は、ソフトウェアの主張に対するピアレビューを示すが、処分の前で停止している。Terpstra の通知は、割り当てと更新の管理に関する。Karrenberg の数値例は、申請者の結果を特定することなく保守的な慣行を説明している。RIPE-18 は、基礎となる申請なしに参加者の報告と制度的対応を記録している。
レビューされたセットには、元の申請、適用可能なバージョン、修正、同時代の理由、最終割り当て、レビュー、救済を結合する完全な連鎖は特定されていない。結果として、実質的な決定の一貫性と成功率または拒否率は未測定のままである。以前のアドレスフォームもまた、直接調査されれば、最も初期の文書化された基準の年代を修正するかもしれない。
したがって、歴史的結果は限定されているが重要である。公開フォームと表は、申請者の入力、事務的取り扱い、および一部の逸脱をより把握可能にした。それらは精査の条件を作り出した。残された公開記録は、それらの基準が最終判断をどの程度一貫して支配したかを判断するために必要なトランザクションサンプルをまだ提供していない。