Отсутствующая апелляционная служба раннего интернета

Резюме

• Опубликованные инструкции 1983–1992 годов описывали формы, технические требования, ответственных администраторов, пути исправления и каналы связи. В рассмотренной здесь документальной выборке они не предусматривали общей независимой апелляционной службы для неуспешных заявок на домены или числовые идентификаторы.
• Списки зарегистрированных пользователей, доменов и присвоенных сетевых номеров сохраняют завершённые или действующие записи. Они не раскрывают общую совокупность поданных, неполных, задержанных, отозванных, отклонённых, исправленных, пересмотренных, переданных наверх, отменённых или иным образом закрытых заявок.
• Переписка с NIC, телефонная помощь, администрирование родительского домена, государственное спонсорство, полномочия IANA и федеральный надзор могли помочь в решении отдельных проблем. В выборке нет ни одного дела на уровне заявки, которое доказывало бы, что какой-либо из этих каналов работал как апелляция заявителя с мотивированным и зафиксированным результатом.
• Карта полномочий поэтому неравномерна: сотрудники NIC могли обрабатывать и исправлять записи; администраторы хостов и доменов — разрешать или пересматривать локальные подачи; спонсоры — влиять на подключение; IAB — рекомендовать политику; а IANA обладала полномочиями по присвоению числовых идентификаторов и делегировала их. Индивидуальная апелляционная юрисдикция и обязанности по отмене решений остаются неустановленными.
• Малое число зафиксированных конфликтов совместимо и с благоприятной, и со скептической трактовкой. Возможно, проблемы обычно решались точно благодаря доверительным отношениям; возможно, неуспешные заявители просто исчезали из записей, оптимизированных для сохранения присвоений, а не процедурных историй. Имеющийся знаменатель не позволяет различить эти два варианта.

Знаменатель, скрытый за каждым успешным списком

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

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

Обычный путь реконструировать гораздо проще.

В качестве непосредственного исходного ориентира предшествующего периодаRFC 810от 1 марта 1982 года требовал, чтобы имена и адреса сетей, шлюзов и хостов Department of Defense согласовывались и регистрировались в Network Information Center до начала использования и до того, как хост DoD начнёт пропускать трафик. В документе были указаны электронные и телефонные каналы связи. На переходный период NIC должен был также пытаться поддерживать сопоставимую информацию, предоставленную сетями и хостами вне DoD. Инструкция устанавливала, где происходит регистрация. Она не описывала журнал заявок и не предусматривала путь обжалования неблагоприятного вывода.

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

RFC 1032, «Domain Administrators Guide» от ноября 1987 года, делал рабочий порядок более явным. Администратор получал анкету, заполнял её и отправлял в NIC, в службу Hostmaster. Сотрудники Hostmaster проверяли информацию на полноту. Руководство предполагало несколько обменов электронными письмами до авторизации. Исправления можно было подать позднее, а вопросы задать по электронной почте или через бесплатную горячую линию.

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

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

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

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

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

Машина состояний, а не бинарная пара «одобрено — отклонено»

Минимальная аналитическая последовательность выглядит так:

подано -> неполная информация -> запрос дополнительной информации -> задержано -> отклонено -> исправлено -> пересмотрено -> передано наверх -> отменено или окончательное решение

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

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

Неполная информацияописывает состояние обработки. Могли отсутствовать обязательные поля, ответственные контакты, схема серверов или авторизация. RFC 1032 требовал заполненной анкеты до того, как NIC авторизует домен. Это правило фиксирует категорию, но в выборке нет связанного файла заявки, который показывал бы поименованную заявку, отнесённую к неполным.

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

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

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

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

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

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

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

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

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

Доказательственный статус по этой выборке, следовательно, асимметричен:

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

Документальная выборка и что она исключает

Интересующий период — 1983–1992 годы. RFC 810 используется только как исходный ориентир марта 1982 года для унаследованного правила регистрации хостов. RFC 1400, опубликованный в 1993 году, появляется лишь как краткое сравнение, показывающее, как явная видимость состояния заявки позже вошла в публичную процедуру.

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

• RFC 920, RFC 1032, RFC 1062, RFC 1174 и RFC 1359;
• документ NIC «Instructions for Network User Registration Drive» от 20 октября 1983 года, сохранившийся на страницах 67–73 оцифрованного комплектаDefense Communication Agency Materials; 6 of 13из Computer History Museum;
• «How to Reach the NIC»,NIC KNACKS, выпуск № 2 от 17 мая 1985 года, сохранившийся на странице 94 оцифрованного комплектаDefense Communications Agency Materials; 3 of 13;
• справочник Computer History Museum 2011 годаGuide to the SRI ARC/NIC Records, коллекция X3578.2006;
• интервью Джеймса Пелки с Джоном Постелом, записанное 18 февраля 1988 года;
• и более поздний правовой анализ US Government Accountability Office федеральных контрактов, связанных с DNS и функциями IANA.

