RFC 790 и политика, скрытая в списке адресов

Кратко

• RFC 790 прямо устанавливает, что несколько рядов номеров велись как действующий операционный справочник и что разработчикам предписывалось обращаться за назначениями к Jon Postel, но в документе не публикуется ни общее правило допуска сетей, ни разделение полномочий по распределению.
• RFC 820 добавляет исследовательскую, оборонную и коммерческую категории, рекомендованное распределение пространства номеров сетей, предлагаемое условие готовности шлюза для исследовательских заявителей и перспективное разделение обязанностей между организациями.
• RFC 820 также сообщает, что его рекомендация ещё не полностью реализована и что Postel по-прежнему координировал все назначения; поэтому соглашение, предлагаемая политика и рабочая практика не могут считаться одним и тем же институциональным состоянием.
• Опубликованные таблицы показывают назначения, переходы и внутренние расхождения, а не совокупность заявителей. Без записей о заявках, отказах, отзывах, использовании и современной переписки они не могут установить обращение с заявителями, распределительный мотив или намерение скрыть принятие решений.

Положите первую страницу двух моноширинных документов под одну настольную лампу. На странице 1RFC 790, датированного сентябрём 1981 года, вводный абзац говорит, что актуальную информацию можно получить у Jon Postel, и добавляет: «Распределением номеров также занимается Джон». Соответствующий абзац в изученном текстеRFC 820сохраняет личную грамматику, но вставляет оговорку: назначениями занимается тот же координатор в соответствии с соглашением между DARPA/IPTO и DDN/PMO, зафиксированным в приложении A.

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

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

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

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

Два документа, одно расхождение в каталоге

RFC 790 — документ Network Working Group на 15 страницах, автором указан J. Postel из University of Southern California’s Information Sciences Institute, датирован сентябрём 1981 года. В нём сказано, что зафиксированы действующие присвоенные значения из нескольких рядов, используемых в реализациях сетевых протоколов. Разработчику, которому нужен номер линии, сокета, порта, протокола или сети, предписано обратиться к Postel, чтобы получить назначение.

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

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

Раздел о номерах сетей занимает страницы 2–4. В нём объясняются три класса адресов и приводятся их побитовые схемы. Класс A использует ведущий ноль, семь битов номера сети и 24-битное локальное поле. Класс B — старший шаблон10, четырнадцать битов номера сети и 16-битное локальное поле. Класс C —110, двадцать один бит номера сети и восьмибитное локальное поле. Это были технические категории с совершенно разной ёмкостью, но само существование разной ёмкости не доказывает, как оценивались заявки и была ли экономия причиной того или иного назначения.

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

Изученный документ RFC 820 длиннее — 22 страницы. В его текстовом заголовке указаны J. Postel и J. Vernon, а также январь 1983 года. Текущаязапись в каталоге RFC Editor, напротив, называет RFC 820 «Assigned numbers, August 1982» и указывает только J. Postel. В этом анализе фрагменты идентифицируются по заголовку и номерам страниц изученного текста, при этом расхождение каталога сохраняется. Доступные источники не дают оснований молча выбрать одно из соглашений о дате и авторстве как исправление другого.

RFC 820 сохраняет прежнюю функцию описи, но расширяет её охват. В нём упоминается переход от среды ARPANET к ARPA Internet, добавляются номера автономных систем, номера Ethernet и отображения сетей передачи данных общего пользования, а таблицы сетей существенно расширены. Самое важное здесь: страница 1 подчиняет распределение номеров соглашению DARPA/IPTO–DDN/PMO, а страницы 19–22 воспроизводят вытекающие из него рекомендации и примечание о реализации.

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

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

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

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

«Assigned», «registered», «current» и «official» не были синонимами

Вводная инструкция RFC 790 делает больше, чем просто предлагает разработчику сообщить самостоятельно выбранное значение. В ней сказано обращаться к Postel, «чтобы получить назначение номера». Прежде чем новое значение могло безопасно появиться в общем списке, кто-то должен был узнать о запросе, проверить коллизии, выбрать или подтвердить значение, сообщить результат и обновить реестр. Эта минимальная последовательность и есть координируемая административная работа.

Из этого не следует, что каждый ряд номеров предполагал столь же значимое решение. Для многих запросов протоколов или портов основным действием мог быть поиск неиспользуемой кодовой точки и поддержание совместимости. Текст не даёт оснований утверждать, что институциональные заслуги каждого разработчика оценивались. Слово «назначение» (assignment) обозначает операцию, но одно его присутствие не раскрывает ни критериев, ни глубины суждения, стоявших за ней.

