RFC 1366 и момент, когда региональное распределение адресов стало мыслимым

Резюме

• RFC 1366 предлагал распределить регистрацию, сохранив центральную координацию IANA и Internet Registry, и географически сгруппировать пространство Class C, чтобы решить проблему удалённости обслуживания, дефицита при классовой адресации и агрегации маршрутов.
• Текст и ранняя европейская практика показывают реальную регионализацию, но не устанавливают постоянную территориальную эксклюзивность, право собственности, согласие всех операторов или полный механизм замены и апелляции.

Измеренная проблема сочетала административную нагрузку с архитектурным напряжением. В классовом снимке за июнь 1992 года RFC 1366 насчитал 49 выделенных слотов номеров сетей класса A из 126, 7 354 слота класса B из 16 383 и 44 014 слотов класса C из 2 097 151. Сети среднего размера было трудно обслуживать эффективно: номера класса B были дефицитны, но выдача множества несвязанных сетей класса C увеличивала таблицы маршрутизации.

RFC 1366 отвечал на это распределением регистрации, резервированием географически организованных блоков класса C, выделением смежных групп с расчётом на 24-месячные прогнозы и сохранением IANA и центрального Internet Registry в качестве координирующих и резервных субъектов.

Самое сильное контраргументное свидетельство против любого описания открытой региональной конкуренции содержится в самом документе. RFC 1366 называл наличие одного регионального реестра на каждый географический регион важным условием эффективного и справедливого субраспределения. Это предпочтение он связывал с требованиями регионального признания, институциональной устойчивости, операционных ресурсов, соблюдения центральных руководств и координации субраспределения. В то же время абоненты по-прежнему могли обращаться в центральный Internet Registry, который оставался корневым и обещал обслуживание там, где это необходимо.

Таким образом, текст предлагал концентрацию на региональном уровне с центральным резервным механизмом, но не давал фиксированных региональных границ, срока назначения, регулярной процедуры аккредитации, сравнительной записи отбора, права на переносимость или опубликованного механизма замены.

Европейское внедрение шло через датированные, неодновременные действия. Документы RIPE относят начало работы Центра сетевой координации к 1 апреля 1992 года, описывают его как действующий делегированный реестр с 1 мая, фиксируют июльскую просьбу центрального Internet Registry о том, чтобы он обрабатывал европейские заявки, и датируют автоматическую пересылку таких заявок 1 августа. К концу квартала в марте 1993 года RIPE 87 сообщал о 10 348 назначенных номерах сетей и частичном журнале нагрузки в 143 заявки.

RIPE 92 позднее описывал более 10 000 номеров сетей за первый год работы, а RIPE 99 ретроспективно утверждал о более чем 14 000 за тот же год и отдельно сообщал на момент наблюдения 25 октября 1993 года, после 18 месяцев, о более чем 60 реестрах поставщиков услуг и 21 страновом реестре, не относящемся к поставщикам. Отчёты не раскрывают общий зафиксированный набор данных, по которому можно было бы согласовать эти показатели.

Ограниченный вывод существенен, но уже, чем конституционная история происхождения. RFC 1366 решал операционную задачу, добавлял предпочтение одного поставщика на региональном уровне и сопровождался наблюдаемым делегированием блоков, локальным переназначением, пересылкой заявок, обменом базами данных, рассмотрением запросов и делегированием обратного DNS в Европе. Это был информационный RFC, а не интернет-стандарт и не общеоператорское голосование.

Доступная документация указывает на технические и координационные круги, которые рассматривали или внедряли проект, но не содержит полного знаменателя затронутых операторов, сравнения кандидатов, реестра возражений, апелляции на назначение, процесса замены или доказательств того, что номинальный центральный резерв был практически одинаково пригоден для всех.

Октябрь 1992 года: центральная очередь встречается с растущей сетью

RFC 1366 «Руководство по управлению адресным пространством IP»был написан Элизой Герих из Merit Computer Network и опубликован в октябре 1992 года. Он однозначно заявлял свой статус: меморандум предоставлял информацию интернет-сообществу и не определял интернет-стандарт. Такая классификация не делала документ незначительным. Информационный 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 упоминались как внёсшие значительный вклад, истоки концепций относились к сессии IETF Addressing Birds of a Feather в Кембридже, штат Массачусетс, в июле 1992 года, а Джон Постел и Яков Рехтер назывались рецензентами и соавторами.

Это серьёзный контекст создания, но каждый субъект играл ограниченную роль. Герих была автором. FEPG и федеральный совет относились к федеральной сетевой структуре. IEPG обеспечивал международное участие в инженерном планировании. Сессия IETF BOF давала площадку для разработки и проверки технических идей. RIPE был одновременно координационным кругом и формирующимся исполнителем. IANA и центральный Internet Registry были субъектами, от которых ожидалось резервирование пространства, ведение корня, признание реестров и координация делегирования.

Сетевые провайдеры, абоненты, локальные реестры и заявители были затронутыми группами, а не взаимозаменяемыми с группами разработки и рассмотрения.

Поэтому фраза «общий консенсус» подтверждает лишь атрибутированное утверждение о названных рецензентах. RFC 1366 не даёт числа участников, списка присутствовавших, голосов, знаменателя аффилиаций или журнала возражений, по которым можно было бы рассчитать более широкую поддержку. Участие в обсуждении само по себе не является одобрением; внедрение не является ретроспективным голосованием. Ничто в этом ограничении не стирает компетентность или влияние участвовавших групп. Оно лишь не позволяет молчаливо расширять их рассмотрение до универсального операторского полномочия.

Практический контекст начался с роста и интернационализации. RFC 1366 отмечал, что спрос на номера сетей значительно вырос за предыдущие два года. Более разнообразное глобальное сообщество должно было взаимодействовать с центральной регистрационной службой, спроектированной в более ранней и географически концентрированной среде. Реестры, расположенные ближе к заявителям, могли обслуживать на соответствующих языках и эффективнее работать с местными административными обычаями. Распределение в этой трактовке прежде всего сокращало организационную дистанцию.

Оно изначально не требовало утверждения о том, что географические регионы обладают номерными ресурсами или политической юрисдикцией над ними.

Классовая адресация делала нагрузку не только проблемой обслуживания. Таблица 1 RFC 1366 приводила снимок за июнь 1992 года в единицах слотов номеров сетей. Для класса A 49 выделенных слотов, делённые на 126, дают 38,8889 процента, что округляется до 39 процентов, а не до напечатанных в RFC 38 процентов. Для класса B 7 354, делённые на 16 383, дают 44,8892 процента, что соответствует напечатанным 45 процентам. Для класса C 44 014, делённые на 2 097 151, дают 2,0988 процента, что соответствует напечатанным 2 процентам.

