Кратко

  • Квалификационное заявление SRI от 1988 года содержит номера контрактов, даты, финансирование и объём работ, но публичные копии самих контрактов, изменений к ним и технических заданий обнаружить не удалось, поэтому точные обязательства, средства защиты и периоды пересечения остаются невыясненными.
  • Закупки DCA обеспечивали услуги NIC в цепочке DDN и Министерства обороны, тогда как правила эксплуатации DDN, политика IAB и DARPA в отношении доменов, делегирование IANA через USC/ISI и внешняя зависимость давали отдельные, привязанные к конкретным услугам мосты, которые нельзя свести к единому контрактному мандату.
  • Передача функций в 1991 году показывает, что оператор сменился, а данные, каналы запросов и услуги были сохранены; это не подтверждает отсутствующие условия закупки, обязанности по переходу, права собственности, затраты или средства защиты для внешних пользователей.

Отчёт подрядчика о собственном опыте

Самая подробная публичная таблица номеров контрактов DDN-NIC взята не из подписанного контракта Агентства оборонных коммуникаций (DCA), технического задания или отчёта государственной инспекции. Она приводится в документе SRI International от 27 октября 1988 года, подготовленном для совершенно другой возможности:Квалификационное заявление для запроса предложений F04701-88-R-0043: «Техническая поддержка информационного центра глобальной системы позиционирования». Центр сетевых информационных систем SRI представил документ, чтобы продемонстрировать способность разработать и эксплуатировать предлагаемый гражданский информационный центр GPS. Обсуждение DDN-NIC в нём было корпоративным опытом, приводимым в поддержку этой заявки.

Это происхождение меняет то, как следует читать каждую строку таблицы. SRI сообщило, что контракт DCA200-83-C-0025 действовал с 1 июня 1983 года по 31 декабря 1985 года и имел финансирование в размере 3 122 367 долларов. Контракт DCA200-84-C-0024 — с 15 июня 1984 года по 31 января 1987 года с финансированием 8 128 495 долларов. Контракт DCA200-87-C-0020 — на два годовых периода, начиная с 1 февраля 1987 года, с 3 772 115 долларами за первый год и 4 121 252 долларами за второй. Даты пересекаются.

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

SRI также описало восемь направлений работ, включая базовые сетевые информационные службы; протоколы и архитектуру информации и баз данных; контроль доступа к сети и регистрацию пользователей; систему аудиторских журналов и биллинга DDN и ARPANET; службу имён и каталогов для интернета Министерства обороны; и эксплуатацию правительственного компьютерного объекта. Оно перечислило WHOIS, службу имён, регистрацию доменов, распространение протоколов, телефонную горячую линию, регистрацию пользователей, онлайн-информационные службы, публикации и программное обеспечение.

В конце таблицы SRI заявило, что все обязательства выполнены без перерасхода средств.

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

Одна часть описанной цепочки имеет отдельное федеральное подтверждение. Национальная служба технической информации (NTIS) каталогизирует выпущенное в 1985 годуСправочное руководство по протоколам DDN, том 1: военные стандартные протоколы Министерства обороныкак технический отчёт SRI DDN-NIC, подготовленный по контракту DCA200-83-C-0025. Запись NTIS описывает руководство для разработчиков, планирующих подключение компьютеров к Defense Data Network, включая ARPANET. В ней указаны роли DCA и Управления программами DDN в стандартизации протоколов и управлении конфигурацией. Это подтверждает, что номер контракта был связан по крайней мере с этим документированным продуктом. Это не раскрывает остальной объём контракта, его платёжную структуру, средства защиты или права лиц, не являвшихся его сторонами.

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

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

Цепочка закупок, которую можно установить

Основное институциональное отношение ясно на высоком уровне. Министерство обороны обеспечивало государственный контекст. DCA управляло Defense Data Network и заключало с SRI контракты на работы NIC. SRI International было подрядчиком. DDN-NIC был операционным центром, через который SRI предоставляло услуги регистрации, информации и поддержки. Объекты DDN и документированные пользователи ARPANET и MILNET составляли население, для которого государственные операционные полномочия видны наиболее отчётливо.