Номера сетей — другое дело, потому что RFC 820 связывает их с административными категориями использования и рекомендуемым условием допуска. Приложение A говорит, что в сообществе исследований и разработок идентификаторы сетей будут предоставляться только заявителям, которые представят доказательства того, что приобретают стандартное шлюзовое ПО BBN или реализовали либо приобретают шлюз, отвечающий требованиям Exterior Gateway Protocol. Там же добавлено, что приобретение ПО Berkeley BSD 4.2 UNIX может считаться доказательством последнего.

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

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

RFC 820 использует слово «registered» в разделе об автономных системах. Exterior Gateway Protocol предоставляет 16-битное поле для идентификации автономных систем, и значения регистрируются в документе. Первоначальная таблица почти пуста: ноль зарезервирован, единица идентифицирует шлюзы BBN, значения от 2 до 65 534 не назначены, а 65 535 зарезервировано. Здесь регистрация описывает общий учёт ряда идентификаторов на раннем этапе. Её нельзя без разбора переносить на приложение о сетях, где классификация и рекомендуемые доказательства для заявителей добавляют иные соображения.

«Official» становится явным в RFC 943, а не во вводных формулировках статуса RFC 790 или RFC 820. Эта более поздняя формулировка описывает признание внутри сообщества ARPA-Internet. Она не приравнивает каждое более раннее действие по ведению списка к формальному государственному решению и не устанавливает, что запись имела то же значение вне сообщества, для которого работал отчёт.

Таким образом, слова обозначают пересекающиеся, но отделимые функции. «Assignment» может включать выбор или подтверждение. «Registration» фиксирует значение. «Currentness» выражает поддержание в актуальном состоянии. «Official» обозначает признанный статус в определённом операционном сообществе. Их соседство в линии документов Assigned Numbers не сливает их в единый универсальный авторитет.

В одной публикации было несколько разнородных реестров

Название «Assigned Numbers» собирает несколько рядов в один документ, но проблемы коллизий и институциональные ставки в них не были взаимозаменяемы.

Номер интернет-протокола занимал восьмибитное поле в заголовке IP и обозначал протокол следующего уровня, переносимый пакетом. Координация этого номера позволяла разным реализациям единообразно интерпретировать поле. Приложение A RFC 820 предлагало зарезервировать части пространства номеров протоколов под стандарты DoD, исследовательское использование и коммерческие, национальные или международные стандарты. Это была координация идентификаторов протоколов, а не выделение организации ёмкости адресов хостов.

Номер порта обозначал точку подключения к сервису на конце логического соединения. RFC 790 ещё обсуждал и сокеты AHHP, и порты TCP, тогда как RFC 820 представлял список портов с центром на TCP и по возможности повторным использованием с UDP. Назначение хорошо известного порта могло сделать сервис совместимым между реализациями. Но оно не делало названного автора протокола или контакт сервиса держателем сетевого блока.

Номера сетей играли другую роль. Они обозначали сети в архитектуре интернет-адресации. Выбранный класс определял ширину поля локального адреса: 24 бита для класса A, шестнадцать для класса B и восемь для класса C. Назначения сетей различались поэтому не только как метки, но и по адресной ёмкости и режиму маршрутизации. Код категории, пометка перехода и рекомендация о готовности шлюза в RFC 820 относились именно к этой более институционально дифференцированной операции.

Номера автономных систем были ещё одним отдельным рядом. Их назначение — идентифицировать группы шлюзов для Exterior Gateway Protocol. Их появление в RFC 820 фиксирует раннее развитие междоменной координации; оно не даёт общей доктрины допуска для номеров сетей.

Номера линий ARPANET относились к среде интерфейса Host/IMP. Приложение RFC 820 рекомендовало устранить излишние использования и изучить вопросы совместимости между интерфейсами. Эта задача касалась другого поля протокола и другого набора операционных зависимостей.

Регистрацию имён нельзя выводить только из того, что таблицы портов содержат службы, связанные с именами. RFC 790 назначает порт 42 серверу имён и порт 43 — Whois. RFC 820 содержит эти контакты служб и добавляет порты серверов имён хостов или почтовых ящиков. Это записи для доступа к службам, а не реестр имён хостов или доменов. Раздел людей — также справочник ответственных контактов, а не реестр имён или журнал заявителей.