Первое расхождение следует оставить видимым, а не молча исправлять. Важнее то, что единицей таблицы были не заявители, организации, запросы, маршрутизируемые префиксы, отказы или используемые хосты. Она измеряла выделенные слоты номеров сетей в трёх классах на один административный момент. В ней нет знаменателя запросов, инвентаря позже возвращённых назначений и оценки того, насколько эффективно использовалась каждая назначенная сеть.

Дисбаланс тем не менее отражал реальную инженерную проблему. Сеть класса C давала небольшое поле хостов; сеть класса B предоставляла гораздо больше ёмкости, чем требовалось многим средним организациям. Щедрая выдача класса B расходовала сравнительно дефицитный средний класс. Замена несколькими независимо анонсируемыми сетями класса C экономила слоты класса B, но могла добавлять несколько записей маршрутизации. Политика регистрации, экономия адресов и рост таблиц маршрутизации оказались связанными.

У проблемы маршрутизации была эмпирическая точка отсчёта.RFC 1338, опубликованный в июне 1992 года, воспроизводил ежемесячный ряд анонсируемых маршрутов Merit, в котором было 1 525 маршрутов в апреле 1990 года и 4 775 в феврале 1992 года. Разница составляет 4 775 минус 1 525, то есть 3 250 дополнительных анонсируемых маршрутов. Относительно базового уровня апреля 1990 года это рост на 213,1 процента за 22 месяца.

RFC 1338 называл источником Merit и связывал цифры с маршрутной информацией без маршрутов по умолчанию, например из базы маршрутизации NSFNET. Это не была перепись всех маршрутизаторов. Единицей наблюдения был анонсируемый маршрут в этом ежемесячном ряду на две указанные даты, а не запрос адреса, заявитель, абонент, оператор, выделенная сеть или пользователь интернета. Его ценность состояла в демонстрации нагрузки в важной точке маршрутизации, а не в предоставлении универсального знаменателя.

Непрерывное выделение также не уменьшало автоматически наблюдаемую таблицу. RFC 1338 объяснял, что выгоды агрегации зависят от поддержки междоменной маршрутизацией произвольных пар «сеть-маска». Администрация адресов могла готовить агрегируемые блоки до того, как маршрутизаторы начинали использовать их как единые пункты назначения. Мультихоминг, смена провайдеров и исключения могли сохранять или вновь вводить более специфичные маршруты. Поэтому административный план был предпосылкой агрегации, а не доказательством того, что агрегация уже развёрнута или что каждый маршрутизатор наблюдал одинаковый результат.

RFC 1366 соединял эти нагрузки в один ответ. Регистрация должна была стать распределённой. Большая часть пространства номеров сетей класса C должна была быть разделена на широкие географические блоки. Назначения внутри блоков должны были использовать смежные степени двойки с размером под прогнозируемую потребность. IANA и центральный Internet Registry должны были сохранить координационные функции, ответственность за более строго контролируемые классы и обслуживание там, где регионального реестра нет.

Документ также обозначал свой горизонт. Его рекомендации претендовали на отсрочку исчерпания, а не на его бессрочное предотвращение. Большая верхняя часть тогда в основном неназначенного диапазона класса C должна была оставаться в резерве до дальнейшего уведомления. План стремился сохранить работоспособность существующей архитектуры, пока развивались технологии адресации и маршрутизации. Срочность двигала проектом; текст не утверждал, что создал вечное урегулирование.

RFC 1174 уже распределил обслуживание, не упразднив центр

Предшествующая архитектура появилась двумя годами ранее вRFC 1174, автором которого был Винтон Серф и который был опубликован в августе 1990 года. Этот документ также был информационным и прямо представлял рекомендации, а не интернет-стандарт. Он фиксировал официальную позицию Internet Activities Board в рекомендациях Federal Networking Council.

RFC 1174 предлагал сохранить централизованные функции IANA и Internet Registry. В то время функция IANA выполнялась в Information Sciences Institute Университета Южной Калифорнии, а DDN Network Information Center Института SRI выполнял функцию Internet Registry для номеров сетей и автономных систем. Internet Registry должен был оставаться главным реестром и реестром по умолчанию там, где не был определён делегированный регистрационный орган.

Распределение должно было происходить через контролируемое делегирование. Internet Registry мог выделять блоки номеров сетей и автономных систем организациям, одобренным Coordinating Committee for Intercontinental Research Networking, и предоставлять им полномочия дальнейшего назначения. Кандидаты-реестры должны были встретиться с IANA и Internet Registry, изучить операционные требования и документировать предлагаемый распределённый режим работы.

Проект базы данных показывает, насколько ограниченным было это распределение. RFC 1174 рекомендовал агрегированные регистрационные базы данных, поддерживаемые Internet Registry, с копиями, предоставляемыми делегированным реестрам для избыточности и доступа. Однако обновления должны были оставаться централизованными в Internet Registry; полные копии затем могли распространяться через передачу файлов или другим своевременным методом. Это была архитектура с реплицируемым чтением и централизованным обновлением.

Она предлагала несколько точек обслуживания, не предполагая, что несколько независимых писателей могут безопасно изменять авторитетный реестр одновременно.

Это различие важно для институционального анализа. Распределение не означало, что каждый делегированный реестр обладал самодостаточным пространством имён или что центральный контроль уникальности исчезал. Локальная или региональная служба могла принимать заявки и осуществлять делегированные полномочия назначения, пока авторитетные обновления сериализовались централизованно. Центр оставался ответственным за предотвращение дублирующих идентификаторов и ведение полной записи.

RFC 1174 также рекомендовал отказаться от старого бинарного статуса «connected». Регистрация оказалась переплетена с разрешением подключаться к федерально спонсируемым интернет-объектам. По мере умножения коммерческих, академических, исследовательских, посреднических и неамериканских сетей эта бинарная категория перестала описывать разнообразие схем доступа и транзита. Документ предлагал собирать заявления о допустимом использовании, доступе и транзитной политике, разрешая зарегистрированным сетям входить в соответствующую базу имён независимо от федерально одобренной связности.

Это отделяло администрирование номеров от применения сетевой политики. Реестр мог фиксировать глобально уникальный номер, не решая каждый вопрос маршрутизации, межсоединения, транзита или допустимого использования. Администраторы сетей продолжали принимать такие решения в рамках собственной политики. Реестровый журнал был важнейшей координационной инфраструктурой, но контроль над журналом не означал автоматически всеобъемлющего контроля над работой сети.