ВПутеводителе по архивам SRI ARC/NICМузея компьютерной истории за 2011 год говорится, что сохранившийся архив содержит предложения, технические задания, контракты, изменения, переписку, ежемесячные отчёты о ходе работ и отчёты о результатах по контрактам. Указано, что к 1987 году работы NIC состояли из множества задач с назначенными руководителями и бюджетами. Формальные ежемесячные отчёты описываются как продолжавшиеся до 1991 года, а отчёты о результатах по контрактам охватывают 1980–1990 годы. Таким образом, опись называет виды документов, обычно связанных с администрированием государственных контрактов: нумерованные документы, структуры задач, бюджеты, отчёты и файлы изменений.

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

Наиболее сильные доказательства реально предоставлявшихся услуг исходят из современных эксплуатационных документов. RFC 811, выпущенный в марте 1982 года, описывал сервер имён Hostnames как часть серии служб имён, поддерживаемых NIC SRI по поручению DCA. RFC 954, опубликованный в октябре 1985 года, аналогично идентифицировал сервер NICNAME/WHOIS. Запись NTIS о руководстве связывает крупное издание DDN с одним заявленным номером контракта. RFC 1032, выпущенный SRI в ноябре 1987 года, сообщал, что DCA назначило NIC поставщиком услуг регистрации доменов для частей интернета DDN и DARPA.

К февралю 1991 года RFC 1206 всё ещё называло SRI International оператором NIC.DDN.MIL, хранилища RFC и Internet Drafts, поставщиком поддержки пользователей DDN, площадкой Интернет-реестра и оператором служб доменов и WHOIS.

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

Название ведомства меняется ближе к концу периода. DCA сохраняло это имя до 25 июня 1991 года, когда директива Министерства обороны 5105.19 переименовала его в Агентство оборонных информационных систем (DISA). Современные и более поздние тексты иногда используют эти два названия нестрого при обсуждении перехода, но дата важна. DCA — правильное название ведомства для контрактов SRI, заявленных в 1983, 1984 и 1987 годах. DISA — правильное название для ведомства, указанного в уведомлении об операционной передаче от сентября 1991 года.

Между этими точками есть существенный пробел. В квалификационной таблице SRI 1988 года окончанием периода по указанному контракту DCA200-87-C-0020 названо 31 января 1989 года. RFC 1206 показывает, что SRI всё ещё эксплуатировало DDN NIC в феврале 1991 года, а архивный путеводитель описывает ежемесячные отчёты до этого года. Ни один из рассмотренных публичных документов не называет опцион, продление, промежуточный контракт, изменение или соглашение-преемника, обеспечивавшие работу с февраля 1989 года до передачи в 1991 году.

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

Что правила DCA делали обязательным

Внутри среды DDN действия DDN-NIC были связаны с государственными операционными полномочиями правилами более конкретными, чем статус самого подрядчика.

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

Это была эксплуатационная спецификация, а не контракт. Тем не менее она называет конкретный источник полномочий. Хост DoD подчинялся правилам сети, управляемой ведомством DoD. NIC получало и вело требуемую запись, но операционные последствия вытекали из положения DCA над сетью DoD и её участвующими объектами. SRI не нуждалось в независимых регулятивных полномочиях над военным хостом, когда DCA могло сделать регистрацию одним из условий использования этой сетью.

Справочное руководство по протоколам DDN1985 года соответствует той же схеме. Его заявленная цель — помочь разработчикам подключать машины к DDN. Руководство объясняло требования DoD к протоколам, управление конфигурацией и роли DCA и Управления программами DDN. Его сила в отношении охваченного объекта проистекала из места этого объекта в программе DDN, а не из публичной доступности руководства или авторства SRI.

RFC 954 даёт ещё один ограниченный пример. WHOIS был доступен через интернет, и DCA поощряло сетевые хосты делать услугу доступной пользователям. Однако его язык регистрации был сосредоточен на людях с учётными записями на хостах ARPANET или MILNET, которые могли передавать трафик через интернет DoD. Пользователи контроллеров терминального доступа MILNET (TAC) должны были регистрироваться. Документ указывал почтовый ящик и телефон регистратора, но не объявлял, что каждый человек, использующий TCP/IP где угодно, обязан вноситься в каталог, поддерживаемый DCA.

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

Надзор DCA виден и в инструкциях по подаче заявок в RFC 1032. Если принятие полностью определённого доменного имени меняло официальное имя хоста ARPANET или MILNET, заявитель должен был заранее получить одобрение DCA и заложить время на обработку. Административный мост виден: затрагиваемый хост принадлежал среде, управляемой DCA; предлагаемое имя меняло официальную запись, используемую в этой среде; NIC обрабатывало запрос; и требовалось одобрение DCA.

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

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

