概要
- RFC 1366 は、中央 IANA とインターネットレジストリの調整を維持しつつ登録を分散し、サービスの距離、クラス別の枯渇、経路集約に対処するためにクラス C 空間を地理的にグループ化することを提案した。
- 本文と初期の欧州実装は真の地域化を示しているが、恒久的な地域排他性、所有権、オペレーター全体の同意、完全な置換・異議申し立てメカニズムを確立するものではない。
観測された問題は、管理負荷とアーキテクチャ的緊張の組み合わせであった。1992 年 6 月のクラス別スナップショットで、RFC 1366 は 126 のうち 49 の割り当て済みクラス A ネットワーク番号スロット、16,383 のうち 7,354 のクラス B スロット、2,097,151 のうち 44,014 のクラス C スロットを数えた。中規模ネットワークには効率的にサービス提供が難しかった。クラス B 番号は不足している一方、多数の無関係なクラス C ネットワークを発行するとルーティングテーブルが肥大化した。RFC 1366 は、登録を分散し、地理的に編成されたクラス C ブロックを予約し、24 か月の予測に基づいて連続したブロックを割り当て、IANA と中央インターネットレジストリを調整役およびデフォルトアクターとして保持することで応えた。
開かれた地域競争の説明に対する最も強力な反証は、文書そのものに存在する。RFC 1366 は、地理的領域ごとに 1 つの地域レジストリが、効率的かつ公平なサブ割り当てのために重要であると記述した。その選好には、地域の認知、制度的基盤、運用リソース、中央ガイドラインへの準拠、サブ割り当てに関する調整の要件が結びつけられていた。同時に、加入者は依然として中央のインターネットレジストリに連絡することができ、それはルートであり、必要な場合にはサービスを提供すると約束されていた。したがって、この文書は地域層での集中と中央フォールバックを提案したが、固定された地域境界、指定期間、定期的な認定手続き、比較選定記録、ポータビリティ権、公表された置換メカニズムは提供しなかった。
欧州の実装は、日付付きの、非同時的な行為を通じて進行した。RIPE 文書は、ネットワーク調整センターの運用開始を 1992 年 4 月 1 日とし、5 月 1 日から委任レジストリとして機能し、7 月に中央インターネットレジストリが欧州の申請を処理するよう要請し、8 月 1 日からそれらの申請の自動転送が開始されたとしている。1993 年 3 月の四半期末までに、RIPE 87 は 10,348 件の割り当て済みネットワーク番号と、143 件の申請の部分的なワークロードログを報告した。RIPE 92 は後に、最初の運用年度に 10,000 件を超えるネットワーク番号が割り当てられたとし、RIPE 99 は遡及的にその年度に 14,000 件以上を主張し、また 18 か月後の 1993 年 10 月 25 日の観測点では、60 を超えるサービスプロバイダレジストリと 21 の非プロバイダ国別レジストリを報告した。これらの報告は、これらの合計を調整するための共通の固定データセットを明らかにしていない。
この限定的な知見は、憲法的な起源物語よりも、結果的ではあるが狭いものである。RFC 1366 は運用上の問題に対処し、地域層で 1 つのプロバイダという選好を追加し、欧州では観察可能なブロック委任、ローカルでの再割り当て、申請の転送、データベース交換、リクエストレビュー、逆引き DNS 委任を伴っていた。それは Informational RFC であり、インターネット標準でも、オペレーター全体の投票でもなかった。利用可能な記録は、設計をレビューまたは実装した技術的および調整的な構成グループを特定しているが、影響を受けるオペレーター全体の分母、候補の比較、異議申立記録、指定の上訴、置換プロセス、名目上の中央フォールバックが実際に一様に使用可能であった証拠は存在しない。
1992 年 10 月：中央のキューがスケーリングするネットワークに直面する
RFC 1366「IP アドレス空間管理のガイドライン」は、Merit Computer Network の Elise Gerich によって執筆され、1992 年 10 月に発行された。その位置づけを曖昧さなく表明していた：このメモはインターネットコミュニティへの情報提供であり、インターネット標準を規定するものではない。その分類は、文書を取るに足らないものにしなかった。Informational RFC は、制度を調整し、実用的な計画を定義し、運用手順に影響を与えることができた。単に発行するだけでは、標準に関連する承認手続きを提供することはできず、ましてや後に割り当てシステムに依存するすべてのネットワーク間の投票を提供することはできなかった。
この文書を取り巻く組織名には注意が必要である。RFC 1366 の要旨では、FEPG を「Federal Engineering Task Force」と展開しているが、謝辞では「Federal Engineering Planning Group」とし、RFC 1367は「FNC Engineering and Planning Group」と呼んでいる。ソース記録は一貫しておらず、したがって単一の展開を明確に正統とみなすべきではない。FEPG がより安全な略語である。
RFC 1366 は、FEPG が Federal Networking Council を代表して、International Engineering Planning Group および RIPE の共同議長と共に提案をレビューしたと述べた。これらのグループの間で、勧告を支持する一般的な合意があったと報告した。謝辞では、FEPG と IEPG のメンバーが多大な貢献をしたとし、概念を 1992 年 7 月にマサチューセッツ州ケンブリッジで開催された IETF Addressing Birds of a Feather セッションにさかのぼらせ、Jon Postel と Yakov Rekhter をレビュアーおよび貢献者として挙げた。
これは重要な作成環境であるが、各アクターは限定された役割を担っていた。Gerich は著者であった。FEPG と連邦評議会は連邦ネットワーキング構造に属していた。IEPG は国際的なエンジニアリング計画参加をもたらした。IETF BOF は技術的アイデアを発展させテストする場を提供した。RIPE は調整参加者であるとともに、新興の実装主体であった。IANA と中央インターネットレジストリは、空間を予約し、ルートを維持し、レジストリを承認し、委任を調整することが期待されるアクターであった。ネットワークプロバイダ、加入者、ローカルレジストリ、申請者は影響を受ける集団であり、起草およびレビューグループと交換可能ではない。
したがって、「一般的な合意」というフレーズは、指名されたレビュアーについての帰属声明を支持する。RFC 1366 は、参加者数、出席者リスト、投票、所属分母、異議申立記録を提供しておらず、それらから広範な支持を計算することはできない。議論への参加自体が支持を意味するわけではなく、実装は遡及的な投票ではない。この制限は、関与したグループの専門知識や影響力を消し去るものではない。それは、彼らのレビューが、無言のうちに普遍的なオペレーターの承認に拡大されるのを防ぐ。
実際的なケースは、成長と国際化から始まった。RFC 1366 は、ネットワーク番号の需要が過去 2 年間で大幅に増加したと述べた。より多様なグローバルな集団が、以前のより地理的に集中した環境で設計された中央登録サービスとやりとりしなければならなかった。申請者に近い場所にあるレジストリは、関連する言語でサービスを提供し、地域の行政慣行により効果的に対応できるかもしれない。この枠組みにおける分散は、まず組織的な距離を縮めることであった。当初、地理的な領域が番号リソースやそれに対する政治的な管轄権を保有しているという主張を必要としなかった。
クラスフルアドレッシングは、作業負荷を単なるサービス問題以上のものにした。RFC 1366 の表 1 は、1992 年 6 月のスナップショットをネットワーク番号スロットの単位で報告した。クラス A では、割り当て済みスロット 49 を合計 126 で割ると 38.8889%となり、38%ではなく、約 39%に丸められる。クラス B では、7,354 を 16,383 で割ると 44.8892%であり、これは記載された 45%と一致する。クラス C では、44,014 を 2,097,151 で割ると 2.0988%であり、記載された 2%と一致する。
最初の不一致は、密かに修正されるのではなく、可視のままにされるべきである。より重要なのは、表の単位が申請者、組織、リクエスト、ルーティングされたプレフィックス、拒否、または利用されたホストではなかったことだ。それは、3 つのクラスにおける 1 つの管理スナップショット時点で割り当てられたネットワーク番号スロットを測定したものである。リクエストの分母、後に返却された割り当ての一覧、割り当てられた各ネットワークがどれほど効率的に使用されているかの測定は含まれていない。
しかし、この不均衡は実際のエンジニアリング上の問題を捉えていた。クラス C ネットワークは小さなホストフィールドを提供し、クラス B ネットワークは多くの中規模組織が必要とするよりもはるかに大きな容量を提供した。寛大なクラス B 割り当ては、比較的希少なミドルクラスを消費した。複数の独立して広告されるクラス C ネットワークで代替すると、クラス B スロットは節約されるが、ルーティングエントリが複数追加される可能性があった。登録ポリシー、アドレス節約、ルーティングテーブルの成長は結びついた。
ルーティングの懸念には経験的な参照点があった。1992 年 6 月に発行されたRFC 1338は、Merit の月次広告経路系列を再掲し、1990 年 4 月に 1,525 経路、1992 年 2 月に 4,775 経路を含んでいた。差は 4,775 から 1,525 を引いた 3,250 の追加広告経路である。1990 年 4 月のベースラインと比較すると、22 か月で 213.1%の増加であった。
RFC 1338 は、その出所を Merit とし、これらの数字を NSFNET ルーティングデータベースに例示されるデフォルトフリールーティング情報に関連付けた。これは全ルーターのセンサスではなかった。観測単位は、指名された 2 つの観測日におけるその月次系列の広告経路であり、アドレスリクエスト、申請者、加入者、オペレーター、割り当てられたネットワーク、インターネットユーザーではない。その価値は、重要なルーティング視点での圧力を示すことであり、普遍的な分母を提供することではなかった。
また、連続的な割り当てが自動的に観測されたテーブルを縮小したわけではない。RFC 1338 は、集約の利益は、任意のネットワークとマスクのペアに対するドメイン間ルーティングのサポートに依存すると説明した。アドレス管理は、ルーターがそれらを単一の宛先として使用する前に、集約可能なブロックを準備することができた。マルチホーミング、プロバイダ変更、例外は、より具体的な経路を保持または再導入する可能性があった。したがって、管理計画は集約の前提条件であり、集約がすでに展開されていたことや、すべてのルーターが同じ結果を観測したことの証明ではなかった。
RFC 1366 は、これらの圧力を 1 つの回答にまとめた。登録は分散される。クラス C ネットワーク番号空間の大部分は、広範な地理的ブロックに分割される。これらのブロック内での割り当ては、予測される需要に対してサイズが決定された 2 のべき乗の連続ブロックを使用する。IANA と中央インターネットレジストリは、調整機能、より厳しく制御されるクラスに対する責任、および地域レジストリが存在しない場合のサービスを保持する。
この文書はまた、その地平線を示した。その勧告は、無期限に枯渇を防ぐのではなく、枯渇を遅らせることを公言した。当時ほとんど未割り当てだったクラス C 範囲の大部分は、追って通知があるまで予約されたままにされた。この計画は、アドレッシングとルーティング技術が進化する間、既存のアーキテクチャを実行可能に保つことを目指した。緊急性が設計を駆り立てたが、文書は恒久的な和解を書いたとは主張しなかった。
RFC 1174 はすでにセンターを廃止せずにサービスを分散していた
前身のアーキテクチャは、2 年前の 1990 年 8 月に Vinton Cerf によって執筆されたRFC 1174に現れた。その文書も Informational であり、インターネット標準ではなく勧告を提示することを明示していた。それは、Internet Activities Board の公式見解を Federal Networking Council への勧告として記録した。
RFC 1174 は、中央集権的な IANA およびインターネットレジストリ機能を保持することを提案した。当時、IANA 機能は南カリフォルニア大学情報科学研究所で実行され、SRI International の DDN ネットワークインフォメーションセンターがネットワーク番号と自律システム番号のインターネットレジストリ機能を実行していた。インターネットレジストリは、主要なレジストリであり、委任された登録機関が特定されていない場合のデフォルトであり続ける。
分散は、制御された委任を通じて行われる。インターネットレジストリは、国際研究ネットワーキング調整委員会によって承認された組織にネットワーク番号と自律システム番号のブロックを割り当て、さらなる割り当て権限を与えることができる。候補レジストリは、IANA およびインターネットレジストリと会合し、運用要件をレビューし、提案された分散運用モードを文書化することが期待された。
データベース設計は、その分散がいかに限定的であったかを明らかにしている。RFC 1174 は、インターネットレジストリが維持する集約登録データベースを推奨し、冗長性とアクセスのために委任レジストリにコピーが提供される。ただし、更新はインターネットレジストリで集中化されたままである。その後、完全なコピーがファイル転送または別のタイムリーな方法で再配布される。これは、複製読み取り・中央更新アーキテクチャである。複数の独立したライターが同時に権威ある台帳を安全に変更できるとは想定せずに、複数のサービスロケーションを提供した。
この区別は制度分析にとって重要である。分散は、委任された各レジストリが自己完結型の名前空間を持っていたり、中央の一意性制御が消滅したりすることを意味しなかった。ローカルまたは地域サービスは、申請を受け付け、委任された割り当て権限を行使できるが、権威ある更新は中央で直列化される。中央は、重複識別子を回避し、完全な記録を維持する責任を負い続けた。
RFC 1174 はまた、古いバイナリの「接続」ステータスを放棄することを推奨した。登録は、連邦政府が支援するインターネット施設への接続許可と絡み合っていた。商用、学術、研究、仲介、非米国ネットワークが増加するにつれて、そのバイナリカテゴリは、多様なアクセスおよびトランジットの取り決めを説明しなくなっていた。この文書は、利用許諾、アクセス、トランジットポリシーの声明を収集し、連邦政府が承認した接続性に関係なく、登録されたネットワークが関連する命名データベースに入ることを許可することを提案した。
これにより、番号管理とネットワークポリシーの執行が分離された。レジストリは、ルーティング、相互接続、トランジット、利用許諾に関するすべての質問を決定することなく、グローバルに一意な番号を記録できた。ネットワーク管理者は、引き続き自身のポリシーの下でこれらの決定を下す。レジストリ台帳は不可欠な調整インフラであったが、台帳の管理は自動的にネットワーク運用に対する包括的な管理を含むわけではなかった。
推奨の動詞は依然として重要である。RFC 1174 は提案し、示唆し、予期した。すべての委任、複製プロセス、またはポリシー分離が完了したことを示す監査済みリストを公開しなかった。CCIRN、IANA、インターネットレジストリを通じた承認経路は、定義された制度的チャネルであり、影響を受ける可能性のあるすべてのオペレーターの分母ではなかった。
RFC 1366 は、このアーキテクチャを継承し、自律的な領域レジストリに置き換えたわけではない。インターネットレジストリをルートと呼び、カバーされない地域ではデフォルトとして保持し、分散レジストリを IANA およびインターネットレジストリのガイドラインの下に置き、直接の連絡を明示的な選択肢として保持した。地域化は真の委任と地域責任を伴ったが、それは中央調整の中に入れ子のままであった。
この構造は、2 つの相反する単純化に抵抗する。1 つは、センターが生き残ったために地域化を表面的な分散化に還元する。しかし、地域レジストリはサービスとサブ割り当てに対して真の責任を行使することが期待された。もう 1 つは、地理的ブロックを主権や所有権の移転として扱う。RFC 1366 は予約、割り当て、割り当て、登録、委任を記述した。所有権の移転を定義しなかった。
難しい言葉は「１つ」だった
RFC 1366 の集中に関する最も強力な条項は、直接読まれるべきである：それは「このレベルでは地理的領域ごとにただ 1 つの地域レジストリ」を、効率的かつ公平なサブ割り当てにとって重要であると記述した。「１つ」は、同じ地理的領域に対して同じ層で動作する複数の地域レジストリに対抗するものであった。「このレベルで」は、地域組織の下に多数のサービスプロバイダ、国別、またはその他のローカルレジストリの余地を残した。中央インターネットレジストリもその上に残り、直接のアプローチを受け付けることができた。したがって、地域層での単一性は現実的であったが、それはすべての申請を処理する 1 つのオフィス、または中央サービスの消滅と同等ではなかった。
残りの言葉は、完全な説明責任設計なしに理論的根拠を提供した。「地域」は管理層を指し、立法府や主権者を指してはいなかった。「地理的」は、サービスと割り当てブロックを広範な世界地域と関連付けたが、境界設定や地域横断的ネットワークは未解決のままにした。「効率的」は、おそらく一貫したサブ割り当て、重複の減少、中央作業負荷の低下、集約に適したブロックを指したが、RFC には比較コスト研究は含まれていなかった。「公平」は宣言された目的であり、公表された平等性メトリック、決定監査、サービスベンチマーク、または上訴経路はなかった。この文は、1 つのプロバイダという選好を強く確立している。さらなる証拠なしに、指定の期間を固定したり、恒久的な排他性を証明したり、所有権を確立したり、サービスエリア内のすべてのオペレーターからの同意を実証したりすることはできない。
直接サービス条項も同様に重要である。RFC 1366 は、加入者はインターネットレジストリに連絡でき、状況に応じて地域レジストリに紹介される可能性があり、必要な場合には中央でサービスを受けられると述べた。これはルートと名目上のフォールバックを保持した。この文書は「必要な」を定義しておらず、紹介に抵抗できる場合を指定せず、センターに対する応答義務を公表せず、直接サービスが地域レジストリの決定のレビューを提供するかどうかを確立しなかった。委任階層内のフォールバックは、自動的にピアプロバイダ間のポータビリティではなく、テキスト上の選択肢は実際の使用可能性の証明ではない。
1 レジストリ条項はそのカウンターウェイトに値するが、希釈されてはならない。中央フォールバックを、排他性が存在しなかった証拠として扱うことは、提案された階層化を誤読するだろう。地域選好を取消不能な領土譲渡として扱うことは、操作的な文言を超えるだろう。RFC 1366 は、中央調整階層内の一層における集中を設計した。
再現可能な選定記録のない選定基準
RFC 1366 は、単に利用可能な組織を指名するのではなく、地域レジストリがどうあるべきかを定義しようとした。5 つの基準を提示した。これらは合わせて、著者が委任を単なる技術的設定ではなく、制度的決定として理解していたことを示している。また、決定手続きのどれだけが未記述のままであったかも暴露している。
第一に、地理的エリア内の「ネットワーキング権威」が候補を正当化することになっていた。この用語には分母が提供されていなかった。国立研究ネットワーク、省庁、キャリア、サービスプロバイダ、学術コンソーシアム、標準参加者、ネットワーク運用フォーラムは、それぞれ異なる種類の権威を主張できた。RFC は、必須カテゴリを特定せず、いくつの支持があれば十分なのかを決定せず、異議に重みがあるかどうかを説明せず、相反する主張がどのように解決されるかを述べなかった。
周辺テキストはまた、レジストリが偏りがなく、地域内のネットワークプロバイダと加入者によって広く認識されていることを要求した。「広く」はテストに変換されなかった。それは、国々にわたる認識、主要バックボーン間の認識、技術調整フォーラム内での認識、またはレビュアーにすでに知られている組織間の認識を意味したかもしれない。プロバイダと加入者のリストは添付されておらず、したがって読者は認識比率を再現したり、どの影響を受ける組織が欠けていたかを特定したりすることはできない。
第二に、候補は十分に確立されており、レジストリ機能の外部に正当性を有している必要があった。これにより、選定のみに基づく組織に重要な調整を委ねるリスクが軽減された。既存の技術作業、財政的継続性、組織的成熟度、認識された調整役割が、すべてこの基準を支持できた。しかし、RFC は標準的な財務開示、ガバナンス検査、利益相反評価、比較スコアカードを提供しなかった。
第三に、組織は安定し、タイムリーで信頼できるサービスのために適切なリソースをコミットする必要があった。これは、人員配置、予算、応答時間、データベース精度、可用性、継続性の取り決めを通じて測定可能な最も基準となるものであった。文書はしきい値を指定せず、パフォーマンスが後に悪化した場合の結果も定義しなかった。
第四に、レジストリは IANA とインターネットレジストリのガイドラインに従って番号を割り当てる必要があった。第五に、資格とサブ割り当て戦略について中央インターネットレジストリと調整する必要があった。これらの条件は地域の自律性を抑制した。委任されたレジストリは、非互換の番号付けシステムを構築したり、ルート台帳を無視したりする権限を与えられなかった。
言語と地域慣習は、5 つの正式な基準ではなく、分散の理論的根拠に現れた。RFC 1366 は、地理的に位置するレジストリがそれらの点でコミュニティにより効果的にサービスを提供するかもしれないと示唆した。特定の言語セット、翻訳されたフォーム、ローカルオフィス、または測定可能なサービスカバレッジを要求しなかった。その理論的根拠は、特に急速に国際化するネットワークにおいてもっともらしかったが、認定テストとして運用化されなかった。
決定連鎖は不完全なままであった。IANA とインターネットレジストリはレジストリに権限を与え、地域ネットワーキング権威はそれを正当化し、候補は中央ルールを受け入れる。テキストは、誰がリソースを検証し、候補がどのように比較され、中央アクターが地域の異議を押し切って選択できるかどうか、いずれかが拒否権を持っていたかどうか、後に認識が低下した場合に何が起こるかについて、未解決のままにしている。
公表された指定に対する異議申し立ても存在しなかった。失望した候補は、評価を検査したり再考を求めたりする明示的なプロセスを受けなかった。加入者は中央インターネットレジストリに連絡できたが、その運用経路は必ずしも地域組織のステータスをレビューするものではなかった。サービス修正と制度置換は別の問題であり、前者だけが一般的なフォールバックさえ受け取った。
したがって、この基準は地域委任を非公式な都合よりも規律あるものにした。再現可能な認定および更新レジームを作成したわけではない。作成記録は、明示された原則の下で特定可能な調整機関による選定を支持するが、委任の広さ、期間、争訟性は未解決のままにしている。
地理ブロックは割り当て手法であり、領土ではない
RFC 1366 は、クラス C 範囲の一部を 8 つの等しいブロックに分割することを提案した。プレフィックス 192 と 193 がすでに使用中であり、194 から 223 の多くが未割り当てのままであることに言及した後、208 から 223 を追って通知があるまで予約し、192 から 207 を/8ブロックのペアに配置した。
RFC は各ペアを 131,072 の「アドレス」を含むと説明したが、操作的なクラスフル単位は 131,072 のクラス C ネットワーク番号スロットであった。各スロットは名目上、256 の生の IPv4 値の/24サイズ範囲に対応する。131,072 に 256 を掛けると、各 2 つの/8ブロックで 33,554,432 の生の値が得られる。RFC 1366 のクラス C 分母 2,097,151 のネットワーク番号スロットに対して、131,072 スロットは約 6.25%を表し、文書の約 6%という丸められた説明と一致する。
ラベルは暫定的かつ広範なものであった。192-193 は多地域、194-195 は欧州、196-197 は「その他」、198-199 は北米、200-201 は中南米、202-203 は環太平洋、204-207 はさらに 2 つの「その他」ブロックを供給した。これは 5 つの恒久的な機関の成熟した地図ではなかった。4 つの指名された地理的エリア、1 つの多地域範囲、3 つの柔軟な範囲を含んでいた。
適格な地域レジストリが存在する場合、関連するブロック内での主要な割り当て責任をそのレジストリに委任することができた。存在しない場合、中央インターネットレジストリは地理的区分に従いながら割り当てを継続する。したがって、地理は地域機関が選定される前に割り当てを形成することができた。ブロック計画と制度的カバレッジマップは関連しているが同一ではない。
ブロック内の割り当ては、加入者の 24 か月の予測需要に基づいて、2 のべき乗の連続ブロックを使用することになっていた。通常の順序は、256 アドレス未満なら 1 つのクラス C ネットワーク、512 未満なら 2 つの連続ネットワーク、1,024 未満なら 4 つ、2,048 未満なら 8 つ、4,096 未満なら 16 であった。これらは計画の下での割り当てのサイジングルールであり、リクエスト、申請者、または成功した決定の数ではない。
生のアドレスと使用可能なホストは区別されなければならない。/24には 256 の生の IPv4 値が含まれる。当時の慣例的な扱いでは、オールゼロとオールワンのホスト識別子は通常のホストには使用できず、254 の使用可能なホスト識別子が残る。したがって、16 の連続する/24は 4,096 の生の値を含むが、慣例的に使用可能なホストは 4,064 である。RFC 1366 の通常の連続クラス C の例は 16 ネットワークで停止し、4,096 を超える一意のアドレス要件はクラス B の検討に向かう可能性が高いと指示した。
後にRIPE 83として公開された欧州のフォームは、32 クラス C ネットワークに拡張された例を表示した。そのフォームのホストの慣例では、32 に 254 を掛けると 8,128 の使用可能なホストが得られる。同じ 32 の/24は 8,192 の生の値を含む。この比較は、2 のべき乗のブロックサイジングの連続性を示すが、同一の上限しきい値ではない。地域の実践で使用されるフォームは、表示されるクラス C オプションを RFC 1366 の通常の 16 ネットワークの例を超えて拡張できる。
RFC 1366 では、クラス B は中央管理のままだった。文書のベースラインは、32 サブネット以上、4,096 ホスト以上を要求し、クラス C ブロックが実用的でない場合にはケースバイケースの検討を要した。地域レジストリは評価を支援できるが、IANA とインターネットレジストリがクラスに対する責任を保持した。したがって、地域化はすべてのアドレスカテゴリにわたって包括的ではなく、実質的なものであった。
地理的計画にはルーティングの限界もあった。集約は、割り当て階層とルーティングトポロジが一致するときに最もクリーンに機能する。プロバイダは国境を越えることができ、組織はマルチホーム化でき、顧客はプロバイダを変更でき、国際ネットワークは広範な地域にまたがることができる。RFC 1338 は、マルチホーミングとプロバイダ変更が例外または再番号付けを必要とする可能性があることを認めた。RFC 1366 自身の多地域および「その他」カテゴリは、整然とした政治地図がすべてのネットワーク配置を包含できないことを認識していた。
操作的なテキストのいずれも、ブロックの所有権をレジストリや人口に付与していない。地理的ラベルは、管理責任を組織し、アドレス空間を集約に備えた。それは権利書でも法的境界でもなかった。実際的な結果は依然として大きかったかもしれない。一度レジストリ、申請者、データベース、ブロックが地域的に配置されれば、将来の選択はその構造の中で行われる。しかし、制度の影響力は、分析的に財産とは異なる。
RFC 1367 は提案日付を計画に付した
RFC 1366 の同伴スケジュールであるRFC 1367は、Claudio Topolcic によって執筆され、1992 年 10 月に発行された。これも Informational であった。その文言はステータスについて異常に明確であった：それはスケジュールを提案し、そのスケジュールを草案と呼び、1992 年 7 月の IETF アドレッシングセッションと、IANA およびインターネットレジストリを含む多数の、ただしすべてではない知識のある関心のある当事者との議論から組み立てられたと述べた。
最初の目標である 1992 年 10 月 31 日は、初期の地域レジストリ基準が整い、IANA が将来のレジストリからの申請を受け付けることを要求した。クラス A 番号は事実上取得不可能とされた。クラス B 番号は合理的な正当化を必要とし、可能な限りクラス C ブロックが推奨された。クラス C 割り当てはアドレッシング計画に従い、中央インターネットレジストリは地域レジストリが指定されていない場合に行動する。
レビューと可能な再調整は 1993 年 2 月 14 日に予定された。4 月 15 日には、インターネットレジストリが適切なサイズのクラス C ブロックでアドレッシング計画の下ですべてのネットワークの割り当てを開始し、クラス B 番号の取得がより困難になることが期待された。最後に挙げられた日付である 1993 年 6 月 6 日は、インターネットにおけるアドレス集約メカニズムの利用可能が期待された日である。
これらの日付は、意図された順序と管理レベルを示している。IANA での基準と候補受付、カバレッジが欠けている場所での継続的な中央割り当て、より厳格なクラス B レビュー、連続クラス C ブロックのより広範な使用、および予想されるルーティングサポート。RFC 1367 は、これらの段階のいずれかの完了報告を含んでいなかった。公開討論への招待、不完全な協議、明示的な再調整ポイントはすべて、自己執行マンデートとしての扱いに抵抗する。
実装は別の場所で、機能ごとに確立されなければならない。委任されたブロック、転送された申請、データベース更新、ローカル再割り当て、逆引き DNS 委任、リクエスト評価、集約経路は異なる行為である。それらは必ずしも同じ日付に発生したわけではなく、スケジュールされた各マイルストーンの完了を証明するものでもない。
欧州は断片的に実装していた
欧州は、RFC 1366 が登場する前に地域の実践が発展していたため、最も明確な即時の証拠を提供する。記録は、RFC が発行され、それまで不活発だった地域が従ったという単純な連鎖ではない。運用手順、中央レジストリの決定、RIPE 調整、RFC 作業は重なり合っていた。
RIPE 65（1992 年 7 月 1 日付バージョン 0.6）は、RIPE ネットワーク調整センターが 5 月 1 日から欧州 IP ネットワーク番号の委任レジストリとして行動したと述べた。サービスプロバイダ、ネットワークインフォメーションセンター、ネットワーク運用センターに割り当て、個々の組織に直接割り当てないという方針を説明した。それらの中間者が申請者に番号を再割り当てする。
1993 年 10 月の遡及的レビューは、明確な順序を提供する。1993 年 10 月 25 日付のRIPE 99（NCC の最初の 18 か月を検討）は、その運用開始を 1992 年 4 月 1 日とした。中央インターネットレジストリが 1992 年 7 月に RIPE NCC に欧州組織からのすべての申請を処理するよう依頼したと述べた。RIPE 議長と関連作業部会との協議の後、NCC は手続きが不完全であるにもかかわらず受諾した。8 月 1 日から、中央に電子メールまたは書簡で届いた欧州のリクエストは RIPE NCC に転送された。
これらの日付は、矛盾なく異なる機能を説明できる。運用は 4 月に開始され、5 月から一部の委任レジストリ作業が報告され、7 月に包括的な欧州処理の中央要請が行われ、8 月に体系的な転送が開始された。「委任」は、ブロックの受領、ローカル再割り当て、特定の申請のレビュー、データベース作業、または通常の受け入れ先になることを包含し得る。文書はこれらの行為を 1 つの普遍的な移転日付に還元しない。
1992 年 10 月 16 日付バージョン 0.7 のRIPE 72は、再び 5 月 1 日からの委任レジストリ活動を説明した。完全なクラス C ブロックがサービスプロバイダとローカルネットワークセンターに移動し、要求に応じて未使用スペースが返却され、再割り当てが RIPE データベースに報告され、備蓄が回避され、適切なビット境界に整列された 2 のべき乗の連続割り当てが行われたことを文書化した。手続きは集約を予期していたが、スーパーネッティングはまだ正式に採用されていないとも述べた。普遍的なルーティング展開の前に手続きの互換性が存在した。
申請者に見える階層は、1993 年 3 月 23 日付の RIPE 83 に文書化された。このフォームは、欧州の以前は中央集権的だったプロセスが分散システムに置き換えられたと述べた。グローバルレジストリがブロックを RIPE NCC に委任し、RIPE NCC がローカルレジストリに委任し、申請者は一般にサービスプロバイダまたは非プロバイダローカルレジストリにアプローチする。クラス B 申請はローカルで開始されるが、ローカルレジストリが正当化されると判断した場合、レビューのために RIPE NCC に転送された。
このフォームは、現在のマシン数とサブネット数、1 年後と 2 年後の予測を尋ねた。接続性、既存の IP 番号、計画された運用国、ネットワーク構造に関する情報を要求した。管理登録データは公開 RIPE データベースに入り、評価に使用される技術情報は機密として説明された。これは生きた管理経路の強力な証拠である。ただし、フォームは結果の分布ではなく、要求される入力と定められた手続きを記録する。
RIPE 83 はまた、割り当て単位を可視化する。その例では、254、508、1,016、2,032、4,064、8,128 の使用可能ホスト計算を、1 つ、2 つ、4 つ、8 つ、16、32 のクラス C ネットワークにわたって使用した。そのシーケンスは、256 から 8,192 の生のアドレス合計とは異なる。表示された最大のクラス C の例は、RFC 1366 の通常の 16 ネットワークの上限を超えており、初期の実装がバイナリメカニズムを保持しながらその実用範囲を調整できることを示している。
最も詳細な限定的なワークロード証拠は、1993 年 3 月の四半期報告であるRIPE 87から得られる。報告四半期について、143 件の申請が受領されたと述べた。その印刷された受付経路は、グローバルインターネットレジストリから 51 件、RIPE NCC に直接送られた 86 件、ローカルレジストリから受領された 5 件であった。これらの小計は 142 になり、143 ではない。報告は、1 件の申請の差を調整する第 4 のカテゴリや修正を提供していない。
RIPE 87 は、申請者が単に適切なローカルレジストリに案内され、RIPE NCC が申請を受領しなかった単純な紹介を明示的に除外した。したがって、143 件の合計は、すべての欧州アドレス問い合わせ、すべてのローカルレジストリリクエスト、または四半期中に番号を求めるすべての組織の分母ではない。また、86 件の直接提出は、地域システムの成功したバイパスを確立できない。それらは地域センターが受領した申請であり、申請者が地域管理を回避したり、中央でサービスを受けたりした証拠ではない。
同じ四半期ログは、記録されたリクエスト集団の応答時間測定を報告した。リクエストの 82.5%が受領日に回答され（単なる受領確認ではなく）、97.9%が RIPE NCC による受領から 7 暦日以内に回答されたと述べた。また、NCC を通じて処理されたクラス C 割り当ての平均経過時間は 5 日弱、クラス B 割り当てでは 10 日弱と別に報告した。
これらのタイミングは、1993 年 3 月の報告四半期と RIPE 87 によって説明された集団に属する。報告は、各タイミングカテゴリの基礎となるカウントを公開せず、すべての結果タイプを区別せず、単純な紹介を含めず、ローカルレジストリによって完全に完了された申請を測定しなかった。応答は必ずしも割り当てではなく、四半期サービス統計は、可能なすべてのレジストリ配置の比較尺度ではない。
RIPE 87 はまた、評価されたクラス B ケースの 90%以上が、グローバルレジストリと IANA と合意された基準の下で正当化されていないと判断されたと述べた。何件のクラス B ケースが評価されたかは述べておらず、したがって分子はパーセンテージから回復できない。説明された手続きでは、そのようなケースはクラス C 割り当てのために適切なローカルレジストリに転送された。クラス B 基準の下での「正当化されていない」は、拒否、申請者の害、上訴、またはアドレス空間の取得の最終的な失敗の完全な台帳に変換されるべきではない。
RIPE 87 のアドレス空間セクションは、四半期中に RIPE NCC が 14 のクラス B ネットワーク番号を割り当て、32 のクラス C ネットワーク番号ブロックを委任し、15 のクラス C ブロックを予約したと報告した。四半期中に欧州のレジストリが 3,235 のクラス C ネットワークを割り当て、1993 年 3 月の四半期終了時点で報告された割り当て済みネットワーク番号の合計は 10,348 になったと述べた。これらは異なるレベルでの管理単位である。個々のクラス B ネットワーク番号、委任または予約されたブロック、割り当てられたクラス C ネットワーク番号。いずれも申請者数ではない。
RIPE 87 はまた、ネーミングシステムにおける別個の実装行為を記録している。193.in-addr.arpa 逆引き DNS ゾーンが 1993 年 3 月 16 日に RIPE NCC に委任され、報告の観測点までにクラス C ブロックを保持するローカルレジストリに 11 のサブドメインが引き続き委任されたと述べた。単位はそのゾーンの下での逆引き DNS サブドメインであり、アドレス申請や割り当て決定ではない。これは、RFC 1367 のルーティングマイルストーンの完了を証明することなく、割り当て台帳を超えた運用階層を示している。
年次および遡及的な合計は別個の扱いを必要とする。1993 年 9 月 3 日に「RIPE NCC の最初の一年」として公開されたRIPE 92は、1992 年 4 月から 1993 年 3 月までの運用年度を説明し、10,000 を超える IP ネットワーク番号が割り当てられたと述べた。単位は欧州レジストリシステムを通じて割り当てられたネットワーク番号であり、生の IPv4 値や申請者組織ではない。その丸められた声明は、3 月の四半期末の RIPE 87 の 10,348 と広く互換性がある。
RIPE 99 は後に、1 年間の運用後、欧州レジストリシステムは 14,000 を超える IP ネットワーク番号を割り当てたと述べた。これも最初の年に関する遡及的な主張であるが、RIPE 87 の 10,348 や RIPE 92 の「10,000 超」よりも実質的に高い。利用可能な報告は、これら 3 つの数字を調整するのに十分な共通の固定データセット、カットオフ、履歴エントリの扱い、遡及的コンパイルルール、または正確な分子を暴露していない。安全な説明は、組み合わせた合計を製造するのではなく、各ソース、日付、ウィンドウ、単位を保存する。
RIPE 99 のレジストリ数は異なる観測点を指す。1993 年 10 月 25 日、NCC 運用 18 か月後、分散システムは当時、60 を超えるサービスプロバイダレジストリと 21 の非サービスプロバイダ国別レジストリと共に整備されていたと述べた。それらは 10 月のレビュー日付で存在すると報告されたレジストリである。それらを後方に移動させ、初年度の数としてラベル付けすべきではない。
RIPE 99 は RIPE レビューパネルによって執筆され、RIPE の見解を代表するものとして承認された。NCC の正確性と適時性を賞賛し、レジストリ機能は極めてよく処理されたと述べた。これは、作業に近い機関からの貴重な同時代の証拠である。それはすべての欧州オペレーターの独立した調査ではない。報告の RIPE 内での同意への言及は、RIPE の参加者層とその内部プロセスに関係するものであり、レジストリ階層の影響を受けるすべてのプロバイダ、加入者、申請者の分母を提供するものではない。
レビューはまた、即興を文書化した。1991 年 5 月の NCC 活動計画は、欧州 IP レジストリの役割を明示的に含んでいなかった。RIPE 99 によれば、元の計画を超える活動が提案され、RIPE 内で議論され、肯定的な結論に達した場合に実装された。1992 年 7 月の中央要請は、すべての手続きが整う前にレジストリ機能を加速させた。これは、事前に存在する包括的な地域委任の証拠ではなく、活発な調整機関を通じた適応の証拠である。
トップブロックレベルでは、現在のIANA IPv4 アドレス空間レジストリ（2025-10-10 に最終更新されたバージョン）は、193/8、194/8、195/8 を RIPE NCC の下に1993-05の日付でリストしている。これらは現在のレジストリにおける月レベルの日付である。それらは同時代の 1993 年 5 月のスナップショット、正確なサブ割り当て日付、移転記録、リクエストファイル、動機の証拠ではない。
それでも、193/8 の現在の行は公開されたマップに関連する。RFC 1366 は 192-193 を多地域ブロックに配置し、194-195 を欧州と特定していた。後のレジストリによる 193/8 の RIPE NCC 下での扱いは、1992 年 10 月のマップが不変の区画として適用されなかったことを示している。それ自体では、決定プロセスを説明したり、各下位レベルの委任の日付を特定したりすることはできない。
総合すると、欧州の記録は、調整センターの運営、ブロックの受領、ローカルレジストリを通じた再割り当て、申請の転送、リクエストの評価、登録データの交換、逆引き DNS 責任の委任、トップレベルのアドレス管理の記録といった、一連の別個の行為としての実装を示している。この連鎖は現実のものだったが、同時でもなければ、単一の委任日付に還元できるものでもない。
運用記録が確立するもの
最も強力な実装証拠は、分散サービスに関するものである。RFC 1174 は委任を推奨し、RFC 1366 は地域資格と地理的ブロック計画を提供し、RIPE 65 と RIPE 72 は動作する割り当て手続きを文書化し、RIPE 83 は申請者をグローバル-地域-ローカルの階層に導き、RIPE 87 は結果として生じた作業負荷の一部を測定した。これは制度の願望を超えるものである。
中央フォールバックは異なる証拠特性を持つ。RFC 1366 は、インターネットレジストリが必要な場合に加入者にサービスを提供する準備ができていると約束した。RIPE 99 は、中央に届いた欧州の申請が 1992 年 8 月 1 日から RIPE NCC に転送されたと述べた。その後、RIPE 87 はグローバルレジストリから四半期に 51 件の申請が受領されたと記録したが、それらは地域プロセスに転送された。レビューされた記録には、センターによって直接サービスを受けた申請者、地域に紹介された申請者、例外が許可された申請者、または中央処理を主張することを許された申請者の完全なログが欠けている。
連続割り当てもまた、提案から手続きへと移行した。RIPE 文書は 2 のべき乗、整列されたブロック、予測需要を使用した。しかし、管理上の準備とルーティング効果は別個のままだった。割り当て報告は、集約がアナウンスされたか、特定のルーターで受け入れられたか、マルチホーミングによって分割されたか、より具体的な経路によって置き換えられたかどうかを測定しない。Merit シリーズは特定された視点でのルーティング圧力を説明し、レジストリ記録は割り当て活動を説明した。
運用能力はいくらかの遡及的な支持を得た。RIPE 87 は応答時間と作業負荷測定を公開し、RIPE 99 は正確性と適時性を賞賛した。これらの観察は RIPE NCC の初期のパフォーマンスに関するものである。RFC 1366 は選定前の数値ベンチマークを設定していなかったため、後の成功は候補評価を再構築したり、どの代替案が検討されたかを確立したりすることはできない。
認知は再現可能性が低い。RIPE は確立された調整役割、参加組織、RARE を通じた正式な枠組みを持っていた。これらの事実は、レジストリ機能の外部での地位に対する RFC 1366 の選好に適合する。欠けているのは、地域プロバイダと加入者の完全なリスト、支持と異議の記録、競合する候補の提出、「広く認知されている」ことを示す文書化されたテストである。
欧州はまた、1 つの地域レジストリがいかに実質的な多数性と共存し得るかを示している。サービスプロバイダおよび国別レジストリは、RIPE NCC の下で申請者を処理した。センターは地域層でブロック、手続き、データベース関係を調整した。したがって、1 レジストリ条項は、すべての顧客とのやり取りを中央集権化するのではなく、特定の層に権限を集中させた。
運用記録が解決できないのは、その集中に付随する期間と救済策である。レビューされた文書は、固定された指定期間、定期的な認定、ピア地域プロバイダ間の申請者ポータビリティ、自動置換トリガー、同じレベルで第 2 のレジストリを設立するための透明な手続きを明らかにしていない。継続的な依存は時間とともに実際的な正統性を強化し得るが、それは選定の瞬間に省略された認可プロセスを再創造するわけではない。
アクター、権限、そして欠けている救済策
この歴史における権限は、一般的である前に機能的であった。IANA は数値識別子を調整した。インターネットレジストリは中央登録および割り当て機能を維持した。連邦および国際計画グループは提案をレビューした。IETF 参加者は技術メカニズムを開発した。RIPE は参加する欧州ネットワークを調整した。RIPE NCC とローカルレジストリは管理作業を処理した。オペレーターはルーティングと相互接続を決定し、申請者は結果として生じる手続きの下でリソースを求めた。
IANA とインターネットレジストリは、ブロックを予約し、レジストリを承認し、ルート記録を維持し、選択されたサービスパスを通じて申請をルーティングする実際的な能力を有していた。その能力は、当時使用されていたシステムの内部における運用権限の証拠である。それは、現在または将来のすべてのオペレーターが無制限の制度的委任を付与したという記録ではない。
FEPG のレビューは、提案を連邦ネットワーキング調整に結びつけた。IEPG と IETF アドレッシング議論は技術的設定を広げた。RIPE は地域の専門知識と実装経験を追加した。それぞれが有意義であったが、レビューされた証拠に基づけば、いずれも列挙された世界的な有権者を代表していなかった。
RIPE の二重の役割は、軽視も誇張もされるべきではない。それは、調整センターが欧州レジストリになりつつある間に、レビューに貢献した。実装に最も近い機関は、しばしば最も関連性の高い専門知識を有する。それらはまた、自らが形成を助けるアーキテクチャの受益者にもなり得る。RIPE の報告は、その手続き、活動、制度的見解の一次証拠であり、未定義の地域全体にわたる同意の独立した証明ではない。
申請はサービスパスへの依存を示すが、リクエストの提出は必ずしも制度構造のすべての特徴を支持することを意味しない。オペレーターは、プロセスが有用である、認識されている、または事実上不可避であるために従うかもしれない。データベース報告、ルーティング協力、ローカルレジストリ参加は、実践を通じて正統性を構築し得る。それらは依然として、誰が地域組織を指定、監査、置換できるかという質問とは異なる質問に答える。
ここでレビューされた記録には、完全な著者の起草アーカイブ、FEPG または IEPG の通信一式、IETF Addressing BOF のトランスクリプト、候補レジストリの比較、地域支持の分母、異議台帳、指定上訴ファイルが含まれていない。このギャップは隠れた反対に変換されるべきではない。それは同様に、沈黙が測定されたコンセンサスになるのを防ぐ。
より強力な認可の歴史は、指名された機関が代表すると主張した支持者層とそれらを結びつける証拠を必要とするだろう。候補の提出、評価記録、プロバイダや加入者との通信、文書化された異議、中央サービスの例外、置換議論、認知がどのように評価されたかを説明する決定。そのような資料がなければ、初期の記録は、技術的に理由付けられ、運用上実装された取り決めを確立するが、包括的な委任は不完全なままにしている。
当時実現可能だった代替案は現代の共有台帳ではなかった
有用な反事実は、分散の必要性を受け入れることから始まる。1992 年までに、純粋に中央集権的な受け入れサービスは、国際的な成長、言語、地域手続き、管理規模と調和させることがますます困難になっていた。より鋭い質問は、分散サービスが地域層での単一プロバイダを必要としたかどうかである。
当時実現可能な代替案の 1 つは、RFC 1174 の実際のデータベースアーキテクチャに従った。複数の認定された受け入れまたは割り当てサービスが、広範な地域内で申請者を処理し、中央インターネットレジストリが権威ある更新を直列化することができた。委任されたサービスは、別個のアドレスプールを受け取り、共通の基準を適用し、変更を 1 つの中央更新キューに提出する可能性がある。その後、複製されたコピーがアクセスと冗長性のために再配布される。
これは真のマルチライター複製ではなかった。中央インターネットレジストリは、変更を順序付け、重複割り当てを防ぐ権威であり続ける。そのような設計は、複数の機関が同時に同じ権威ある状態を編集することを要求せずに、複数のサービスインターフェースを提供できる。そのボトルネックは中央更新パスである。遅延、停止復旧、提出遅延後の調整には依然として明示的な手続きが必要である。
衝突防止は、厳格なプール分割か、割り当て前の中央確認のいずれかに依存する。分割されたブロックでは、各サービスはピアと衝突することなく自身の範囲内で行動できるが、未使用の容量が遊休化し、再バランスには調整された移転が必要になる。中央確認では、プールはより柔軟になり得るが、申請者とレジストリは更新遅延と中央中断に対する脆弱性を経験する。
集約は別のトレードオフを導入する。各サービスに別個の連続プールを割り当てると、広範な集約を保持できる。申請者がアドレスを保持しながらプロバイダを切り替えることを許可すると、それらの集約に穴が開いたり、より具体的なルーティングが必要になる可能性がある。切り替え時に再番号付けを要求すると、申請者の移行作業を犠牲にして集約を保護する。したがって、代替案は、単なる追加のフロントデスクではなく、アドレス継続性のルールを必要とした。
ローカル言語サービスは、特に 1 つのセンターが均等にサービスを提供するにはあまりに多様な地域全体で、専門化されたプロバイダを通じて改善し得る。また、不均等になる可能性もある。収益性の高い、またはよく接続されたコミュニティは複数のレジストリを引き付ける一方で、他のコミュニティはほとんどカバレッジを受けないかもしれない。認定は、競争が公平に分散すると仮定するのではなく、地理的および言語的リーチを評価する必要がある。
共通基準は独自のガバナンス問題を生み出す。複数のプロバイダが予測需要やクラス B の正当化を異なって解釈し、申請者が最も寛容なサービスを選択するように促す可能性がある。そのようなフォーラムショッピングを防ぐには、監査、共有ガイダンス、分岐した結果のレビュー、およびプロバイダを是正または停止する権限が必要になる。複数性は、認定および監査層が信頼できる場合にのみ、1 つのレジストリへの依存を減らす。
中央フォールバックも定義を必要とする。ルートが、地域プロバイダが遅いまたは制限的である場合にはいつでも申請を受け付けると、競合サービスになり、地域計画を損なう可能性がある。自動的に申請者を紹介し返すと、実際的な冗長性をほとんど提供しない。実行可能な代替案は、センターがいつ介入するか、地域決定を覆すことができるかどうか、直接サービスが運用上の例外なのか真のレビュー経路なのかを指定する必要があった。
障害復旧も同様に具体的である。地域サービスは、スタッフ、資金、接続性、またはデータベースの整合性を失う可能性がある。マルチサービスモデルの下では、別の認定プロバイダが受け入れを引き継ぐことができるが、権威ある記録、保留中の申請、未使用プールは安全に移転されなければならない。1 レジストリモデルの下では、センターまたはローカルレジストリが継続性を提供するかもしれないが、RFC 1366 はテストされた引き継ぎプロセスを説明していない。どちらの構造も、制度の失敗を無コストにはしなかった。
置換と上訴は分離されるべきである。申請者は、レジストリの削除を求めることなく、個々の割り当て決定に異議を唱えるかもしれない。プロバイダまたは地域の支持者層は、特定のリクエストに異議を唱えることなく、レジストリのパフォーマンスまたは認知に異議を唱えるかもしれない。最初の問題は基準と証拠のレビューを求め、2 番目は認定、監査、置換ルールを求める。RFC 1366 の直接中央連絡条項は、最初の問題に部分的にしか対処しておらず、2 番目は定義しなかった。
2 番目の、より野心的な代替案は、真のマルチライター複製を可能にしたであろう。複数のレジストリが権威ある状態を更新し、後に調整する。レビューされた当時の文書は、それを意図されたアーキテクチャとして確立していない。それには、競合のない割り当てパーティションまたは堅牢なトランザクション順序付け、認証された更新交換、分岐した記録の検出、ネットワーク分割後の復旧、どのライターが勝つかを決定するルールが必要だったであろう。現代風の共有台帳を 1992 年の努力のない選択肢として扱うことは、RFC 1174 が中央更新を保持した技術的理由を消し去ることになる。
1 レジストリ地域設計は、いくつかの調整コストを削減した。1 つの組織は、一貫したブロックを管理し、IANA およびインターネットレジストリとの単一の関係を維持し、1 つの地域手続きを適用し、下位のレジストリ階層を調整できた。そのローカルレジストリは、依然としてプロバイダ固有、国レベル、言語サービスのサービスを提供できた。これにより、地域層での単一性は、その下の分散と両立した。
その代償は集中依存である。地域組織が遅くなり、一貫性を欠き、リソース不足になり、または十分に代表的でなくなった場合、申請者は明示されたピア代替案を持たなかった。中央サービスは潜在的な冗長性を提供したが、紹介は申請者を同じ地域層に送り返す可能性があった。したがって、設計は参入基準と同様に、継続的なレビューと置換可能性を必要とした。
RFC 1366 は、説明責任メカニズムよりも調整の利点をより完全に明確にした。安定性、適時性、信頼性、認知を望ましい品質として特定したが、それらがどのように監視されるか、誰の証拠が数えられるか、指定がいつ満了するか、新しいレジストリがどのように現職を置き換えることができるかを定義しなかった。
反事実は、複数のプロバイダがより良い結果をもたらしたであろうことを証明しない。複数の認定サービスは、更新順序付け、プール管理、集約、再番号付け、監査、移行において実際のコストを伴ったであろう。比較が明らかにするのはより狭いことである。地域サービス、中央一意性、1 プロバイダ集中は 3 つの分離可能な選択肢であった。最初の 2 つに対する運用上の必要性は、それ自体では 3 つ目の恒久的な必要性を確立しなかった。
地域割り当てが考えられるようになった瞬間
RFC 1366 は、もはや独立して扱うことのできない問題を結びつけることによって、地域割り当てを具体化した。国際的な成長は単一のサービスインターフェースに負担をかけた。言語と管理の近接性は分散を支持した。クラス B の不足は古いサイジング習慣を持続不可能にした。ブロックが連続的で集約と互換性がない限り、複数のクラス C 割り当てはルーティング成長を脅かした。
RFC 1174 は基礎となるアーキテクチャを提供していた。IANA と中央インターネットレジストリを保持し、承認された組織を通じて割り当て機能を委任し、データベースコピーを配布しながら更新を集中化し、登録をネットワークポリシー執行から分離する。RFC 1366 は地域資格、地理的クラス C 計画、サイジングしきい値、地域層での 1 レジストリという明示的な選好を追加した。RFC 1367 は、すべてのマイルストーンが発生したことを証明することなく、提案日付をその計画に付した。
欧州は実践の最も強力な証拠を提供する。1992 年 4 月から 1993 年 10 月の間に、公開記録は、運用調整センター、委任レジストリ手続き、申請の中央転送、サービスプロバイダおよび国別レジストリ、クラス C ブロック委任、申請者フォーム、リクエスト評価、データベース調整、逆引き DNS 委任、および相当な報告された割り当て量を文書化する。これらの行為は異なる日付と異なる管理レベルで発生した。それらの統計は、単一のリクエスト、申請者、または認可台帳に集約することはできない。
1 レジストリ条項は、その運用上の達成の内部に属し、外部ではない。それは、多くのローカルサービス拠点を許可しながら、ブロックと手続きを調整する方法を提供した。また、地域層に依存を集中させた。RFC 1366 は中央ルートとフォールバックを保持したが、中央レビューの実際的な条件を不確かなままにした。
結果として得られた記録は、明確な境界で終わる。運用上の問題が対処された。制度の集中が追加された。日付付きの実装が観察できる。依然として欠けているのは、影響を受ける集団全体にわたる認可の完全な説明、認知の再現可能な尺度、指定された地域レジストリがその選定が依存した品質を満たさなくなった場合の上訴、置換、継続性の確立されたプロセスである。