Глаголы рекомендаций остаются важными. RFC 1174 предлагал, советовал и ожидал. Он не публиковал проверяемый список, показывающий, что каждое делегирование, процесс репликации или разделение политик завершены. Его маршрут утверждения через CCIRN, IANA и Internet Registry был определённым институциональным каналом, а не знаменателем всех операторов, которых это могло затронуть.

RFC 1366 унаследовал эту архитектуру, а не заменил её автономными территориальными реестрами. Он называл Internet Registry корнем, сохранял его в качестве реестра по умолчанию в непокрытых регионах, помещал распределённые реестры под руководства IANA и Internet Registry и оставлял прямой контакт как заявленную опцию. Регионализация включала реальное делегирование и региональную ответственность, но оставалась встроенной в центральную координацию.

Такая структура сопротивляется двум противоположным упрощениям. Одно сводит регионализацию к косметической децентрализации, потому что центр выжил. Но от региональных реестров ожидалось реальное выполнение ответственности за обслуживание и субраспределение. Другое трактует географические блоки как передачу суверенитета или собственности. RFC 1366 описывал резервирование, распределение, назначение, регистрацию и делегирование. Он не определял передачу права собственности.

Сложным словом было «один»

Самое сильное положение RFC 1366 о концентрации следует читать прямо: он называл «ровно один региональный реестр на географический регион на этом уровне» важным для эффективного и справедливого субраспределения. «Один» противостоял равноправным региональным реестрам, работающим на одном уровне над одной географической областью. «На этом уровне» оставляло место для множества реестров поставщиков услуг, страновых или иных локальных реестров ниже региональной организации. Центральный Internet Registry также оставался над ней и мог получать прямые обращения.

Единственность на региональном уровне была, таким образом, реальной, но не равнозначной одному офису, обрабатывающему каждую заявку, или исчезновению центрального обслуживания.

Остальные слова давали обоснование без полного проекта подотчётности. «Региональный» называл административный уровень, а не законодательный орган или суверенный народ. «Географический» связывал обслуживание и блоки распределения с широкими областями мира, оставляя нерешёнными установление границ и трансрегиональные сети. «Эффективный» правдоподобно относился к согласованному субраспределению, меньшему дублированию, снижению центральной нагрузки и блокам, удобным для агрегации, но RFC не содержал сравнительного анализа затрат.

«Справедливый» был заявленной целью без опубликованной метрики равенства, аудита решений, эталона обслуживания или пути апелляции. Предложение твёрдо устанавливает предпочтение одного поставщика. Без дальнейших доказательств оно не может зафиксировать срок назначения, доказать постоянную эксклюзивность, установить собственность или продемонстрировать согласие каждого оператора в зоне обслуживания.

Положение о прямом обслуживании не менее важно. RFC 1366 говорил, что абоненты могут обращаться в Internet Registry, в зависимости от обстоятельств могут быть направлены в региональный реестр и при необходимости могут обслуживаться централизованно. Это сохраняло корень и номинальный резерв. Документ не определял «необходимость», не указывал, когда можно сопротивляться направлению, не публиковал обязательство центра отвечать и не устанавливал, будет ли прямое обслуживание пересматривать решение регионального реестра.

Резерв внутри делегирующей иерархии не является автоматически переносимостью между равноправными поставщиками, а текстовая опция не является доказательством практической пригодности.

Положение об одном реестре заслуживает такого противовеса, но не размывания. Считать центральный резерв доказательством отсутствия эксклюзивности значило бы неверно прочитать предложенную многоуровневость. Считать региональное предпочтение безотзывным территориальным грантом значило бы выйти за пределы действующего языка. RFC 1366 проектировал концентрацию на одном уровне внутри централизованно координируемой иерархии.

Критерии отбора без воспроизводимой записи отбора

RFC 1366 пытался определить, чем должен быть региональный реестр, а не просто назвать доступную организацию. Он предлагал пять критериев. Вместе они показывают, что автор понимал делегирование как институциональное решение, а не только техническую конфигурацию. Они же обнажают, сколько в процедуре решения осталось невысказанным.

Во-первых, «сетевые органы» в пределах географической области должны были легитимизировать кандидата. У термина не было заданного знаменателя. Национальная исследовательская сеть, министерство, оператор связи, поставщик услуг, академический консорциум, участник стандартизации и форум сетевых операций могли претендовать на разный тип авторитета. RFC не называл обязательные категории, не определял, сколько одобрений достаточно, не объяснял, имеют ли возражения вес, и не говорил, как разрешать конфликтующие притязания.

Окружающий текст также требовал, чтобы реестр был непредвзятым и широко признанным сетевыми провайдерами и абонентами в своём регионе. «Широко» не было превращено в проверку. Это могло означать признание в разных странах, среди ведущих магистралей, внутри технического координационного форума или среди организаций, уже известных рецензентам. Списка провайдеров и абонентов приложено не было, поэтому ни один читатель не может воспроизвести коэффициент признания или выявить, какие затронутые организации отсутствовали.

Во-вторых, кандидат должен был быть устойчивым и обладать легитимностью вне реестровой функции. Это снижало риск доверить критическую координацию организации, чьё положение возникло только из её выбора. Существующая техническая работа, финансовая непрерывность, организационная зрелость и признанная координационная роль могли поддерживать критерий. Однако RFC не предлагал стандартного раскрытия финансов, проверки управления, оценки конфликтов или сравнительной оценочной карты.

В-третьих, организация должна была выделить достаточные ресурсы для стабильного, своевременного и надёжного обслуживания. Этот критерий был наиболее измерим через штат, бюджеты, время ответа, точность базы данных, доступность и планы непрерывности. Документ не устанавливал порогов и последствий, если производительность позже ухудшится.

В-четвёртых, реестр должен был распределять номера в соответствии с руководствами IANA и Internet Registry. В-пятых, он должен был координировать с центральным Internet Registry квалификацию и стратегии субраспределения. Эти условия ограничивали региональную автономию. Делегированному реестру не разрешалось строить несовместимую систему нумерации или игнорировать корневой реестр.

Язык и местные обычаи фигурировали в обосновании распределения, но не в пяти формальных критериях. RFC 1366 предполагал, что географически расположенные реестры могут эффективнее обслуживать сообщества в этих отношениях. Он не требовал определённого набора языков, переведённых форм, местных офисов или измеримого покрытия обслуживания. Обоснование было правдоподобным, особенно в быстро интернационализирующейся сети, но оно не было операционализировано как аккредитационный тест.

Цепочка принятия решений оставалась неполной. IANA и Internet Registry должны были наделять реестр полномочиями; региональные сетевые органы — легитимизировать его; кандидат — принять центральные правила. Текст оставляет открытым, кто проверял ресурсы, как сравнивались кандидаты, могли ли центральные субъекты выбрать одного вопреки региональным возражениям, обладала ли какая-либо сторона правом вето и что происходило, если признание позже снижалось.