Полномочия, которые давала интернет-политика

Закупки были не единственным мостом между DDN-NIC и более широким интернетом. Позитивные полномочия, предоставленные технической политикой, следует оценивать на их собственных основаниях.

RFC 920, опубликованный в октябре 1984 года Джоном Постелом и Джойс Рейнольдс из USC/ISI, объявлял себя официальным заявлением о политике Совета по активности интернета (IAB) и DARPA. Он определял требования к созданию доменов в сообществе ARPA-Internet и исследований DARPA. Домены должны были иметь ответственных администраторов, надёжную службу имён и регистрацию в иерархии. NIC было указано как агент для первоначальных доменов верхнего уровня. DARPA было указано как администратор для ARPA, GOV, EDU, COM и ORG; Управление программ DDN — администратор для MIL.

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

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

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

К ноябрю 1987 года RFC 1032 описывал реализацию в более развитой форме. Он говорил, что DCA назначило NIC поставщиком услуг реестра для системы доменов в частях интернета DDN и DARPA. Он называл NIC регистратором доменов верхнего и второго уровня, администратором корневых зон от имени DARPA и DDN и временным администратором нескольких поименованных доменов верхнего уровня, пока подходящие организации не примут их.

Будущий администратор домена получал анкету, указывал требуемые организационные и технические данные и возвращал заполненную форму на HOSTMASTER в SRI. Путеводитель говорил, что заявка должна быть полной, прежде чем NIC авторизует создание домена. В нём также описывались альтернативные схемы регистрации, при которых организации управления CSNET и UUCP обрабатывали заявки для своих сообществ и передавали соответствующие сведения в NIC для включения в центральную базу данных и корневые файлы.

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

Эти полномочия не проистекали исключительно из закупочных отношений DCA с SRI. Они опирались на сочетание политики IAB и DARPA, назначения NIC агентством DCA для документированных частей интернета, распределения ответственности в иерархии и запроса заявителя на включение. Они также не были безграничными. RFC 1032 рассматривал многие решения об именах как локальные дела. В нём говорилось, что NIC не будет решать, какая спорящая сторона имеет основное право на регистрацию имени для организации. Конфликты должны были разрешаться до регистрации, тогда как NIC ограничивалось техническим руководством и обработкой.

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

Номера, IANA и Интернет-реестр

Администрирование интернет-номеров шло другим институциональным путём. Различие между функцией IANA в USC/ISI и функцией Интернет-реестра в SRI существенно, потому что иначе один и тот же почтовый ящик мог бы выглядеть так, будто все полномочия проистекают из закупки DCA.

RFC 1020, опубликованный сотрудниками SRI в ноябре 1987 года, объявлял, что Hostmaster в DDN-NIC принял на себя ответственность за назначение номеров IP-сетей и номеров автономных систем. В нём признавалась продолжающаяся помощь Джона Постела и Джойс Рейнольдс из USC/ISI. Документ был официальным отчётом о состоянии со списком назначенных идентификаторов; он не воспроизводил соглашение, передавшее операционную работу.

RFC 1174 давал современный политический отчёт в августе 1990 года. В нём описывалась функция IANA как выполняемая в USC/ISI и говорилось, что IANA имеет дискреционные полномочия делегировать части ответственности за идентификаторы. Для сетевых номеров и номеров автономных систем ответственность была размещена в Интернет-реестре, управляемом SRI в DDN-NIC. SRI было не просто пассивным получателем форм. В рамках принятой технической договорённости оно было основным реестром этих идентификаторов.

Эта делегация была мостом позитивных полномочий. Она объясняет, почему организация за пределами закупочного круга DDN могла тем не менее направить запрос номера в DDN-NIC и считать результат авторитетным. Заявителю нужен был глобально уникальный идентификатор, признаваемый общей системой координации интернета. Функция IANA в USC/ISI разместила соответствующую регистрационную ответственность у SRI. Другие операторы сверялись с назначениями реестра и использовали их, чтобы избегать коллизий.

У моста всё же были определённые границы. RFC 1174 сохранял IANA и Интернет-реестр институционально различными. USC/ISI выполняло центральную функцию IANA; SRI выполняло работу реестра, делегированную ему. IAB рекомендовал, чтобы реестр выделял блоки одобренным региональным организациям, а дальнейшие полномочия по назначению распределялись на международном уровне. DDN-NIC должен был оставаться реестром по умолчанию там, где нет делегированного реестра, а агрегированные копии регистрационных данных — распространяться для улучшения доступа и резервирования.

