Контракт InterNIC и цена единой административной точки отказа

Кратко

• В апреле 1993 года NSF запустила InterNIC: Network Solutions занималась центральной невоенной регистрацией доменов, номеров сетей и ASN, включая приём заявок, обработку и обновления; AT&T — доступом к каталогам и базам данных; General Atomics/CERFnet — информацией и направлением к нужным службам. В воспроизведениях предварительного соглашения также зафиксированы требования в 3, 5 и 22 рабочих дня для выдачи блоков класса C, B и A после получения полной заявки, однако сохранившиеся материалы не позволяют измерить, как эти сроки соблюдались.
• Документированный процесс подачи заявок Network Solutions использовал стандартные шаблоны, автоматический разбор, сообщения об ошибках, проверку заявителем, семидневное окно подтверждения, финальную обработку человеком и видимый статус заявки — это давало реальный выигрыш в масштабировании, единообразии и прозрачности исправлений.
• Сохранившиеся копии соглашения — непроверенные воспроизведения, в отчётах о работе нет решающих знаменателей по числу заявок, а документированные каналы исправлений, разбора споров между менеджерами, процедуры для сторон контракта и апелляций в реестрах не дают восстановленных рядов данных об использовании, сроках, отменах или результатах.
• Материалы подтверждают концентрацию приёма и обработки заявок в едином центре для определённых невоенных регистрационных работ, но не доказывают всеобщую неизбежность этого пути, систематическое исключение кого-либо, измеримый ущерб заявителям или то, что региональные, военные, местные реестровые и провайдерские каналы были недоступны конкретной затронутой группе.

1 апреля 1993 года: заявка попадает в новый канал

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

Наиболее подробное современное описание —RFC 1400, опубликованный в марте 1993 года. Его автор, Скотт Уильямсон, работал в Network Solutions, новом подрядчике по регистрации. Поэтому документ представляет собой описание от первого лица предполагаемого перехода и процесса подачи заявок, а не независимую проверку работы. Тем не менее он необычайно точен в деталях административной последовательности.

В переходный период до 31 марта пользователи, не относящиеся к DDN, могли отправлять существующие шаблоны Сетевого информационного центра DDN либо на старый адрес DDN NIC, либо на новый адрес хостмастера InterNIC. Письма, факсы и почтовые отправления, полученные на любой из площадок, должны были обрабатываться. Пользователи DDN оставались на отдельном военном канале: им предписывалось по-прежнему направлять регистрационные заявки в DDN NIC. Переход разделил группы пользователей; он не закрыл прежний институт одним ударом.

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

Новая форма была рассчитана на автоматическую обработку и очищена от DDN-специфичных ссылок. После отправки почтовый сервер разбирал шаблон и быстро проверял информацию, которую можно было проверить. В RFC 1400 в качестве примера приводился конфликт доменных имён. Затем система возвращала либо форму подтверждения, либо отказ с сообщениями об ошибках.

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

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

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

Эта последовательность давала и очевидные преимущества. Подтверждающее сообщение включало номер тикета (trouble ticket). Пользователь мог узнать статус заявки через утилитуfingerили интерактивно подключившись к регистрационному хосту. В примере показывалось, ожидает ли заявка обработки, как она поступила, когда была открыта и какой внутренний аккаунт её вёл. Для растущей службы это заменяло часть неопределённости непрозрачного почтового ящика видимым административным состоянием.

Ручная поддержка оставалась доступной по телефону, электронной почте, факсу и обычной почте. Служба WHOIS работала и на DDN NIC, и на площадках InterNIC в переходный период. С 1 апреля сервер DDN должен был содержать информацию DDN, а сервер InterNIC — записи об IP-адресах, доменах, ASN и связанных контактных лицах. Распространение корневой зоны, регистрация доменов, выдача номеров, контактные записи и доступ через WHOIS делили части одной операционной среды, но это не одна и та же функция.

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

Карта запуска — и дата, когда она перестала быть полной

InterNIC была представлена пользователям как скоординированная служба, но NSF закупила её у отдельных организаций.Объявление о начале работы сервисов InterNIC от 1 апреля 1993 годаописывало структуру запуска, разделённую между регистрационными службами, службами каталогов и баз данных и информационными службами. Единый публичный образ должен был скрыть ненужные швы, не стирая лежащее в основе распределение ответственности.

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

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