Документы включались, когда они описывали требование к заявке, административный канал, процесс исправления, полномочия по выделению, различие спонсорства, рекомендацию по политике или отношение надзора, значимые для 1983–1992 годов. RFC 1062 включён как артефакт опубликованного результата, а не как руководство по подаче заявок. Архивный путеводитель используется для очерчивания архивного ландшафта, а не как замена записям внутри коллекции. Интервью с Постелом даёт ограниченный контекст о культуре документирования, а не доказательства по делам об идентификаторах.

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

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

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

Путеводитель по коллекции SRI ARC/NICописывает 351 линейный фут материалов в 281 коробке, при этом основная часть датируется 1968–1990 годами. К релевантным сериям относятся предложения и контракты NIC, официальные ежемесячные отчёты, результаты по контрактам, справочная служба и горячая линия, именование и адресация, регистрация пользовательского доступа TAC, администрирование сетевых контактов, а также разрозненные электронные письма и переписка.

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

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

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

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

Три административные совокупности, которые нельзя смешивать

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

Первая совокупность —регистрация сетевых пользователей и доступ TAC. Документ NIC «Instructions for Network User Registration Drive» от 20 октября 1983 года касался людей, использующих хосты MILNET и ARPANET, а для части из них — доступа через терминальные контроллеры доступа MILNET. Администраторы хостов получали шаблоны для пользователей своих хостов, исправляли существующие данные, добавляли подходящих пользователей, отмечали удаления, проверяли результаты и возвращали материал в NIC. Запросы доступа TAC требовали авторизации через почтовый ящик администратора хоста.

Это была система авторизации на стороне спонсора и хоста. DDN Program Management Office заявляло, что локальные хосты должны ответственно управлять собой в рамках государственных инструкций и что оно будет работать с администраторами хостов при возникновении проблем. Эта формулировка устанавливает канал решения проблем между DDN-PMO и администраторами. Она не устанавливает право отдельного человека, которому его администратор хоста отказал в авторизации.

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

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

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

Третья совокупность —присвоение числовых идентификаторов. RFC 1062 публиковал присвоенные сетевые номера.RFC 1174от августа 1990 года описывал IANA как организацию с первичными полномочиями по распределению и присвоению числовых идентификаторов; эту функцию выполнял Information Sciences Institute при USC. Internet Registry в SRI описывался как собирающий и регистрирующий информацию о сетях и выполняющий делегированную работу по присвоению.

Присвоение номеров нужно также отделять отподключения. RFC 1062 гласил, что независимые сети, использующие интернет-протоколы, могут получать номера, оставаясь вне подключённого интернета, и что для разрешения на взаимное подключение они должны подавать отдельную заявку. RFC 1174 позднее описывал статус «подключено» как санкцию спонсирующей организации правительства США на подключение к финансируемой федеральным правительством системе.

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

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

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

Прямая запись об исключении: исправление и продолжение обработки

Самое сильное доказательство исключения в выборке касается исправления.

Документ «Instructions for Network User Registration Drive» от 20 октября 1983 года описывал конкретную последовательность. NIC готовил шаблоны для людей, уже находящихся в его базе идентификационных данных. Администраторы хостов забирали эти шаблоны, заменяли неверные данные, добавляли отсутствующих пользователей, отмечали удаления, проверяли и авторизовывали итоговые списки и возвращали их регистратору. NIC редактировал поданные материалы и вносил их в базу идентификационных данных WHOIS.

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

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

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

Задокументированная последовательность, следовательно, такова:

существующие данные -> проверка администратором -> исправление или добавление -> авторизация -> структурированная повторная подача -> обработка в NIC

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

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

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

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

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

Они не дают ни отклонённого заявителя, ни апелляции, ни отмены решения.

Карта отмены решений

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

На этой карте много способов спросить и меньше способов обязать. Сотрудники NIC могли исправить запись, которую вели. Администратор хоста мог авторизовать пользователя. Администратор родительского домена мог пересмотреть локальное суждение. Спонсор мог изменить решение о спонсорстве, влияющее на подключение. Государственный заказчик мог поднять вопросы работы подрядчика. IAB мог рекомендовать изменение политики.

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