RFC 1174 не устанавливает полное договорное основание отношений IANA с DARPA, DCA или SRI. Его утверждение, что IANA обладает дискреционными полномочиями делегирования, фиксирует политическую договорённость, признанную IAB. Оно не заменяет отсутствующие соглашения DARPA и DCA. Счётная палата США (GAO) столкнулась со сравнимым доказательственным затруднением в 2016 году при изучении имущественных интересов правительства в исторических интернет-функциях: ключевые контракты с 1970-х по 1990-е годы получить не удалось, что не позволило сделать уверенные выводы о правах, переданных этими соглашениями.

Институциональная картина, таким образом, многослойна. Ведомства Министерства обороны финансировали важные объекты и функции. DCA закупало услуги NIC для DDN. DARPA и IAB давали политику для исследовательского интернета и формирующейся системы доменов. USC/ISI выполняло IANA и делегировало работу по регистрации номеров. SRI эксплуатировало Интернет-реестр и DDN-NIC. Заявители соблюдали процесс регистрации, потому что стремились получить признанные идентификаторы. Операторы сетей и DNS затем использовали полученные данные.

Каждый слой имел значение. Ни один не даёт полных полномочий всех остальных.

Университет Райса: снимок, а не досье сделки

Университет Райса иллюстрирует и охват реестра, и ограничения сохранившихся доказательств по делу.

RFC 1020 перечисляет RICE-NET на 128.42 и относит его к исследовательским сетям. RFC 1032 использует ответ WHOIS дляrice.eduкак пример того, как администратор домена может проверить регистрационные данные. Показанная запись называет Университет Райса, его контакты и его серверы домена. Эти записи устанавливают, что связанные с Райсом сведения о номерах и доменах появлялись в публикациях и службах DDN-NIC в ноябре 1987 года.

Они не раскрывают первоначальную заявку Райса, личность должностного лица, подавшего её, отношения по финансированию, путь подключения, обмен сообщениями с Hostmaster или время обработки. Они не показывают оспариваемый запрос, отклонение, переопределение, официальное уведомление об одобрении или апелляцию. RFC 1020 не помечает RICE-NET звёздочкой как независимую сеть, поэтому было бы небезопасно на этом основании описывать Райс как внешнюю неприсоединённую сеть.

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

Операционное значение записей может быть описано только на уровне системы. Выделенный номер давал общему реестру уникальный идентификатор для публикации для RICE-NET. Действительная делегация домена позволяла системам, использующим общую иерархию DNS, узнавать, какие серверы авторитетны дляrice.edu. Документы не устанавливают, что какой-то конкретный пакет был маршрутизирован, что Райс получил физическую связность от DDN-NIC или что другая сеть была обязана передавать трафик Райса.

Ни один из рассмотренных публичных документов не устанавливает полный внешний спор за 1983–1991 годы, в котором идентифицируемый заявитель, не состоящий в контракте, подал запрос домена или номера в DDN-NIC, получил оспариваемое решение, обратился за пересмотром и получил документированный исход. Это ограничение доступного анализа, а не свидетельство того, что споров никогда не было. Без такого досье невозможно проверить, как SRI объясняло неблагоприятное решение, рассматривало ли его DCA или USC/ISI, какое средство защиты существовало и имел ли заявитель подлежащее принудительному исполнению право.

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

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

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

Надзор без раскрытой оговорки о средствах защиты

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

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

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

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

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

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

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

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

Техническая политика включала механизмы распределения ответственности. RFC 920 допускал перераспределение ролей регистратора более подходящим организациям. RFC 1032 распределяло администрирование вниз по иерархии DNS и отказывалось централизовать локальные споры. RFC 1174 предлагало дальнейшую делегацию регистрации номеров и более широкую репликацию данных реестра. Это были не договорные средства защиты и не судебный пересмотр, но они показывают, что архитектура не требовала, чтобы один подрядчик оставался единственным операционным центром навсегда.

Пересмотр охвата в 1990 году

К 1990 году население интернета больше не соответствовало государственным и исследовательским сообществам, для которых разрабатывались прежние процедуры. RFC 1174 описывало рост в промышленности, академических кругах и зарубежных сетях и предлагало изменения как в назначении идентификаторов, так и в значении статуса «подключённости».

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

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

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

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

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

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