General Atomics, действовавшая через CERFnet, получила информационный компонент и компонент направления заявок. Её функция заключалась в консультировании: отвечать на вопросы об использовании интернета и подключении к нему, поддерживать информационные ресурсы и направлять пользователей в подходящие службы или организации поддержки. Справочная служба могла помочь заявителю найти путь регистрации; она не могла заменить организацию, уполномоченную обрабатывать выдачу.

Другие институты оставались вне этой тройки подрядчиков. NSF владела контрактами, выделяла финансирование, контролировала работу, утверждала отдельные действия, оценивала прогресс и координировала споры между менеджерами. Институт информационных наук Университета Южной Калифорнии (USC/ISI) продолжал координационную функцию IANA — ответственность над реестрами или наряду с ними и полномочия делегировать часть администрирования номеров. DDN NIC сохранила свой канал для военных пользователей. Региональные и местные механизмы уже начинали менять то, какой реестр обслуживает конкретную группу.

Структуру запуска можно кратко представить так:

Это карта на апрель 1993 года, а не устойчивое описание всего периода до 1998 года. Вархивном воспроизведении Поправки 4 от 13 сентября 1995 годаговорится, что ссылка на General Atomics удалялась в связи с недавним прекращением её соглашения. В воспроизведении также видна несогласованность номеров контрактов: General Atomics приписывается NCR-9218179, тогда как в воспроизведённом основном тексте NCR-9218179 отнесён к AT&T, а NCR-9218749 — к General Atomics. Доступные материалы не дают оснований молча исправить это противоречие или вывести из него полную правовую историю прекращённого контракта. Зато они подтверждают, что первоначальное описание с тремя менеджерами перестало быть полным к сентябрю 1995 года.

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

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

Прежде чем читать контракт, предупреждение о контракте

Доступные материалы соглашения полезны, но не подтверждены как полная исполненная федеральная запись.

Частная расшифровка Cavebear— это частная расшифровка.Скан Freespeech на 31 страницу, размещённый на зеркале, — это скан с зеркального хостинга без подтверждённой цепочки хранения.Архивное воспроизведение ICANN— архивное воспроизведение, а не каноническая копия NSF. Ни одна из них не является канонической копией NSF. Эти источники позволяют сравнивать и находить пункты; они не доказывают, что доступный набор содержит полный исполненный договор, все включённые материалы предложения, все приложения, полную историю подписей, проверенный набор страниц или полную цепочку поправок.

Эти ограничения видны прямо в сохранившемся наборе. Воспроизведённое соглашение ссылается на предложение Network Solutions сентября 1992 года, совместное дополнение октября 1992 года и формулы качества из предложения. Эти материалы не полностью доступны в базовом воспроизведении. Общие условия присутствуют в скане на зеркале, тогда как страница ICANN воспроизводит в основном особые условия и более поздние поправки. Поправка 4 включает по ссылке ещё одно предложение и приложения. Читатель архива может реконструировать важные условия, но не может подтвердить подлинность всего действующего пакета.

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

Самое очевидное предупреждение — расхождение в сметной сумме на 1 000 000 долларов США. Титульное воспроизведение указывает оценочный итог в4 219 339 долларов США. Воспроизведение статьи 8 указывает5 219 339 долларов США. Скан на зеркале, судя по всему, разбивает цифру статьи 8 на оценочную стоимость в4 854 061 доллар СШАплюс фиксированный гонорар в365 278 долларов США, что арифметически даёт 5 219 339 долларов США.

Расхождение между титульной суммой и суммой статьи 8 составляет ровно1 000 000 долларов США. Внутренняя арифметика не может установить, какая заглавная сумма отражала полный исполненный контракт. Она лишь показывает, что компоненты статьи 8 в сумме дают итог статьи 8. Вописании федерального окружного суда 1998 годанезависимо повторены компонент возмещения в 4 854 061 доллар США и фиксированный гонорар в 365 278 долларов США. Это подтверждает арифметику компонентов; это не подтверждает подлинность полной копии соглашения, его приложений или истории поправок.

Из цифр статьи 8 можно пересчитать несколько полезных соотношений, если обозначить их как расчёты, а не как договорные ставки. Фиксированный гонорар в 365 278 долларов США составляет примерно7,5252 %от воспроизведённой оценочной стоимости в 4 854 061 доллар США и примерно6,9985 %от воспроизведённого итога статьи 8 в 5 219 339 долларов США. Предварительное первоначальное финансирование составляло1 162 245 долларов СШАдо 31 марта 1994 года, то есть примерно22,2680 %от итога статьи 8.

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

Что предварительный контракт пытался контролировать