Сотрудники NIC: полномочия по обработке без опубликованной второй инстанции

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

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

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

ВыпускNIC KNACKSот 17 мая 1985 года под названием «How to Reach the NIC» показывал раздельные каналы для помощи пользователям, компьютерных операций, обновлений WHOIS и регистрации пользователей, изменений хостов, материалов бюллетеня и вопросов по контрактам или управлению. В нём также описывалась горячая линия, которую поддерживали справочные и операционные сотрудники. Это свидетельство маршрутизации обслуживания. Человек, считавший запись неверной, знал, куда отправить исправление; тот, у кого была проблема с хостом, мог обратиться к функции Hostmaster; более широкую проблему можно было направить руководству.

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

Постел, IANA и делегированные полномочия по номерам

RFC 1174 даёт самое ясное заявление периода о полномочиях в отношении номеров. В нём IANA описывалась как обладатель первичной власти над числовыми идентификаторами, необходимыми для работы интернета; функцию выполнял Information Sciences Institute при USC. Internet Registry в SRI описывался как ведущий регистрационную информацию и выполняющий работу по присвоению в рамках делегированной ответственности.

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

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

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

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

IAB и федеральные сетевые органы: рекомендации — это не решения

RFC 1174 был адресован председателем Internet Activities Board председателю Federal Networking Council. Он содержал рекомендации о распределении присвоения идентификаторов и об изменении прежней политики статуса «подключено».

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

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

Глаголы имеют значение. IAB рекомендовал. FNC получил рекомендацию. В документе предлагалось, чтобы Internet Registry получил указание внести изменения. Один лишь RFC 1174 не устанавливает дату принятия решения FNC, исполняющую директиву или завершение каждого предложенного изменения.

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

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

DCA, спонсоры и разница между регистрацией и подключением

Инструкции по регистрации пользователей 1983 года показывают, что за кампанией регистрации стояло DDN-PMO. Администраторы хостов отвечали за авторизованных пользователей, и DDN-PMO заявляло, что будет работать с ними при возникновении проблем. Это было прямое заявление о решении проблем, но отношения проходили через администраторов.

Человек, не согласный с администратором хоста, оказывался в трудном положении. DDN-PMO могло разъяснить действующие инструкции или заняться системной проблемой. Документ не обещал, что человек сможет обойти администратора и получить независимый пересмотр. Авторизующее лицо одновременно было локальным институциональным представителем.

Государственное спонсорство иначе влияло на подключение. Описанная в RFC 1174 история статуса «подключено» говорит о санкции спонсирующей организации правительства США. Спонсор мог подтвердить, что сеть подходит для подключения, отозвать поддержку или уточнить объём финансируемой деятельности. Такое действие могло определять практический доступ, даже если Internet Registry уже присвоил номер.

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

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

Две контрактные цепочки, ни одна из которых не является автоматическим средством защиты заявителя

Федеральное финансирование создаёт надзор, но само по себе не создаёт права на апелляцию.

Первая релевантная цепочка —DCA–SRI/NIC. Путеводитель по коллекции SRI ARC/NIC называет финансируемые DCA работы NIC, контрактные предложения, результаты, ежемесячные отчёты и промежуточные проверки. Материалы DCA 1987 года включают совещание по проверке контракта и описывают задачи NIC и каналы обслуживания. Эти записи устанавливают, что государственный заказчик контролировал деятельность подрядчика.

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

Вторая цепочка —DARPA–USC/ISI/IANA.Решение GAO B-327398, вынесенное значительно позже, сообщало, что GAO не смог получить копии контрактов DARPA 1970–1990-х годов, в рамках которых развивались и выполнялись функции IANA, хотя ему удалось восстановить информацию о более поздней контрактной задаче, начавшейся в 1995 году. Этот вывод ограничивает умозаключения о ранних условиях DARPA–USC.

Он не устанавливает, что отдельная контрактная документация DCA–SRI отсутствует. Два подрядчика, государственные отношения и функции должны оставаться различными. Коллекция SRI описывает контрактные материалы, которые могут ответить на вопросы о работе NIC. Доказательственный пробел GAO касается исторических контрактов DARPA–USC/IANA.

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

Шесть разных вещей, которые позднее называют апелляцией

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

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

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

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

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

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

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

Эти категории могут пересекаться в одной фактической последовательности. Заявитель может исправить форму, попросить сотрудников Hostmaster пересмотреть решение, подключить спонсора, пожаловаться руководству и, наконец, предъявить внешний правовой иск. Ярлыки должны следовать за доказательствами на каждом шаге, а не трактовать всю последовательность как «апелляцию».