Архивный указатель Computer History Museum по записям SRI ARC/NICусиливает институциональное различие. В нём поддержание ARPANET Host Table и более поздние переходы в области имён описываются как отдельная деятельность. Там также сказано, что администрирование Assigned Numbers и глобальное распределение адресов перешли от USC-ISI к контракту SRI NIC в 1987 году. Указатель — более поздний архивный контекст, а не доказательство того, что SRI выполняла в 1981–1983 годах функцию назначения, описанную в двух RFC.

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

Административные категории не заменили технические классы

RFC 820 накладывает друг на друга две разные классификации. Первая — архитектурная: классы A, B и C определяют форматы адресов. Вторая — административная:R,DиCобозначают исследования и разработки, DoD и коммерческое использование. Их смешение создаёт ложные сравнения.

На странице 2 изученный текст RFC 820 корректно описывает класс A как имеющий ведущий ноль, а класс B — как имеющий ведущий шаблон10. В прозе класса C три старших бита описаны как1-0-0, но соседняя схема показывает1 1 0, а диапазон класса C начинается со 192, старшие биты которого —110. RFC 790 также печатает шаблон класса C как110. Поэтому фраза1-0-0в RFC 820 — внутренняя текстовая ошибка, а не свидетельство другой архитектуры адресов.

Три технических класса содержали соответственно 128, 16 384 и 2 097 152 возможных значения номера сети — до зарезервированных крайних точек и прочих исключений. Их локальные поля содержали (2^{24}), (2^{16}) и (2^8) числовых значений адресов на сеть. Эти различия делали выбор класса значимым, но ни один RFC не приводит измерений использования хостами для перечисленных сетей.

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

Приложение A рекомендует разделить доступные пространства классов между тремя сферами использования. Для класса A оно отводит восемь сетей исследованиям и разработкам, 24 — DoD и 94 — коммерческому использованию. Для класса B — 1 024, 3 072 и 12 286. Для класса C приложение печатает 65 536 для исследований, 458 725 для DoD и 1 572 862 для коммерческого использования.

Это предлагаемые распределения, а не описание завершённого раздела. Рабочая таблица на странице 6 сообщает о 26 назначенных идентификаторах класса A исследовательского назначения, четырёх оборонных и одном коммерческом. 26 исследовательских записей — в 3,25 раза больше восьми, рекомендованных приложением. Несколько записей помечены как старые переходные номера. Расхождение согласуется с явным заявлением документа о том, что реализация остаётся незавершённой.

Документ содержит и числовое расхождение. Сводка «Maximum Allowed» на странице 6 даёт оборонную долю класса C как 458 752, а приложение A на странице 20 печатает 458 725. Разница — 27 идентификаторов.

При использовании цифры со страницы 6 предлагаемые категории класса C дают в сумме:

• 65 536 идентификаторов для исследований;
• 458 752 идентификатора для обороны;
• 1 572 862 идентификатора для коммерческого использования;

итого 2 097 150. Это совпадает с пространством номеров сетей класса C в 2 097 152 значения после резервирования первого и последнего значений.

Если вместо этого использовать напечатанные в приложении A 458 725, получается 2 097 123, то есть на 27 меньше итога со страницы 6. Документ не даёт объяснений. Реконструкция должна сохранять оба напечатанных утверждения, а не молча исправлять одно.

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

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

Рекомендация, соглашение и рабочая практика уместились в одном приложении

Приложение A начинается с сообщения, что в нём обобщены соглашения, достигнутые DDN/PMO и DARPA на встрече в сентябре 1982 года. Затем оно неоднократно использует язык рекомендаций.

Что касается идентификаторов сетей, в повествовании рекомендуется, чтобы назначения для исследовательского, оборонного и коммерческого использования стали ответственностью соответственно DARPA, DCA PCCO/DDN и National Bureau of Standards. Однако числовые таблицы называют ARPA исследовательским назначителем, а для оборонного и коммерческого назначителей печатаютTBD.

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

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

Формулировку о готовности шлюза нужно поместить в эту последовательность. Она говорит, какой «будет политика» в исследовательском сообществе при рекомендуемой договорённости. Это прямое доказательство предлагаемого условия допуска. Но это не прямое доказательство того, что каждая более ранняя запись RFC 790, каждая запись RFC 820 или каждый тип запроса номера уже обрабатывались по этому условию.

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

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

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

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

Считаем опись, не превращая строки в заявителей

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

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

Развёрнутый идентификатор сети— это одно классное значение номера сети, полученное после разворота напечатанного диапазона. Диапазон RFC 820192.001.xxxпо192.004.xxx, например, представляет четыре значения второго октета, умноженные на 256 значений третьего октета, то есть 1 024 идентификатора класса C.

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

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