Эти эффекты не все возникали из закупочных отношений SRI с DCA. Мостом для регистрации номеров были делегирование IANA и участие заявителя в общей системе идентификаторов. Мостом для регистрации доменов были структура политики IAB и DARPA, документированное назначение DCA, иерархия DNS и запрос заявителя на включение. Мостом для правил эксплуатации DDN было использование DDN и соответствующие государственные отношения. Мостом для передачи трафика была политика используемой сети.

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

Отсутствующие годы и передача 1991 года

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

Заявленный период контракта DCA200-87-C-0020 заканчивался 31 января 1989 года. Современные RFC показывают, что SRI продолжало эксплуатировать DDN-NIC в 1990 году и начале 1991 года. Архивный путеводитель описывает отчёты о ходе работ до 1991 года. Ни один из рассмотренных публичных документов не называет контракт, опцион, изменение или промежуточное соглашение, обеспечивавшие продолжение. Закупочное основание периода с февраля 1989 года до передачи 1991 года остаётся невыясненным.

25 июня 1991 года DCA стало DISA. В сентябре RFC 1261 объявило, что Сетевой информационный центр переезжает от SRI International в Менло-Парке в Government Systems Inc. в Чантильи 1 октября. В нём были перечислены услуги, предлагавшиеся тогда и пользователям DDN, и пользователям интернета: регистрация сетей и пользователей, назначение номеров сетей и доменов верхнего уровня, онлайн-информационные службы, работа службы поддержки, а также архивы и распространение RFC и Internet Drafts.

Уведомление было написано Скоттом Уильямсоном и Лесли Нобиле из Network Solutions. В нём говорилось, что SRI продолжит отвечать на звонки и запросы до 30 сентября. База данных WHOIS не будет изменяться с 26 по 30 сентября, пока регистрационные действия приостановлены и главная база данных передаётся в GSI. Запросы по почте и факсу должны были направляться на новый адрес GSI; электронные сообщения на знакомые почтовые ящики Hostmaster и Registrar должны были продолжать работать и перенаправляться по мере необходимости. Регистрационная деятельность возобновлялась 1 октября.

Новый NIC использовал Sun 470 SPARCserver под управлением SunOS 4.1, заменив прежнюю среду TOPS-20.

Эти детали устанавливают операционную передачу поставщика. Данные переехали. Адреса, телефонные номера и вычислительная инфраструктура изменились. Запросы были приостановлены, перенаправлены и возобновлены. Уведомление также устанавливает, что DISA и GSI были публично связаны с переходом и что сотрудники Network Solutions участвовали во внедрении или сообщении о преемственной службе.

Решение федерального окружного суда 1998 года,Thomas v. Network Solutions, дало более поздний юридический пересказ. Суд сообщил, что Network Solutions получила субподряд в рамках закупочного контракта, заключённого DISA с GSI, и что её обязанности включали регистрацию доменов и назначение IP-номеров. Отдельное решение 2000 года цитировало данные под присягой показания должностного лица Национального научного фонда Джорджа Строуна, описывавшего Network Solutions как субподрядчика GSI, поддерживавшего DDN и интернет по контракту DISA.

Эти более поздние пересказы поддерживают описание на высоком уровне «генеральный подрядчик — субподрядчик»: DISA как государственное ведомство, GSI как держатель закупочных отношений и Network Solutions как субподрядчик, выполнявший работу реестра. Они не раскрывают номер награждения, запрос предложений, протокол отбора, подписанный генеральный контракт или субподряд. Они также содержат ретроспективные резюме, которые не должны вытеснять современный отчёт RFC 1261 об операционной передаче 1 октября.

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

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

Круг обслуживаемых также требует осторожности. RFC 1261 адресовано и пользователям DDN, и пользователям интернета, что доказывает: операционный переход проектировался вокруг сообщества шире военных объектов. Это утверждение не устанавливает, что все эти пользователи были договорными бенефициарами. Правительство может закупать услугу, сделанную публично доступной, не давая каждому пользователю права принуждать к исполнению закупки.

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

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

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

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

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

Практическая зависимость и её пределы

К концу 1980-х DDN-NIC находился на пересечении нескольких форм зависимости. Некоторые были прямыми следствиями государственных эксплуатационных правил. Другие проистекали из технического делегирования, иерархии и общего принятия.