Телефон как практическое средство защиты и архивное слепое пятно

Самая сильная благоприятная альтернатива начинается с доступности NIC.

NIC публиковал электронные каналы и предоставлял телефонную помощь. RFC 1032 предполагал переписку до авторизации домена. Лист «How to Reach the NIC» 1985 года направлял разные темы разным ролям, включая помощь, регистрацию, изменения хостов, операции и управление. Путеводитель описывает справочную службу и горячую линию, которые отвечали на телефонные и электронные запросы и сообщали статистику активности в ежемесячных отчётах.

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

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

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

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

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

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

Кто имел доступ к практическому пересмотру?

Институциональная карта подсказывает вопрос о распределении, а не вывод о распределении.

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

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

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

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

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

Защитимое сравнение потребовало бы данных на уровне заявок и контроля технической готовности, запрашиваемого ресурса, требований спонсорства и полноты заявки. Без этих доказательств нельзя сообщать ни о равном, ни о неравном обращении как об установленном результате.

Суды и ведомства вне технической иерархии

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

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

Технические руководства периода не говорили, что неуспешный заявитель может попросить суд пересмотреть техническое суждение сотрудника Hostmaster. Они также не устанавливали, что каждое действие NIC или IANA является окончательным действием ведомства. Статус подрядчика, делегированные технические полномочия, федеральное спонсорство и государственное финансирование не сводятся к одной публично-правовой категории.

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

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

Контрфактуал A: сохранить решения, добавить обоснования

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

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

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

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

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

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

Контрфактуал B: действительно низкая конфликтность

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

Какие следы должна оставлять такая благополучная система?

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

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

Части благополучной инфраструктуры видны. RFC 1032 предполагал переписку. NIC поддерживал каналы помощи и управления. Администраторы хостов могли исправлять записи пользователей. DDN-PMO заявляло, что будет работать с администраторами при возникновении проблем. RFC 1359 рассматривал провайдеров как источник консультаций по заявкам. RFC 1174 описывал политику, нацеленную на широкое присвоение уникальных номеров при отделении санкции на подключение.

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

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

Краткий взгляд за пределы 1992 года

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

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

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

Какие выводы можно сделать

Три положения должны оставаться раздельными.

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

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

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

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

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

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

Источники

• RFC 810, «DoD Internet Host Table Specification», 1 марта 1982 года:https://www.rfc-editor.org/rfc/rfc810.html
• RFC 920, «Domain Requirements», октябрь 1984 года:https://www.rfc-editor.org/rfc/rfc920.html
• RFC 1032, «Domain Administrators Guide», ноябрь 1987 года:https://www.rfc-editor.org/rfc/rfc1032.html
• RFC 1062, «Internet Numbers», август 1988 года:https://www.rfc-editor.org/rfc/rfc1062.html
• RFC 1174, «IAB Recommended Policy on Distributing Internet Identifier Assignment and IAB Recommended Policy Change to Internet “Connected” Status», август 1990 года:https://www.rfc-editor.org/rfc/rfc1174.html
• RFC 1359, «Connecting to the Internet», август 1992 года:https://www.rfc-editor.org/rfc/rfc1359.html
• RFC 1400, «Transition and Modernization of the Internet Registration Service», март 1993 года:https://www.rfc-editor.org/rfc/rfc1400.html
• Network Information Center, «Instructions for Network User Registration Drive», 20 октября 1983 года, внутренние страницы 1–7, страницы 67–73 оцифрованного комплектаDefense Communication Agency Materials; 6 of 13:https://archive.computerhistory.org/resources/access/text/2023/07/102707743-05-06-acc.pdf
• DDN Network Information Center, «How to Reach the NIC»,NIC KNACKS, выпуск № 2, 17 мая 1985 года, страница 94 оцифрованного комплектаDefense Communications Agency Materials; 3 of 13:https://archive.computerhistory.org/resources/access/text/2023/07/102707743-05-03-acc.pdf
• Computer History Museum,Guide to the SRI ARC/NIC Records, коллекция X3578.2006, 2011 год:https://archive.computerhistory.org/resources/access/text/finding-aids/102706170-SRI/102706170-SRI.pdf
• Джеймс Пелки, интервью с Джонатаном «Джоном» Постелом, записано 18 февраля 1988 года:https://archive.computerhistory.org/resources/access/text/2016/05/102738139-05-01-acc.pdf
• US Government Accountability Office, B-327398, «Department of Commerce—Property Implications of Proposed Transition of U.S. Government Oversight of Key Internet Technical Functions»:https://www.gao.gov/products/b-327398