Таблица класса A в RFC 790 печатает поименованные строки назначений для значений с 001 по 044, за исключением значения 013, которое явно не назначено. Это даёт 43 поименованные строки назначений. Но это не даёт 43 бесспорно назначенных идентификаторов. Строка 044 называет AMPRNET, но следующий сразу за ней неназначенный диапазон тоже начинается с 044 и продолжается до 126. Таким образом, документ даёт 42 однозначных поименованных идентификатора плюс один внутренне конфликтующий идентификатор — 044.

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

RFC 820 приводит на странице 6 напечатанную сводку «Network Totals»:

С учётом напечатанной сводки исследования составляют (1 078 / 1 097), то есть 98,267 %, округлённо 98,3 %. Это результат напечатанной сводки, а не вывод о том, что 98,3 % заявителей или организаций были исследовательскими.

Основной вклад даёт один диапазон, связанный с локальными сетями BBN. Разворот диапазона192.001.xxxпо192.004.xxxдаёт (4 × 256 = 1 024) идентификатора класса C. Эти 1 024 идентификатора составляют (1 024 / 1 097), то есть 93,345 %, округлённо 93,3 %, напечатанного итога назначений RFC.

Этот знаменатель явен: 1 097 развёрнутых назначений, как представлено напечатанной сводкой. Соотношение не означает, что BBN подала 1 024 отдельные заявки, получила 1 024 самостоятельных решения или использовала каждую сеть как внешне маршрутизируемую единицу. Документ связывает диапазон с «локальными сетями BBN», но не объясняет историю запросов или рабочую топологию за ним.

Буквальная дедупликация даёт другой результат. В таблице класса C адрес192.005.022напечатан для BRLNET2, BRLNET3, BRLNET4 и BRLNET5. Названия подсказывают задуманную последовательность, а следующий неназначенный диапазон начинается с 192.005.026, но буквальная реконструкция не может подставить 023, 024 и 025, не пометив это как исправление.

Дедупликация четырёх вхождений192.005.022убирает три дублирующихся вхождения из напечатанного итога класса C:

Поскольку повторяющиеся строки BRL имеют оборонный код, итоги уникальных буквальных категорий становятся такими: 1 078 исследовательских, тринадцать оборонных и три коммерческих, всего 1 094. Число исследовательских остаётся 1 078; число оборонных падает с шестнадцати до тринадцати.

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

Переходные записи добавляют ещё одно усложнение. RFC 820 объясняет, что старые номера могут оставаться в списке с пометкойTдля облегчения изменений. Поэтому сеть может фигурировать под старым идентификатором класса A и под более новым идентификатором класса B, не представляя двух независимо расположенных получателей. Учёт обеих записей может быть верен для операционного признания и неверен для анализа получателей.

Движение между документами всё же видно. RFC 790 содержит поименованные строки только в таблице класса A. RFC 820, согласно своей сводке, содержит смесь из 31 назначения класса A, 24 класса B и 1 042 класса C, а также явные пометки перехода. Некоторые крупные более ранние идентификаторы были заменены, оставлены или временно сохранены, пока появлялись идентификаторы меньших классов.

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

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

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

Что поздние данные о распределении могут и не могут восстановить

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

CAIDA объясняет, что ранняя часть визуализации основана на RFC Assigned Numbers, а более поздние периоды используют данные IANA. Представление работает с гранулярностью /8, помещая меньшие распределения внутрь более крупных адресных блоков, которые их содержат. Отмечается, что выделенное адресное пространство между RFC 790 и RFC 820 сократилось, отчасти потому, что некоторые организации обменяли крупные блоки на меньшие назначения.

Это описание совместимо с пометками перехода RFC 820 и сокращением поименованных записей класса A. Это не независимое подтверждение на уровне получателей, потому что ранняя реконструкция опирается на исследуемый ряд RFC. Публичная последовательность дат идёт с ноября 1977 года по январь 1983 года, а связанные данные Sankey агрегируют потоки по /8. Они не могут независимо восстановить каждый запрос, решение о назначении или переход получателя между RFC 790 и RFC 820.

Более поздние записи реестров создают другие проблемы. В отдельном описании методологии потребления IPv4 CAIDA отмечает, что обновление 1993 года присвоило многим унаследованным распределениям дату августа 1993 года там, где точные более ранние даты были недоступны. Последующие записи могут также наследовать переименования организаций, передачу административной ответственности, исправления и изменения статуса.

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