Для охваченного пользователя DDN, ARPANET или MILNET соответствующее обязательство могло быть явным в эксплуатационной спецификации или инструкции управления. Хост мог быть обязан зарегистрировать своё официальное имя, получить одобрение изменения или предоставить точные сведения о пользователях, потому что этого требовал государственный администратор сети. SRI вело запись, но обязывающее отношение проходило через управляемый правительством объект.

Для заявителя домена за пределами этого круга непосредственным следствием было общее пространство имён. Полная заявка и соответствующая схема серверов имён были условиями делегирования в соответствующем домене верхнего уровня. Роль DDN-NIC подкреплялась политикой IAB и DARPA, назначением DCA для частей DDN и DARPA и иерархическими полномочиями, предоставленными регистраторам и администраторам доменов. Стимулом заявителя было признанное разрешение через общую систему.

Для заявителя номера RFC 1174 называло другой мост: функция IANA в USC/ISI разместила ответственность за регистрацию номеров сетей и автономных систем в Интернет-реестре SRI. Ценность назначения возникала из уникальности и признания среди участвующих систем. Само по себе оно не создавало маршрут, подключение или разрешение использовать федерально спонсируемую магистраль.

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

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

Доказательства наиболее сильны там, где они называют точный мост. RFC 810 связывало регистрацию с условиями, на которых хосты DoD обменивались трафиком. RFC 920 связывало создание доменов с политикой и иерархией сообщества ARPA-Internet и исследований DARPA. RFC 1032 связывало авторизацию с полной заявкой и обязанностями администрации домена. RFC 1174 связывало регистрацию номеров с делегированием IANA, отделяя регистрацию от статуса подключения и политики маршрутизации. RFC 1261 показало, что непрерывность услуг для пользователей DDN и интернета требовала управляемой операционной передачи.

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

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

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

Что заголовок может безопасно означать

Доказательства поддерживают ограниченный ответ на три отдельных вопроса.

Внутри цепочки DDN и Министерства обороны DCA имело документированную государственную роль, а SRI было документированным подрядчиком. Эксплуатационные спецификации и руководства требовали регистрации или одобрения для определённых действий DDN, ARPANET и MILNET. DDN-NIC обрабатывало записи, поддерживало службы и сообщало процедуры от имени DCA. Сила этих действий исходила из управления сетью агентством DCA и обязательств охваченных объектов. Поскольку соответствующие технические задания и оговорки о средствах защиты остаются недоступными, точный контрактный периметр реконструировать нельзя.

За пределами этого закупочного круга организации принимали и использовали несколько служб. Они обращались за уникальными идентификаторами в Интернет-реестр, подавали заявки на домены в общей иерархии, запрашивали WHOIS, получали RFC и полагались на данные корневых серверов. Их мотивы включали делегирование IANA, политику IAB и DARPA, ограниченное назначение DCA, соблюдение заявителями процедур регистрации, техническую интероперабельность, накопленное доверие и практическую цену отхода от широко используемой системы. Эти мосты давали DDN-NIC реальные полномочия по конкретным решениям о регистрации.

Полномочия над записью реестра не были полномочиями над каждой связанной организацией или сетью. Администраторы доменов сохраняли ответственность в своих доменах. IANA оставалась отличной от Интернет-реестра. DCA и DARPA имели разные институциональные роли. Назначение идентификатора не обеспечивало взаимосоединение. Включение в DNS не командовало каждым маршрутом. Политика допустимого использования магистрали применялась через использование этой магистрали, а не просто через появление в центральной базе данных.

Ни один из рассмотренных публичных документов не устанавливает универсального моста, посредством которого закупка DCA услуг SRI сама по себе связывала каждую не состоящую в контракте сеть, использовавшую полученные записи. И отсутствие такого документа не стирает более узкие полномочия, обеспеченные политикой IAB, спонсорством DARPA, делегированием IANA, правилами иерархии и участием заявителей.

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

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

Такой подход отдаёт DDN-NIC должное. SRI эксплуатировало важную инфраструктуру в период стремительных институциональных и технических изменений. Его сотрудники вели реестры, каталоги, публикации, каналы поддержки и серверы, использовавшиеся за пределами самого узкого военного круга. Услуги были достаточно ценны, чтобы их передача в 1991 году потребовала приостановки регистрационных действий, перемещения главной базы данных, перенаправления запросов и скоординированной смены хост-инфраструктуры.

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

Источники