Не было и опубликованной апелляции на назначение. Разочарованный кандидат не получал описанного процесса ознакомления с оценкой или запроса пересмотра. Абонент мог обратиться в центральный Internet Registry, но этот операционный путь не обязательно пересматривал статус региональной организации. Исправление обслуживания и институциональная замена были разными проблемами, и только первая получала хотя бы общий резерв.

Критерии, таким образом, делали региональное делегирование более дисциплинированным, чем неформальное удобство. Они не создавали воспроизводимого режима аккредитации и продления. Документация о создании подтверждает отбор узнаваемыми координирующими институтами по заявленным принципам; она оставляет нерешёнными широту, срок и оспоримость мандата.

Географические блоки были приёмом распределения, а не территорией

RFC 1366 предлагал разделить часть диапазона класса C на восемь равных блоков. Отметив, что префиксы 192 и 193 уже использовались, а значительная часть диапазона 194–223 оставалась неназначенной, он зарезервировал 208–223 до дальнейшего уведомления и сгруппировал 192–207 в пары блоков/8.

RFC описывал каждую пару как содержащую 131 072 «адреса», но действующей классовой единицей были 131 072 слота номеров сетей класса C. Каждый такой слот номинально соответствовал диапазону размером/24из 256 сырых значений IPv4. Умножение 131 072 на 256 даёт 33 554 432 сырых значения в каждом блоке из двух/8. Относительно знаменателя класса C в RFC 1366, равного 2 097 151 слоту номеров сетей, 131 072 слота составляли примерно 6,25 процента, что согласуется с округлённым описанием в документе — около 6 процентов.

Метки были предварительными и широкими: 192–193 — мультирегиональный; 194–195 — Европа; 196–197 — «Прочие»; 198–199 — Северная Америка; 200–201 — Центральная и Южная Америка; 202–203 — Тихоокеанский регион; 204–207 — ещё два блока «Прочие». Это не была зрелая карта пяти постоянных институтов. Она содержала четыре названные географические области, один мультирегиональный диапазон и три гибких диапазона.

Там, где существовал квалифицированный региональный реестр, ему могла делегироваться основная ответственность за распределение в соответствующем блоке. Там, где его не было, центральный Internet Registry продолжал назначения, следуя географическим делениям. Таким образом, география могла влиять на распределение ещё до выбора регионального института. План блоков и карта институционального покрытия были связаны, но не тождественны.

Назначения внутри блока должны были использовать смежные степени двойки на основе прогнозируемой потребности абонента на 24 месяца. Обычная последовательность: одна сеть класса C для менее 256 адресов, две смежные сети для менее 512, четыре для менее 1 024, восемь для менее 2 048 и шестнадцать для менее 4 096. Это были правила размера для назначения по плану, а не подсчёт запросов, заявителей или успешных решений.

Сырые адреса и пригодные к использованию хосты следует различать. Сеть/24содержит 256 сырых значений IPv4. При обычной для того периода трактовке идентификаторы хостов из всех нулей и всех единиц не были доступны обычным хостам, оставляя 254 пригодных идентификатора хостов. Шестнадцать смежных/24, следовательно, содержат 4 096 сырых значений, но 4 064 обычно используемых хоста. Обычный в RFC 1366 пример смежного класса C останавливался на шестнадцати сетях и направлял потребности выше 4 096 уникальных адресов к вероятному рассмотрению класса B.

Европейская форма, позже опубликованная какRIPE 83, показывала пример, расширенный до 32 сетей класса C. В принятой в этой форме конвенции о хостах 32 умножить на 254 давало 8 128 используемых хостов; те же 32/24содержали 8 192 сырых значения. Сравнение показывает преемственность в размере блоков степенями двойки, но не идентичный верхний порог. Форма, использовавшаяся в региональной практике, могла расширять отображаемый вариант класса C за пределы обычных шестнадцати сетей RFC 1366.

Класс B в RFC 1366 оставался под центральным контролем. Базовое условие документа требовало более 32 подсетей и более 4 096 хостов, с индивидуальным рассмотрением, когда блоки класса C были непрактичны. Региональный реестр мог помогать в оценке, но IANA и Internet Registry сохраняли ответственность за класс. Поэтому регионализация была существенной, но не всеобъемлющей по всем категориям адресов.

У географического плана были и маршрутные ограничения. Агрегация работает чище всего, когда иерархия распределения и топология маршрутизации совпадают. Провайдеры могут пересекать границы, организации могут быть мультихоминговыми, клиенты могут менять провайдеров, а международные сети могут охватывать широкие регионы. RFC 1338 признавал, что мультихоминг и смена провайдеров могут требовать исключений или перенумерации. Собственные категории RFC 1366 «мультирегиональный» и «Прочие» признавали, что аккуратная политическая карта не может вместить любую сетевую конфигурацию.

Ничто в действующем тексте не передавало право собственности на блок реестру или населению. Географическая метка организовывала административную ответственность и готовила адресное пространство к агрегации. Это не был ни титул, ни правовая граница. Практические последствия тем не менее могли быть значительными: как только реестры, заявители, базы данных и блоки выстраивались регионально, будущие решения происходили внутри этой структуры. Однако институциональное влияние аналитически отлично от собственности.

RFC 1367 поставил предлагаемые даты рядом с планом

Сопутствующий график RFC 1366,RFC 1367, был написан Клаудио Топольчиком и опубликован в октябре 1992 года. Он тоже был информационным. Его язык был необычно ясен о статусе: он предлагал график, называл этот график черновиком и говорил, что он собран по итогам июльской сессии IETF по адресации 1992 года и обсуждений с рядом — но не всеми — знающими и заинтересованными сторонами, включая IANA и Internet Registry.

Первая цель, 31 октября 1992 года, требовала наличия начальных критериев региональных реестров и приёма IANA запросов от потенциальных реестров. Номера класса A описывались как практически недостижимые. Номера класса B требовали разумного обоснования, причём там, где возможно, предпочитались блоки класса C. Распределение класса C должно было следовать плану адресации, а центральный Internet Registry действовать там, где региональный реестр не был назначен.

На 14 февраля 1993 года был запланирован пересмотр и возможная корректировка. На 15 апреля Internet Registry должен был начать распределять все сети по плану адресации блоками класса C подходящего размера, а номера класса B должны были стать труднее получить. Последняя указанная дата, 6 июня 1993 года, была ожидаемой доступностью механизма агрегации адресов в интернете.