С учётом этих ограничений архивное воспроизведение описывает ограниченный по времени контрактный инструмент, действовавший с 1 января 1993 года по 30 сентября 1998 года. Он делит период на трёхмесячное поэтапное внедрение, пять лет операционной поддержки с 1 апреля 1993 года и шестимесячный период гибкости без дополнительных затрат.

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

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

Механизм финансирования давал NSF постоянный рычаг. Первоначальное финансирование покрывало работу до 31 марта 1994 года, а дальнейшие средства предполагались поэтапно. Воспроизведённый текст требовал уведомления, если ожидаемые затраты в следующие 60 дней в сумме с уже понесёнными расходами превысят 85 % выделенной суммы. Дальнейшая поддержка была связана с ежегодным пересмотром, предлагаемым планом программы, переговорами и наличием средств.

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

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

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

Контракт также отделял координацию от пересмотра по жалобам заявителей. Воспроизведённый язык о взаимодействии позволял программному сотруднику NSF разрешать технические, управленческие или плановые споры между менеджерами InterNIC. Это могло касаться разногласий между Network Solutions и AT&T о передаче данных или другого управленческого конфликта внутри проекта. Это не было сформулировано как слушание для заявителя, оспаривающего решение о номере.

Модель «принципал–агент» была, таким образом, более содержательной, чем пассивная субсидия. NSF сохранила деньги, отчётность, утверждение, оценку и координацию. Network Solutions по-прежнему контролировала повседневные системы и персонал, через которые продвигались центральные заявки. Важен не вопрос о том, существовал ли формальный надзор; он существовал. Важно, показывают ли сохранившиеся материалы, насколько быстро, последовательно и эффективно эти рычаги защищали заявителей на номера. Здесь публичная запись скудна.

Трёхдневный отсчёт, который начинается после завершения заявки

В воспроизведениях предварительного соглашения есть отдельные требования к срокам обработки для классовых выдач номеров сетей:3 рабочих дня для класса C,5 рабочих дней для класса Bи22 рабочих дня для класса A. Это воспроизведённые требования, а не подтверждённые результаты соблюдения или наблюдения за реальной работой.

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

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

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

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

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

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

Май 1994 года: масштаб в единицах, которые нельзя смешивать

Самое весомое современное свидетельство нагрузки — раздел, представленный подрядчиком, вInternet Monthly Report за май 1994 года. В нём зафиксировано несколько разных видов деятельности:

• 5 009 писем хостмастеру
• 251 заявка по почте или факсу
• 2 047 телефонных звонков
• 1 316 зарегистрированных доменов
• 565 записей обратного адреса
• 12 645 единиц номеров сетей класса C
• 20 единиц номеров сетей класса B
• 57 выданных ASN

Ни одну из этих единиц нельзя сложить в осмысленный итог под названием «заявки». Письмо может быть заявкой, исправлением, запросом статуса или вопросом о политике. Телефонный звонок может касаться любой из нескольких функций. Запись обратного адреса — не новое выделение. Регистрация домена — не выдача ASN.

Самое важное: 12 645 единиц класса C не означают 12 645 заявителей. В отчёте отдельно сказано, что блоки из 256 сетей класса C выделялись нескольким организациям и DDN NIC. Одна заявка или одно действие по выделению могло объяснять множество отражённых единиц. Цифра показывает масштаб адресных единиц, зафиксированных за месяц, а не число уникальных заявителей или разбирательств.

Тот же отчёт перечисляет использование информационных служб за май, не разрешая вопрос о знаменателе регистрации. В нём указано211 257 клиентских запросов WHOISи785 015 серверных запросов WHOIS. Отдельно сообщается о48 859 подключениях Gopher,24 748 подключениях WAIS,8 779 подключениях FTPи1 387 подключениях Mailserv. Запросы, подключения, заявки, выдачи и телефонные контакты остаются разными вещами.

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

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

Что добавляет отчёт подрядчика 1996 года

Частная расшифровкаГодового отчёта о ходе работ службы регистрации InterNIC за 1996 годсодержит более поздние заявления о работе. Её происхождение слабее, чем у подтверждённого отчёта подрядчика, и статистика остаётся самоотчётной. Тем не менее она информативнее, чем просто заменить период гипотетическими вопросами.

В расшифровке сказано, что по состоянию на31 декабря 1996 года 95 % новых регистрационных заявок обрабатывались в течение 24 часов. В ней нет числителя, состава типов заявок и правила измерения. «Новые регистрационные заявки» не разбиты на домены, работу по IP-номерам, ASN, контакты или другие шаблоны. Это заявление нельзя приводить как 95-процентную долю завершённых заявок на IP-номера.