Таблицы могут поддержать несколько эмпирических выводов без преувеличения:

• RFC 790 печатает 43 поименованные строки назначений класса A, из которых 42 однозначны, а одна конфликтует со следующим неназначенным диапазоном.
• Напечатанная сводка RFC 820 сообщает о 1 097 назначениях, но буквальная дедупликация даёт 1 094 уникальные строки адресов.
• Исследования составляют 98,3 % напечатанного итога, главным образом потому, что один диапазон BBN разворачивается в 1 024 идентификатора класса C с исследовательским кодом.
• Один только диапазон BBN составляет 93,3 % итога напечатанной сводки в 1 097.
• Старые и новые идентификаторы могут сосуществовать, потому что переходные строки сохраняют операционную непрерывность.
• Рабочая таблица пока не соответствует рекомендованным приложением A распределениям категорий.
• Документы не содержат прямого знаменателя для запросов, отказов, отзывов или отклонённых заявок.

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

Текстовый сдвиг допускает четыре объяснения

Переход от RFC 790 к RFC 820 имеет по крайней мере четыре объяснения, возможных для того периода.

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

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

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

Четвёртое — стиль составления. В заголовке изученного RFC 820 указано дополнительное имя — J. Vernon, хотя текущий каталог называет только Postel. Иной процесс составления мог дать более явную институциональную прозу без пропорционального изменения повседневных решений. Расхождение каталога и заголовка делает авторство и редакционную передачу частью неопределённости, а не основанием для приписывания особой политической роли.

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

Различить их могла бы современная переписка. Указатель Computer History Museum называет рабочие блокноты встреч, отчёты NIC о ходе работ, файлы об именах и адресах, хронологическую электронную почту, записи рабочих групп и ежемесячные интернет-отчёты, собранные у подрядчиков. Он указывает, что потенциально релевантная переписка между сотрудниками NIC, пользователями сетей, рабочими группами и федеральными ведомствами сохранилась в архивных коллекциях.

Указатель не раскрывает содержание конкретного запроса по RFC 790, протокол встречи сентября 1982 года или переписку о подготовке приложения A. Он доказывает существование и охват коллекций, но не то, что установили бы нераскрытые записи.

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

Контакты раскрывали ответственность, не определяя цепочку решений

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

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

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

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

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

Более полный реестр был возможен, но не бесплатен

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

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

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

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

Указатель SRI NIC описывает несовместимость носителей, трудности печатного производства и быстро устаревавшие справочные издания в более широком периоде. Поскольку администрирование Assigned Numbers оставалось в USC-ISI до 1987 года, эти свидетельства не могут установить точный производственный процесс или стоимость RFC 790 и RFC 820. Это контекст периода, показывающий, что более богатая документация взаимодействовала бы с реальными техническими и издательскими ограничениями.

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

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

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

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

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

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

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

Федеральная поддержка объясняет возможности, но не каждое правило

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

Правовое заключение Government Accountability Office 2016 годагласит, что функции, позднее объединённые под именем IANA, начались в работе под руководством Postel в UCLA и переехали вместе с ним в USC-ISI в 1977 году. GAO описывает эту работу как выполнявшуюся в рамках исследовательских проектов, финансировавшихся Department of Defense, и продолженную по более поздним контрактам DARPA.

Это более позднее описание согласуется с прямыми упоминаниями DARPA/IPTO, DDN/PMO и встречи сентября 1982 года в RFC 820. Оно помогает объяснить, почему у глобальной технической описи был американский административный центр и почему предлагаемая политика различала исследовательское, оборонное и коммерческое использование.

GAO также сообщает, что не смог получить соответствующие контракты DARPA с 1970-х по 1990-е годы. Его более детальные контрактные свидетельства относятся к более поздним периодам, а его правовой вопрос возник спустя десятилетия после RFC 790 и RFC 820.

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

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

Что в конечном счёте показывают колонки

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

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

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

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

Таблицы также сопротивляются простому распределительному нарративу. Значение 044 в RFC 790 внутренне конфликтно. RFC 820 повторяет один буквальный адрес класса C четыре раза и печатает несовместимые итоги оборонного распределения класса C. Его сводку из 1 097 назначений доминирует диапазон BBN из 1 024 идентификаторов. Переходные записи могут считать одну и ту же сеть и под старым, и под новым номером. Это операционные записи с опознаваемыми редакционными и счётными проблемами, а не чистый набор данных о заявителях.

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

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

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

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

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

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

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