Эти даты описывают предполагаемую последовательность и административный уровень: критерии и приём кандидатов в IANA, продолжение центрального распределения при отсутствии покрытия, более строгий пересмотр класса B, более широкое использование смежных блоков класса C и ожидаемая маршрутная поддержка. RFC 1367 не содержал отчётов о завершении ни одного из этих этапов. Его приглашение к открытому обсуждению, неполные консультации и явная корректировка противостоят трактовке как самоисполняющегося мандата.

Внедрение следует устанавливать отдельно и по функциям. Делегированный блок, пересланная заявка, обновление базы данных, локальное переназначение, делегирование обратного DNS, оценка запроса и агрегированный маршрут были разными действиями. Они не обязательно происходили в одну дату и не доказывали завершение каждой запланированной вехи.

Европа внедряла поэтапно

Европа даёт самое ясное непосредственное свидетельство, потому что региональная практика развивалась до появления RFC 1366. Документация не является простой цепочкой, в которой RFC был опубликован, а ранее неактивный регион подчинился. Рабочие процедуры, решения центрального реестра, координация RIPE и работа над RFC пересекались.

RIPE 65, версия 0.6 от 1 июля 1992 года, сообщал, что Центр сетевой координации RIPE действовал как делегированный реестр европейских номеров IP-сетей с 1 мая. В нём описывалась политика распределения поставщикам услуг, сетевым информационным центрам и центрам сетевых операций, а не напрямую отдельным организациям. Эти посредники должны были переназначать номера заявителям.

Ретроспективный обзор октября 1993 года даёт другую последовательность.RIPE 99от 25 октября 1993 года, рассматривавший первые 18 месяцев работы NCC, относил начало его работы к 1 апреля 1992 года. В нём говорилось, что центральный Internet Registry попросил RIPE NCC в июле 1992 года обрабатывать все заявки европейских организаций. После консультации с председателем RIPE и соответствующими рабочими группами NCC согласился, несмотря на неполные процедуры. С 1 августа европейские запросы, поступавшие централизованно по электронной почте или письмам, пересылались в RIPE NCC.

Эти даты могут описывать разные функции без противоречия. Работа началась в апреле; о части делегированной реестровой работы сообщалось с мая; центральный запрос о всеобъемлющей обработке европейских заявок поступил в июле; систематическая пересылка началась в августе. «Делегирование» могло охватывать получение блоков, локальное переназначение, рассмотрение части заявок, обязанности по базе данных или превращение в обычный пункт приёма. Документы не сводят эти действия к одной универсальной дате передачи.

RIPE 72, версия 0.7 от 16 октября 1992 года, снова описывал делегированную реестровую деятельность с 1 мая. В нём документировалась передача полных блоков класса C поставщикам услуг и локальным сетевым центрам, возврат неиспользуемого пространства по запросу, передача данных о переназначениях в базу RIPE, избегание накопления и смежные распределения степенями двойки, выровненные по подходящим битовым границам. Процедура предвосхищала агрегацию, но также говорила, что суперсети ещё не были формально приняты. Процедурная совместимость существовала до всеобщего развёртывания маршрутизации.

Иерархия, видимая заявителю, документировалась в RIPE 83 от 23 марта 1993 года. Форма сообщала, что прежний централизованный процесс в Европе был заменён распределённой системой: глобальный реестр делегировал блоки RIPE NCC, RIPE NCC делегировал локальным реестрам, а заявители обычно обращались к своему поставщику услуг или локальному реестру, не являющемуся поставщиком. Заявки класса B начинались локально, но пересылались в RIPE NCC для рассмотрения, если локальный реестр считал их обоснованными.

Форма запрашивала текущее количество машин и подсетей и прогнозы на один и два года вперёд. Она требовала информацию о связности, существующих IP-номерах, планируемых странах работы и структуре сети. Административные регистрационные данные должны были попадать в публичную базу RIPE, а техническая информация, использовавшаяся при оценке, описывалась как конфиденциальная. Это сильное свидетельство действующего административного пути. Однако форма фиксирует требуемые входные данные и заявленную процедуру, а не распределение результатов.

RIPE 83 также делает видимой единицу распределения. Его примеры использовали расчёты пригодных хостов 254, 508, 1 016, 2 032, 4 064 и 8 128 для одной, двух, четырёх, восьми, шестнадцати и 32 сетей класса C. Эта последовательность отличается от сумм сырых адресов от 256 до 8 192. Самый крупный показанный пример класса C превышал обычный потолок RFC 1366 в шестнадцать сетей, показывая, что ранняя практика могла сохранять бинарный механизм, корректируя его практический диапазон.

Самое подробное ограниченное свидетельство о нагрузке даётRIPE 87, квартальный отчёт за март 1993 года. За отчётный квартал в нём указывалось 143 полученные заявки. Напечатанные каналы поступления: 51 от глобального Internet Registry, 86 напрямую в RIPE NCC и 5 от локальных реестров. Эти промежуточные суммы дают 142, а не 143. Отчёт не даёт четвёртой категории или исправления, которое согласовало бы разницу в одну заявку.

RIPE 87 прямо исключал простые перенаправления, при которых заявителя лишь направляли к соответствующему локальному реестру без получения заявки RIPE NCC. Поэтому 143 не являются знаменателем для каждого европейского запроса адресов, каждого запроса локального реестра или каждой организации, искавшей номера в этом квартале. Нельзя и 86 прямых обращений считать доказательством успешного обхода региональной системы: это были заявки, полученные региональным центром, а не свидетельство того, что заявитель избежал регионального администрирования или получил обслуживание централизованно.

Тот же квартальный журнал сообщал показатели времени ответа для зафиксированной популяции запросов. В нём говорилось, что 82,5 процента запросов получали ответ — а не только подтверждение — в день поступления, а 97,9 процента — в течение семи календарных дней с момента получения RIPE NCC. Отдельно сообщалось о среднем времени чуть менее пяти дней для распределения класса C через NCC и чуть менее десяти дней для распределения класса B.

Эти сроки относятся к отчётному кварталу марта 1993 года и популяциям, описанным RIPE 87. Отчёт не публиковал исходные количества для каждой категории сроков, не различал каждый тип результата, не включал простые перенаправления и не измерял заявки, полностью завершённые локальными реестрами. Ответ не обязательно является распределением, а квартальная статистика обслуживания не является сравнительной мерой любого возможного устройства реестров.

RIPE 87 также сообщал, что более 90 процентов оценённых случаев класса B были признаны необоснованными по критериям, согласованным с глобальным реестром и IANA. Он не указывал, сколько случаев класса B было оценено, поэтому числитель нельзя восстановить из процента. В описанной процедуре такие случаи пересылались соответствующему локальному реестру для назначения класса C. «Необоснованные» по критериям класса B не следует превращать в полный журнал отказов, вреда заявителям, апелляций или конечной неудачи в получении адресного пространства.