Отдельный отрывок касается именно доменов. В нём сказано, чтов ноябре 1996 года было зарегистрировано более 85 000 доменови чтоболее 90 % этих заявок были автоматически обработаны парсером в течение 24 часов. Это заявление только о доменах нельзя смешивать с утверждением о 95 % на конец года. Это свидетельство значительной автоматизации доменов за один месяц, а не показатель сроков или справедливости распределения адресов.

Та же расшифровка фиксирует менее лестные данные об общей поддержке. В течение1996 года, по самоотчёту, доля брошенных звонков колебалась отменее 8 % до более 50 %. Во второй половине года показатели обычно составляли10–20 %. Среднее ожидание клиента составляло околочетырёх минут, а среднее время ответа на запросы по голосовой почте не измерялось. В отчёте также сказано, что проблемы с телефонными линиями, выявленные в декабре, приводили к тому, что многие звонившие слышали сигнал «занято».

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

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

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

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

Где на самом деле находилась концентрация

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

На этапе приёма Network Solutions контролировала публичный электронный адрес, принимаемый шаблон и парсер. Некорректная или устаревшая форма не могла продвинуться по автоматическому пути, пока её не исправят. Ручные каналы оставались, но центральную невоенную службу в конечном счёте вёл тот же регистрационный подрядчик.

На этапе подтверждения заявитель должен был удостовериться, что машина правильно интерпретировала поданные данные. Это была защита от тихой ошибки. Это также возлагало завершение цикла на заявителя в течение семи дней. Частота истечений неизвестна, поэтому правило демонстрирует зависимость и возможное последствие в виде повторной подачи, а не измеренное бремя для какой-либо группы.

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

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

После выдачи наступали регистрация и публикация. Предварительное воспроизведение определяет доступность как передачу регистрационных данных подрядчику каталогов и баз данных. Network Solutions инициировала передачу; AT&T занимала уровень публикации и доступа на момент запуска. Выдача и её публичная запись были связаны, но институционально разделены.

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

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

Таким образом, доказанный вывод —концентрация приёма и обработки в едином центре. Network Solutions занимала последовательные стадии центрального невоенного пути: приём, разбор, исправление, полноту, обработку сотрудниками, выдачу и обновление регистрации. Материалы не указывают точную группу заявителей, для которой служба DDN, RIPE NCC, APNIC, местный реестр, адресное пространство провайдера или эскалация в вышестоящий реестр были бы доказанно недоступны. Они также не дают документированного операционного ущерба от отсутствия выбора.

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

География и категория заявителя меняли путь

Центральная служба никогда не имела единообразного отношения ко всем интернет-заявителям в 1993–1998 годах.

Европа уже давала самый ясный контрпример.Собственная история RIPE NCCразличает формальное учреждение вапреле 1992 годаи распределение адресов, которое не было первоначальной деятельностью, но было добавлено позже, в1992 году. К моменту перехода к InterNIC администрирование европейских номеров уже начало идти через региональную структуру.

RFC 1466, опубликованный в мае 1993 года, описывал интернет-реестр как реестр по умолчанию там, где не существовало делегированной регистрационной власти. Он обосновывал распределение регистрации тем, что географически более близкие реестры могут лучше обслуживать местные сообщества, языки и обычаи. В нём отмечалось, что RIPE NCC уже получила блок пространства класса C для распределения в Европе.

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

Азиатско-Тихоокеанский путь возник по другому графику.Институциональная история APNICговорит, что пилотный проект должен был начаться всентябре 1993 годаи продолжался до июня 1994 года. IANA публично признала APNIC вапреле 1994 года, делегировав диапазоны IPv4202/8 и 203/8. Доступный путь для заявителя из Азиатско-Тихоокеанского региона зависел от даты, географии, зрелости пилота и действующего делегирования.

К моменту публикацииRFC 2050 в ноябре 1996 годакарта администрирования номеров была явно иерархической: IANA, региональные реестры и местные реестры. InterNIC отождествлялась с Северной Америкой, RIPE NCC — с Европой, APNIC — с Азиатско-Тихоокеанским регионом. Местные реестры работали под региональным уровнем.

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

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

Канал DDN оставался отдельным для своей целевой группы во время перехода 1993 года. Военному пользователю предписывалось продолжать работу с DDN NIC. Этот канал — аргумент против единой службы, охватывающей всех заявителей, но он не был общей альтернативой, открытой для каждой невоенной организации.

К 1996 году самое точное описание не в том, что Network Solutions была единственным глобальным «шлюзом» для номеров. InterNIC была одним региональным реестром в иерархии, в которую также входили RIPE NCC, APNIC, местные реестры и выделения через провайдеров. Ранее центральный реестр оставался реестром по умолчанию для зон без делегирования и сохранял важные координационные функции.

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

Четыре механизма исправления, которые нельзя путать

В материалах есть четыре разных вида исправления или пересмотра. Считать их одним механизмом значило бы преувеличивать защиту заявителей.

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

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

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

Четвёртый канал — обращённая к заявителю иерархия реестров, описанная в RFC 2050. Организация, недовольная работой реестра, выдавшего адреса, могла подать апелляцию в вышестоящий реестр. Выдавший реестр должен был предоставлять соответствующие документы. Дальнейшая апелляция могла идти в реестр ещё более высокого уровня и, после исчерпания других путей, в конечном счёте в IANA. Каждый реестр должен был документировать свою процедуру апелляции.

RFC 2050 улучшил опубликованную архитектуру пересмотра. Он отделял выдавший реестр от проверяющего более высокого уровня и касался именно решений по адресам. Это был документ Best Current Practice, написанный представителями, связанными с InterNIC, APNIC, RIPE NCC и IANA, а не аудит того, как апелляции работали на практике.

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

Карта средств защиты, таким образом, менялась со временем и по субъектам. В 1993 году заявители могли исправлять формы и обращаться к сотрудникам, а NSF управляла своими подрядчиками. Предварительные общие условия давали подрядчику договорной канал пересмотра. К ноябрю 1996 года опубликованная система номерных реестров формулировала обращённый к заявителю путь через вышестоящие реестры к IANA. Каждый из них касался другого спора.

Данные о работе и преемственность в конце цепочки

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

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

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

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

Правовое заключение GAO 2016 годадаёт ограниченные ретроспективные данные о более позднем переходе. В нём сказано, что при переводе администрирования к Министерству торговли в 1998 году добавленное положение требовало от Network Solutions передать копии программного обеспечения, данных и документации, созданных по соглашению, вплоть до октября. GAO сообщило о передаче файлов баз данных надесяти 8-миллиметровых кассетах, подшивке с перечнем баз данных и нескольких дополнительных подшивках с данными и документацией по программному обеспечению.

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

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

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

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

Контрфактический сценарий: один менеджер для всех трёх служб

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

Интеграция могла снизить затраты на координацию. Регистрационные данные могли бы перемещаться от приёма к публикации внутри одной организации. Единая операционная команда могла бы проследить сбой через разбор, обработку сотрудниками, доступность базы данных, публичные запросы и общую поддержку. Пользователям не пришлось бы определять, за кем проблема на стыке — за Network Solutions или AT&T.

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

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

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

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

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

Контрфактический сценарий: несколько взаимозаменяемых регистрационных провайдеров

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

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

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

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

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

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

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

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

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

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

Взвешенный вывод

Проект InterNIC 1993 года от NSF сочетал специализацию с общим публичным образом. Network Solutions вела центральную невоенную регистрацию; AT&T — доступ к каталогам и базам данных; General Atomics/CERFnet — информацию и направление. NSF сохранила финансирование, контроль, утверждения, оценку и координацию между менеджерами. USC/ISI продолжала координацию IANA, а DDN NIC сохранила военный канал.

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

Внутри разделённого института Network Solutions контролировала последовательные стадии центрального регистрационного пути. Эта концентрация делала заявку зависимой от принятого канала, парсера, цикла исправлений, определения полноты, обработки сотрудниками и обновления регистрации одного подрядчика. Это корректно описывается как концентрация приёма и обработки в едином центре.

Окружающая система менялась. RIPE NCC распределяла адреса в Европе, APNIC возникла в Азиатско-Тихоокеанском регионе, местные реестры и провайдеры обслуживали дополнительные группы, пользователи DDN сохранили ещё один канал, а RFC 2050 поместил InterNIC в региональную иерархию с путём апелляции в вышестоящий реестр. Эти альтернативы были привязаны ко времени, географии и категории заявителя, а не были взаимозаменяемым выбором.

Данные о надзоре и средствах защиты неполны, но не отсутствуют. У NSF были договорные инструменты; у заявителей — исправление и контакт с сотрудниками; предварительные общие условия описывали пересмотр между подрядчиком и NSF; а RFC 2050 позже сформулировал апелляцию заявителя через вышестоящие реестры к IANA. Чего не хватает — так это рядов результатов, нужных для оценки этих механизмов в делах о номерах.

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