Раздел адресного пространства RIPE 87 сообщал, что в течение квартала RIPE NCC назначил 14 номеров сетей класса B, делегировал 32 блока номеров сетей класса C и зарезервировал 15 блоков класса C. В нём говорилось, что европейские реестры назначили 3 235 сетей класса C за квартал, доведя общий зарегистрированный показатель до 10 348 назначенных номеров сетей на конец квартала марта 1993 года. Это административные единицы на разных уровнях: отдельные номера сетей класса B, делегированные или зарезервированные блоки и назначенные номера сетей класса C. Ни одна из них не является числом заявителей.

RIPE 87 также фиксирует отдельное действие внедрения в системе имён. В нём говорилось, что зона обратного DNS 193.in-addr.arpa была делегирована RIPE NCC 16 марта 1993 года и что к моменту наблюдения отчёта 11 поддоменов были делегированы локальным реестрам, владеющим блоками класса C. Единицей были поддомены обратного DNS в этой зоне, а не заявки на адреса или решения о распределении. Это демонстрирует операционную иерархию за пределами журнала назначений, не доказывая завершения маршрутной вехи RFC 1367.

Годовые и ретроспективные показатели требуют отдельного рассмотрения.RIPE 92, опубликованный 3 сентября 1993 года как «Первый год RIPE NCC», описывал операционный год с апреля 1992 по март 1993 года и сообщал о более чем 10 000 назначенных номеров IP-сетей. Единицей были номера сетей, назначенные через европейскую систему реестров, а не сырые значения IPv4 или организации-заявители. Округлённое утверждение в целом совместимо с 10 348 из RIPE 87 на конец мартовского квартала.

RIPE 99 позже сообщал, что через год работы европейская система реестров назначила более 14 000 номеров IP-сетей. Это также ретроспективное утверждение о первом годе, но оно существенно выше, чем 10 348 из RIPE 87 и «более 10 000» из RIPE 92. Доступные отчёты не раскрывают общий зафиксированный набор данных, точку отсечения, подход к историческим записям, правило ретроспективной компиляции или точный числитель, достаточные для согласования трёх цифр. Безопасное изложение сохраняет каждый источник, дату, окно и единицу, а не фабрикует комбинированный итог.

Подсчёты реестров RIPE 99 относятся к другой точке наблюдения. На 25 октября 1993 года, после 18 месяцев работы NCC, в нём говорилось, что распределённая система уже действовала и включала более 60 реестров поставщиков услуг и 21 страновой реестр, не являющийся поставщиком. Это реестры, существовавшие по данным на дату октябрьского обзора. Их не следует переносить назад и называть показателями первого года.

RIPE 99 был написан наблюдательной группой RIPE и одобрен как выражающий позицию RIPE. В нём высоко оценивались точность и своевременность NCC, а реестровая функция называлась выполненной исключительно хорошо. Это ценное современное свидетельство института, близкого к работе. Оно не является независимым опросом каждого европейского оператора. Ссылки отчёта на согласие внутри RIPE касаются круга RIPE и его внутренних процессов; они не дают знаменателя для всех провайдеров, абонентов или заявителей, затронутых иерархией реестров.

Обзор также документировал импровизацию. План деятельности NCC от мая 1991 года явно не включал роль европейского IP-реестра. Согласно RIPE 99, активности за пределами первоначального плана предлагались, обсуждались внутри RIPE и внедрялись там, где достигался положительный вывод. Июльский центральный запрос 1992 года ускорил реестровую функцию до того, как все процедуры были улажены. Это свидетельство адаптации через активный координационный орган, а не доказательство заранее существовавшего всеобъемлющего регионального мандата.

На уровне верхних блоков текущийРеестр адресного пространства IPv4 IANAв версии, последний раз обновлённой 10 октября 2025 года, перечисляет 193/8, 194/8 и 195/8 за RIPE NCC с датами1993-05. Это даты уровня месяца в текущем реестре. Они не являются современным снимком мая 1993 года, точными датами субраспределения, записями передачи, файлами запросов или доказательством мотива.

Текущая строка для 193/8 тем не менее имеет отношение к опубликованной карте. RFC 1366 помещал 192–193 в мультирегиональный блок и определял 194–195 для Европы. Трактовка 193/8 за RIPE NCC в более позднем реестре показывает, что карта октября 1992 года не применялась как неизменный раздел. Сама по себе она не может объяснить процесс решения или датировать каждое делегирование нижнего уровня.

В совокупности европейская документация показывает внедрение как цепочку отдельных действий: работа координационного центра, получение блоков, переназначение через локальные реестры, пересылка заявок, оценка запросов, обмен регистрационными данными, делегирование ответственности за обратный DNS и фиксация администрирования адресов верхнего уровня. Цепочка была реальной, но не одновременной и не сводимой к одной дате мандата.

Что устанавливает операционная документация

Самое сильное свидетельство внедрения касается распределённого обслуживания. RFC 1174 рекомендовал делегирование; RFC 1366 дал региональные квалификации и план географических блоков; RIPE 65 и RIPE 72 документально зафиксировали рабочие процедуры распределения; RIPE 83 направлял заявителей через глобально-регионально-локальную иерархию; RIPE 87 измерял часть возникшей нагрузки. Это больше, чем институциональное стремление.

У центрального резерва другой доказательственный профиль. RFC 1366 обещал, что Internet Registry останется готовым обслуживать абонентов там, где необходимо. RIPE 99 сообщал, что европейские заявки, поступавшие централизованно, пересылались в RIPE NCC с 1 августа 1992 года. RIPE 87 затем зафиксировал 51 квартальную заявку, полученную от глобального реестра, но они пересылались в региональный процесс. Изученная документация не содержит полного журнала заявителей, обслуженных центром напрямую, направленных регионально, получивших исключение или получивших право настаивать на центральной обработке.

Смежное распределение также перешло от предложения к процедуре. Документы RIPE использовали степени двойки, выровненные блоки и прогнозируемый спрос. Однако административная готовность и маршрутный эффект оставались разными. Отчёты о распределении не измеряют, был ли агрегат анонсирован, принят на конкретном маршрутизаторе, разделён мультихомингом или вытеснен более специфичными маршрутами. Ряд Merit описывал маршрутное давление в определённой точке наблюдения; реестровые записи описывали деятельность по распределению.

Операционная компетентность получила некоторую ретроспективную поддержку. RIPE 87 публиковал время ответа и показатели нагрузки, а RIPE 99 высоко оценивал точность и своевременность. Эти наблюдения касаются ранней работы RIPE NCC. RFC 1366 не устанавливал числовых ориентиров перед выбором, поэтому более поздний успех не может воссоздать оценку кандидатов или установить, какие альтернативы рассматривались.

Признание менее воспроизводимо. У RIPE была устоявшаяся координационная роль, участвующие организации и формальная рамка через RARE. Эти факты соответствуют предпочтению RFC 1366 в пользу устойчивости вне реестровой функции. Отсутствуют полный список региональных провайдеров и абонентов, запись одобрений и возражений, конкурирующие заявки кандидатов и задокументированная проверка «широкого признания».

Европа также показывает, как один региональный реестр мог сосуществовать со значительной множественностью. Реестры поставщиков услуг и страновые реестры обслуживали заявителей ниже RIPE NCC. Центр координировал блоки, процедуры и отношения баз данных на региональном уровне. Положение об одном реестре, следовательно, концентрировало полномочия на определённом уровне, а не централизовало каждое взаимодействие с клиентом.

Чего операционная документация не может установить, так это срока и средства защиты, привязанных к этой концентрации. Изученные документы не выявляют фиксированного периода назначения, периодической аккредитации, переносимости заявителя между равными региональными поставщиками, автоматического триггера замены или прозрачной процедуры создания второго реестра на том же уровне. Продолжающаяся опора может со временем укреплять практическую легитимность, но не воссоздаёт пропущенный процесс авторизации в момент выбора.

Субъекты, полномочия и отсутствующее средство защиты

Полномочия в этой истории были функциональными раньше, чем общими. IANA координировала числовые идентификаторы. Internet Registry поддерживал центральные функции регистрации и назначения. Федеральные и международные группы планирования рассматривали предложения. Участники IETF разрабатывали технические механизмы. RIPE координировал участвующие европейские сети. RIPE NCC и локальные реестры обрабатывали административную работу. Операторы определяли маршрутизацию и межсоединения; заявители искали ресурсы в рамках возникших процедур.

IANA и Internet Registry обладали практической способностью резервировать блоки, признавать реестр, вести корневую запись и направлять заявки по выбранному пути обслуживания. Эта способность является свидетельством действующих полномочий внутри системы, использовавшейся тогда. Она не является записью того, что каждый настоящий или будущий оператор предоставил неограниченный институциональный мандат.

Рассмотрение FEPG связывало предложение с федеральной сетевой координацией. IEPG и обсуждение адресации в IETF расширяли технический контекст. RIPE добавлял региональную экспертизу и опыт внедрения. Каждый из них был значим; ни один, по изученным свидетельствам, не представлял перечисленный всемирный электорат.

Двойная роль RIPE не заслуживает ни отбрасывания, ни преувеличения. Он участвовал в рассмотрении, пока его координационный центр становился европейским реестром. Институты, ближайшие к внедрению, часто обладают самой релевантной экспертизой. Они также могут становиться бенефициарами архитектуры, которую помогают формировать. Отчёты RIPE являются первичным свидетельством его процедур, деятельности и институциональной позиции, а не независимым доказательством согласия в пределах неопределённого региона.

Заявки показывают зависимость от пути обслуживания, но подача запроса не обязательно одобряет каждую черту институциональной структуры. Оператор может следовать процедуре, потому что она полезна, признана или практически неизбежна. Отчётность в базе данных, сотрудничество в маршрутизации и участие локальных реестров могут укреплять легитимность через практику. Они всё же отвечают на иной вопрос, чем вопрос о том, кто мог назначать, проверять или заменять региональную организацию.

Изученная здесь документация не содержит полного авторского чернового архива, переписки FEPG или IEPG, стенограммы сессии IETF Addressing BOF, сравнения кандидатов-реестров, знаменателя региональных одобрений, журнала возражений или дела об апелляции на назначение. Этот пробел не следует превращать в скрытую оппозицию. Он в равной степени не позволяет молчанию становиться измеренным консенсусом.

Более полная история авторизации потребовала бы свидетельств, связывающих названные институты с кругами, от имени которых они якобы действовали: заявки кандидатов, записи оценок, переписка с провайдерами и абонентами, задокументированные возражения, исключения центрального обслуживания, обсуждения замены и решения, объясняющие, как оценивалось признание. Без таких материалов ранняя документация устанавливает технически обоснованное и операционно внедрённое устройство, оставляя его всеобъемлющий мандат неполным.

Осуществимая в тот период альтернатива не была современным общим реестром

Полезная контрфактическая версия начинается с принятия необходимости распределения. К 1992 году чисто центральную службу приёма было всё труднее согласовать с международным ростом, языками, местными процедурами и административным масштабом. Более острый вопрос в том, требовало ли распределённое обслуживание единственного поставщика на региональном уровне.

Одна осуществимая в тот период альтернатива следовала реальной архитектуре баз данных RFC 1174. Несколько аккредитованных служб приёма или назначения могли обслуживать заявителей в широком регионе, пока центральный Internet Registry сериализовал авторитетные обновления. Делегированные службы могли получать отдельные пулы адресов, применять общие критерии и передавать изменения в одну центральную очередь обновлений. Реплицированные копии затем могли распространяться для доступа и избыточности.

Это не была настоящая репликация с несколькими писателями. Центральный Internet Registry оставался бы органом, упорядочивающим изменения и предотвращающим дублирующие назначения. Такая конструкция могла предлагать несколько интерфейсов обслуживания, не требуя от нескольких институтов одновременного редактирования одного авторитетного состояния. Её узким местом был бы центральный путь обновлений: задержка, восстановление после сбоев и сверка после отложенных отправок всё равно требовали бы явных процедур.

Предотвращение коллизий зависело бы либо от строгого разбиения пулов, либо от центрального подтверждения перед назначением. При разбитых блоках каждая служба могла действовать в своём диапазоне, не сталкиваясь с равной, но неиспользуемая ёмкость могла застревать, а перебалансировка требовала бы координированных передач. При центральном подтверждении пулы могли быть гибче, но заявители и реестры испытывали бы задержку обновления и уязвимость к центральным перебоям.

Агрегация вводила ещё один компромисс. Выделение каждой службе отдельного смежного пула могло сохранять широкие агрегаты. Разрешение заявителю менять провайдера с сохранением адресов могло пробивать дыры в этих агрегатах или требовать более специфичной маршрутизации. Требование перенумерации при смене защищало бы агрегацию ценой переходной работы для заявителя. Поэтому альтернативе требовалось правило непрерывности адресов, а не просто дополнительная стойка приёма.

Обслуживание на местных языках могло улучшиться благодаря специализированным поставщикам, особенно в регионе, слишком разнообразном для равного обслуживания одним центром. Оно также могло стать неравномерным: прибыльные или хорошо связанные сообщества могли привлекать несколько реестров, тогда как другие получали мало покрытия. Аккредитации пришлось бы оценивать географический и языковой охват, а не предполагать, что конкуренция распределится справедливо сама.

Общие критерии создали бы собственную проблему управления. Несколько поставщиков могли по-разному толковать прогнозируемую потребность или обоснование класса B, побуждая заявителей выбирать самую мягкую службу. Предотвращение такого выбора удобного форума потребовало бы аудитов, общих руководств, пересмотра расходящихся результатов и полномочий исправлять или отстранять поставщиков. Множественность снижает зависимость от одного реестра только при надёжности аккредитующего и аудиторского уровня.

Центральному резерву также потребовалось бы определение. Если бы корень принимал заявки всякий раз, когда региональный поставщик медлителен или ограничителен, он мог бы стать конкурирующей службой и подорвать региональное планирование. Если бы он автоматически возвращал заявителей, он давал бы мало практической избыточности. Рабочая альтернатива должна была определить, когда центр вмешивается, может ли он отменить региональное решение и является ли прямое обслуживание операционным исключением или подлинным путём пересмотра.

Восстановление после сбоя столь же конкретно. Региональная служба могла потерять персонал, финансирование, связность или целостность базы данных. В модели нескольких служб другой аккредитованный поставщик мог перенять приём, но авторитетные записи, незавершённые заявки и неиспользуемые пулы пришлось бы передавать безопасно. В модели одного реестра непрерывность могли обеспечить центр или локальные реестры, однако RFC 1366 не описывал проверенный процесс передачи. Ни одна конструкция не делала институциональный сбой бесплатным.

Замену и апелляцию следует разделять. Заявитель мог оспорить отдельное решение о распределении, не требуя отстранения реестра. Провайдер или региональный круг мог оспорить работу или признание реестра, не оспаривая конкретный запрос. Первая проблема требует пересмотра критериев и доказательств; вторая — правил аккредитации, аудита и замены. Положение RFC 1366 о прямом центральном контакте лишь частично решало первую и не определяло вторую.

Вторая, более амбициозная альтернатива допустила бы настоящую репликацию с несколькими писателями: несколько реестров обновляли авторитетное состояние с последующей сверкой. Изученные документы периода не устанавливают, что это была предполагаемая архитектура. Она потребовала бы бесконфликтных разделов распределения или строгого упорядочивания транзакций, аутентифицированного обмена обновлениями, обнаружения расходящихся записей, восстановления после разделов сети и правила, определяющего, какой писатель побеждает.

Считать современный по звучанию общий реестр лёгким вариантом 1992 года значило бы стереть техническую причину, по которой RFC 1174 сохранил центральные обновления.

Региональная конструкция с одним реестром снижала несколько координационных издержек. Одна организация могла управлять согласованным блоком, поддерживать единые отношения с IANA и Internet Registry, применять одну региональную процедуру и координировать нижестоящую иерархию реестров. Её локальные реестры всё же могли предоставлять обслуживание на уровне поставщиков, стран и языков. Это делало единственность на региональном уровне совместимой с распределением ниже него.

Ценой была концентрированная зависимость. Если региональная организация становилась медленной, непоследовательной, недофинансированной или недостаточно представительной, у заявителей не было заявленной равной альтернативы. Центральное обслуживание предлагало потенциальную избыточность, но направление могло возвращать заявителя на тот же региональный уровень. Поэтому конструкция нуждалась в постоянном пересмотре и заменяемости не меньше, чем во входных критериях.

RFC 1366 артикулировал координационное преимущество полнее, чем механизм подотчётности. Он называл стабильность, своевременность, надёжность и признание желательными качествами, но не определял, как они будут отслеживаться, чьи свидетельства будут учитываться, когда истечёт назначение и как новый реестр сможет заменить действующий.

Контрфактическая версия не доказывает, что несколько поставщиков дали бы лучшие результаты. Несколько аккредитованных служб несли бы реальные издержки в упорядочивании обновлений, управлении пулами, агрегации, перенумерации, аудите и переходе. Сравнение выявляет более узкое: региональное обслуживание, центральная уникальность и концентрация одного поставщика были тремя разделимыми решениями. Операционная потребность в первых двух сама по себе не устанавливала постоянную необходимость третьего.

Момент, когда региональное распределение стало мыслимым

RFC 1366 сделал региональное распределение конкретным, связав проблемы, которые больше нельзя было рассматривать по отдельности. Международный рост напрягал единый интерфейс обслуживания. Языковая и административная близость способствовали распределению. Дефицит класса B делал старые привычки размеров неустойчивыми. Множественные назначения класса C угрожали ростом маршрутизации, если блоки не были смежными и совместимыми с агрегацией.

RFC 1174 дал базовую архитектуру: сохранить IANA и центральный Internet Registry, делегировать функции назначения через одобренные организации, распространять копии баз данных при централизации обновлений и отделить регистрацию от применения сетевой политики. RFC 1366 добавил региональные квалификации, географический план класса C, пороги размеров и явное предпочтение одного реестра на региональном уровне. RFC 1367 поставил предлагаемые даты рядом с планом, не доказывая, что каждая веха произошла.

Европа даёт самое сильное свидетельство практики. С апреля 1992 по октябрь 1993 года публичная документация фиксирует работающий координационный центр, делегированные реестровые процедуры, центральную пересылку заявок, реестры поставщиков услуг и страновые реестры, делегирование блоков класса C, формы заявителей, оценку запросов, координацию баз данных, делегирование обратного DNS и значительные отчётные объёмы назначений. Действия происходили в разные даты и на разных административных уровнях. Их статистику нельзя сворачивать в единый журнал запросов, заявителей или авторизации.

Положение об одном реестре принадлежит этому операционному достижению, а не находится вне него. Оно предлагало способ координировать блоки и процедуры, допуская множество локальных точек обслуживания. Оно также концентрировало зависимость на региональном уровне. RFC 1366 сохранял центральный корень и резерв, но оставлял практические условия центрального пересмотра неопределёнными.

Итоговая документация заканчивается на ясной границе. Операционная проблема была решена. Институциональная концентрация была добавлена. Датированное внедрение можно наблюдать. Не хватает полного отчёта об авторизации среди затронутого населения, воспроизводимой меры признания и установленного процесса апелляции, замены и непрерывности, если назначенный региональный реестр перестанет соответствовать качествам, от которых зависел его выбор.