Приоритет исполняемого кода: необходимый патч для сохранения первоначального замысла Интернета

Семь предыдущих заметок Heng.lu в этой последовательности:

Заметка 52. Когда власть реестра отрывается от ответственности: почему нынешняя модель координации RIR не может существовать в нынешнем виде
Заметка 53. Числовые ресурсы Интернета не являются политической собственностью
Заметка 56. Плотное управление региональными интернет‑реестрами превращает уникальность в двойное извлечение
Заметка 58. От двойного извлечения к инверсии суверенитета: как государства уступают суверенный контроль RIR за 100 долларов США
Заметка 59. Штраф за бедность: как модель RIR облагает бедных налогом, называя это равенством
Заметка 61. Предательство исполняемого кода: как система RIR обернула консенсус против технического сообщества
Заметка 62. Отмывание мандата: от фантазии RIR к переходной архитектуре

Семь предыдущих эссе не были программой реформы региональных интернет‑реестров.

Это была аутопсия.

Они прослеживали одну и ту же институциональную патологию через разные уровни: ответственность, оторванная от последствий; числовые ресурсы, переименованные в политическую собственность; уникальность, превращённая в двойное извлечение; инверсия суверенитета; налогообложение бедности во имя равенства; консенсус, обращённый против сетей, которым он должен был служить; и наконец мандат, отмытый до такой степени, что административная структура стала звучать как суверен. Последовательность важна, потому что провал был не следствием плохого совета директоров, плохого реестра, судебного иска или неудобного рыночного события. Это был системный дефект, проявлявшийся под разными масками. Страница автора CircleID теперь ясно показывает эту последовательность, включая Running-Code Betrayal и Mandate Laundering. (circleid.com)

Это эссе не о том, как сделать RIR лучшими правителями.

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

Это дополнение — Приоритет исполняемого кода (Running-Code Primacy).

Необходимость в нём больше не теоретическая. В недавнем обмене мнениями на CircleID Джон Куран представил наиболее сильную версию позиции действующей системы. Его тезис состоит в том, что власть системы RIR — не просто побочный продукт ограниченной технической координации, а результат исторической цепочки: Белой книги, ICANN, ASO, ICP‑2, передачи надзорных функций в отношении IANA и продолжающегося многостороннего управления со стороны частного сектора. Он утверждает, что власть системы RIR возникла в результате работы в рамках многосторонней модели частного сектора, которую продвигало правительство США. (circleid.com)

Этот аргумент полезен, потому что делает спор видимым.

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

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

Первоначальная интернет‑традиция была уже, жёстче и лучше. RFC 3935 говорит, что цель IETF — «улучшить работу Интернета»; работа основывается на технической компетентности, реальной реализации и «примерном консенсусе и исполняемом коде». Там же сказано: когда IETF не отвечает за протокол или функцию, он не пытается контролировать её. (rfc-editor.org) RFC 7282 повторяет старую фразу Дэвида Кларка: «Мы отвергаем королей, президентов и голосование» и «Мы верим в примерный консенсус и исполняемый код». (rfc-editor.org) RFC 9592 ещё яснее формулирует антисуверенный принцип: IETF не руководит, не контролирует и не патрулирует Интернет и не является «полицией протоколов». (rfc-editor.org)

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

Реестровый уровень заимствовал эту легитимность.

Он никогда полностью не принимал эту дисциплину.

Именно этого патча не хватает.

Что означает приоритет исполняемого кода.

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

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

Он не существует для производства политической власти.

Он не существует для надзора за коммерческой моралью.

Он не существует для превращения географии обслуживания в право собственности.

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

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

Реестр — не государство.

Контакт в базе данных — не нотариальная корпоративная доверенность.

Регион обслуживания — не народ.

Площадка для обсуждения правил — не законодательное собрание.

Реестр может описывать операционную реальность. Он её не создаёт.

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

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

Неправильный порядок таков: обсуждение правил на общей площадке, заявление, заявленное обязательство, ярлык соответствия и принудительное исполнение на практике.

Система RIR провалилась, потому что всё чаще выбирала второй порядок.

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

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

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

Это и есть недостающий существенный патч координации числовых ресурсов.

Дефект проектирования присутствовал с самого начала.

Первая архитектура RIR исходила из мира низкой стоимости.

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

Дефицит IPv4 разрушил эту предпосылку.

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

Институциональная форма не была подстроена под новый риск.

Она расширилась.

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

NRS ясно показывает структурную проблему: числовые интернет‑реестры создавались как органы технической координации, но после того как дефицит IPv4 превратил адреса в ценные активы, усмотрение реестра стало экономической властью; когда координационные системы контролируют капитал, централизация становится структурным риском, а децентрализация — вопросом инженерии систем, а не идеологии. NRS также предлагает противоположное направление проектирования: единый Интернет, открытая автономная инфраструктура и децентрализованное управление с минимальным участием людей в качестве основы. (nrs.help)

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

Приоритет исполняемого кода — такая адаптация.

Это не доктрина «улучшенного RIR».

Это пост‑RIR‑дисциплина.

Три правила патча

Конструктивная грамматика изложена в пересмотренной Заметке 64: Минимальная исходная спецификация, локализованное будущее решение и добровольное принятие для систем интернет‑координации: Минимальная исходная спецификация, локализованное будущее решение и добровольное принятие.

Названия остаются прежними. Логика должна быть точной.

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

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

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

Эти три правила не возвращают суверенитет реестру.

Они не позволяют ему появиться под другим названием.

APNIC: правовая структура была риском

APNIC показывает первый провал: минимум с самого начала не был задан достаточно строго.

Это не история кодексов поведения, этикета или того, был ли критик достаточно вежлив с действующей институцией.

Это история правовой структуры.

В марте 2023 года LARUS опубликовала юридический обзор, предупредив, что структура управления APNIC создаёт риски не только для компании в Брисбене, но и для управления Интернетом во всём Азиатско‑Тихоокеанском регионе. В обзоре утверждалось, что генеральный директор APNIC обладает окончательной юридической властью закрыть APNIC и снять избранный Исполнительный совет, а также что необходимы срочные реформы управления. Отмечалось и то, что структура вызывает сомнения в безопасности управления Интернетом для более чем миллиарда пользователей региона. (larus.net)

Первое приложение, выписка ASIC, даёт корпоративную основу. APNIC Pty Ltd была зарегистрирована как частная австралийская компания с ответственностью, ограниченной акциями, в Квинсленде. Пол Байрон Уилсон значился директором и секретарём. В сведениях об акциях указана одна выпущенная обыкновенная акция, единственным держателем которой являлся Пол Байрон Уилсон. (larus.net)

Это ненормальная форма для размещения критически важной региональной функции интернет‑координации.

Второе приложение, юридическое заключение доктора Питера Фелтера, формулирует вывод об управлении. Публичная структура APNIC — члены, выборы, Исполнительный совет, генеральный директор и секретариат — описывается как специальный комитет, основанный на статье 9.3 устава APNIC Pty Ltd. В заключении сказано, что APNIC Pty Ltd в течение 25 лет была частной компанией, контролируемой одним человеком, занимавшим должности директора и секретаря и являвшимся акционером. (larus.net)

Это различие имеет значение.

Публичный институт, ориентированный на сообщество, не был конечной юридической оболочкой. Это была структура, построенная на частной компании.

Юридическое заключение объясняет последствия. Указывается, что устав APNIC подчинён корпоративному уставу и полномочиям корпорации, её директоров, должностных лиц и членов. При таком толковании публичная структура APNIC могла быть изменена решением директора APNIC Pty Ltd; в заключении APNIC фактически описывается как отдел APNIC Pty Ltd. (larus.net)

Самая серьёзная мысль заключения состояла не в том, что APNIC технически незаконна. Она в том, что законность и легитимность — не одно и то же. Заключение утверждает, что механизм доверительного управления не решает проблему, поскольку полномочия Исполнительного совета по‑прежнему происходят из решения директора, учреждающего специальный комитет. Также отмечается, что APNIC Pty Ltd является частной акционерной компанией, чья структура и цели не соответствуют модели некоммерческой организации без акций, которую обычно связывают с региональным реестром, действующим в общественных интересах. (larus.net)

Это первый дефект проектирования в чистом виде.

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

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

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

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

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

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

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

Реестр не должен быть источником валидности.

Источником должно быть проверенное по исходной спецификации состояние распределённого реестра.

ARIN: политика столкнулась с реальностью активов

ARIN показывает второй провал: право и рынок могут опередить теорию реестра.

Решающим событием стала сделка Nortel/Microsoft. Когда Nortel обанкротился, его 666 624 IPv4‑адреса стали ценными активами в процедуре банкротства. Адреса были проданы Microsoft за 7,5 млн долларов. ARIN вмешалась, исходя из того, что адреса не являются собственностью и не могут продаваться вне политики реестра. Industry Canada поддержала эту позицию. Суд по делам о банкротстве её отверг; позднее Microsoft подписала соглашение о «legacy»; практический результат был ясен: политика реестра не могла оставаться единственным источником реальности, когда суды и рынки относились к числовым ресурсам как к активам. (btw.media)

Важен не вывод о том, что ARIN особенно дефектна.

Важен вывод о том, что реестровый уровень вошёл в новую категорию.

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

После того как IPv4 стал дефицитным, реестровый процесс превратился в интерфейс рынка. Правила передачи, оценки потребности, задержки признания и региональные ограничения перестали быть административными деталями. Они стали препятствиями для операций с активами. Публичный анализ сегодня описывает разрозненный свод правил RIR, в котором пять региональных систем управляют рынком, где цена адреса составляет примерно от 18 до 45 долларов; конфликтующие правила могут замораживать активы, задерживать слияния и заставлять создавать отдельные корпоративные структуры, чтобы сохранять блоки адресов. (btw.media)

Это не нейтральная координация.

Это регуляторный эффект без регуляторной ответственности.

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

Реестр, отрицающий реальность, не становится сувереном.

Он превращается в устаревшую базу данных.

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

Нет реестра, в который нужно мигрировать.

Нет реестра, у которого нужно спрашивать.

Есть только распределённое состояние, которое участники проверяют, принимают, отвергают, разветвляют или с которым взаимодействуют.

AFRINIC: когда теория реестра угрожала работающим активам

AFRINIC — центральный случай, потому что сводит проблему к сути.

Неверная история состоит в том, что проблемный член парализовал региональный реестр.

Это моральный рассказ действующей системы.

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

Факты не требуют театрального преувеличения. Публичные сообщения описывали спор AFRINIC как коммерческий конфликт вокруг IP‑адресов, превратившийся в крупнейшую историю управления Интернетом в Африке. Они также отмечали, что Cloud Innovation часто представляли злодеем, тогда как последующие документальные материалы указывали на разрушительные силы внутри самого AFRINIC и на судебные процессы, которые представители AFRINIC задерживали, затягивали и продолжали за счёт AFRINIC. (btw.media)

Это важно, потому что переворачивает обычный нарратив.

Судебный спор не создал структурный дефект.

Он его обнажил.

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

Тем не менее толкование реестра поместило все эти элементы в рамку отзыва.

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

Сообщалось, что AFRINIC направила Cloud Innovation письмо в марте 2021 года, заявив о нарушениях политик и угрожая прекращением членства; что в июле 2021 года Верховный суд Маврикия запретил AFRINIC отменять членство Cloud Innovation; и что новая попытка отмены была заблокирована в декабре 2021 года. (btw.media) Это не история о том, как реестр спокойно защищал Интернет. Это история о столкновении власти реестра с обычным правом.

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

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

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

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

Но это переходные функции старой архитектуры.

В пост‑RIR‑архитектуре эти функции выполняет не реестр. Они кодируются в состоянии распределённого реестра, правилах доказательства контроля, правилах конфликтов и локально проверяемых переходах.

Частный орган не должен превращать аренду в региональное предательство.

Он не должен превращать географию клиентов в триггер отзыва.

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

Он не должен превращать непрерывность активов в вопрос разрешения.

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

Оператор не может нарушить совместимость других операторов, сдавая адреса в аренду.

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

Он не может нарушить её бизнес‑моделью, которую реестр не одобряет.

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

Эта граница не идеологическая.

Она операционная.

Проблема представительства по доверенности — не деталь

Избирательный спор AFRINIC выявил второй дефект: представительство.

NRS излагает основу своего представительства в прямых юридических терминах. Организация утверждает, что перечисленные члены поручили NRS представлять их в вопросах управления RIR и что каждый такой член выдал нотариальную доверенность (power of attorney). (nrs.help) Во время избирательного спора AFRINIC NRS попросила членов сообщить, фигурировали ли их имена в списках голосования или были ли их голоса зарегистрированы без участия, и указала, что такие фактические сообщения будут рассматриваться юридическими путями. (nrs.help)

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

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

Контакт в базе данных может помогать вести записи.

Нотариальная доверенность может давать право на представительство, если она действительна и представительство не выходит за пределы предоставленных ею полномочий.

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

Участник списка рассылки может выражать мнение.

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

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

Комната — не мандат.

Список рассылки — не народ.

Реестр контактов — не нотариальная корпоративная доверенность.

Регион обслуживания — не суверенный округ.

Это не вопрос процедурной строгости.

Это различие между координацией и нормативной властью.

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

Лучше всего, когда проект системы устраняет проблему управления.

RIPE NCC и LACNIC: клуб и точка удушения

RIPE NCC и LACNIC не доказывают, что некоторые RIR более «цивилизованны», чем другие. Они показывают, что модель RIR имеет два уровня исполнения, выходящих за пределы технической функции: клуб и точку удушения.

Клуб решает, кто достоин уважения. Точка удушения решает, как движется реестровый статус.

Отказ RIPE NCC принять спонсорство LARUS для RIPE 90 ясно показал клубный уровень. Участник предложил спонсорство. Реестровая экосистема отвергла его из‑за несвязанного спора в другом регионе. Это не было решением о безопасности маршрутизации, уникальности или детерминированной валидации. Это была частная форма исключения через контроль доступа к пространствам, видимости, спонсорству и социальной легитимности.

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

Это не сообщество. Это контроль доступа.

Санкционный уровень серьёзнее, поскольку показывает точку удушения в юридической форме. RIPE NCC указывает, что, находясь в Нидерландах, обязана соблюдать санкции ЕС; когда они применяются, реестр замораживает записи в базе RIPE, блокирует приобретения и передачи и может считать дела замороженными, если сторона не предоставляет достаточную документацию. Из‑за банковских требований проводятся также проверки по спискам OFAC. (прозрачность санкций RIPE NCC)

Это не критика RIPE NCC за соблюдение закона. Нидерландская организация обязана соблюдать нидерландское право и право ЕС. Проблема архитектурная: почему частная организация в Нидерландах должна быть центральной точкой признания мобильности числовых ресурсов между множеством стран, операторов и правовых систем?

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

В этом и состоит дефект проектирования.

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

Это напрямую связано с тремя принципами.

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

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

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

Поэтому необходима архитектура распределённого реестра. В пост‑RIR‑системе обычную валидность не определяют RIPE NCC, LACNIC, санкционная комиссия, оргкомитет собрания или офис спонсорства. Участники локально проверяют состояние. Контрагенты добровольно принимают или отклоняют его. Форки видимы. Наборы совместимости явны. Центральный реестр исчезает как источник истины.

Решение — не улучшение этикета.

Это не более прозрачная очередь санкций.

Решение — убрать валидность и из клуба, и из точки удушения.

Распределённое состояние. Локальная валидация. Добровольное принятие контрагентов. Ни одного реестра как источника валидности.

Письмо NRO: путь бегства наверх

Самое серьёзное свидетельство — не попытка AFRINIC выйти за пределы полномочий.

Это коллективный ответ системы.

В 2022 году Number Resource Organization написала правительству Маврикия. В письме NRO описывалась как координационный орган мировых RIR и утверждалось, что RIR управляют числовыми ресурсами в своих регионах. Указывалось, что пять реестров администрируют числовые ресурсы по региональным правилам или единогласно принятым глобальным политикам. (nro.net)

В том же письме критиковался спор Cloud Innovation, утверждалось, что подано более 25 исков, выражалась жалоба на судебные приказы, заморозившие счета AFRINIC и остановившие выборы, и говорилось, что AFRINIC неоднократно просила Маврикий признать её международной организацией. NRO призывала правительство принять меры для сохранения независимости AFRINIC и стабильности Интернета в Африке. (nro.net)

Это самый показательный документ всей истории.

Когда частный реестр вступил в конфликт с обычными судами, реакцией системы стало не сокращение мандата.

Не устранение реестровой блокировки.

Не отделение администрирования реестра от принуждения к соблюдению правил.

Не определение распределённой валидации.

Не постановка вопроса о том, не была ли односторонняя власть снимать с регистрации работающие активы нелегитимной с самого начала.

Реакцией стал путь бегства наверх.

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

Такой набор — не управление.

Это системная форма «отмывания мандата».

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

Это путь к коллапсу.

Приоритет исполняемого кода его отвергает.

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

Меньше суверенитета.

Ни одного реестра как источника валидности.

Меньше принуждения.

Больше распределённой валидации.

Пересмотр ICP‑2 недостаточен

Нынешняя система признаёт, что что‑то сломалось.

Страница публичных комментариев ICANN по второму проекту документа об управлении RIR указывает, что предлагаемый документ устанавливал бы правила и критерии признания новых RIR, операционные обязанности и требования к существующим RIR, а также правила лишения признания; в случае принятия он заменил бы ICP‑2. На той же странице сказано, что процесс начался после просьбы NRO к ASO предложить обновления, которые обеспечили бы системе RIR большую подотчётность перед интернет‑сообществом. (icann.org)

Это может быть необходимо как мера обеспечения непрерывности.

Но этого недостаточно как теории легитимности.

Правила признания и лишения признания отвечают на поздний вопрос: когда реестр провалился настолько, чтобы его удалить?

Более важен предыдущий вопрос: почему реестр вообще должен обладать такой властью, чтобы проваливаться катастрофически?

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

Приоритет исполняемого кода задаёт другой набор вопросов.

Как Интернет продолжит работу, если RIR рухнет?

Как сохранить проверяемость назначений числовых ресурсов без разрешения действующего субъекта?

Как сохранить уникальность без монопольного усмотрения?

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

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

Как сделать координацию пригодной без авторитетного реестра?

Как оператору проверять обычное состояние без обращения к постоянно действующему органу?

Как не превращать отказ в ярлык нарушения?

Это не вопросы реформы.

Это пост‑RIR‑вопросы.

Почему это патч первоначального замысла

Проблема не в том, нравятся ли кому‑то действующие реестры.

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

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

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

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

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

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

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

Что требует пост‑RIR‑координация

Пост‑RIR‑координация не означает хаос.

Она означает, что общий уровень становится тоньше, объективнее, детерминированнее и распределённее нынешней монополии RIR.

Нет реестра, в который нужно мигрировать.

Нет нового реестра, который нужно короновать.

Нет нового жречества.

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

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

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

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

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

Особенно важно правильно понимать переносимость.

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

Без этого каждый реестр является точкой блокировки.

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

Поэтому пост‑RIR‑координация нуждается в четырёх свойствах проектирования.

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

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

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

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

Это не аргумент в пользу пяти более совершенных монополий.

Это аргумент против монополии как источника валидности.

Почему путь отказа предсказуем

Если ничего не изменится, путь отказа ясен.

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

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

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

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

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

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

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

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

Вопрос меняется

Старая система спрашивает: у кого есть мандат?

Это неправильный вопрос.

Лучший вопрос: чего на самом деле требует исполняемый код?

Защищает ли это правило уникальность?

Сохраняет ли оно совместимость?

Устраняет ли оно доказуемое мошенничество при регистрации на основе детерминированных доказательств?

Защищает ли оно безопасность маршрутизации?

Сохраняет ли точность доказательства контроля?

Допускает ли оно локальную валидацию?

Устраняет ли оно зависимость от единственного действующего субъекта?

Описывает ли оно принятое состояние или объявляет непринятое обязательство?

Может ли участник отвергнуть его, не получив ярлыка недействительности?

Может ли участник проверить обычную валидность, не запрашивая состояние у реестра?

Может ли контрагент добровольно принять или отклонить состояние?

Может ли произойти форк без институционального удаления одной из сторон?

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

Это и есть приоритет исполняемого кода.

Для обсуждения

Это предложение предназначено для обсуждения. Это не окончательное решение.

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

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

Проект должен задавать трудные вопросы.

Каковы глобальные инварианты?

Какие правила валидации детерминированы?

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

Какие прежние полномочия реестра являются историческими остатками?

Какие решения относятся к операторам?

Какие решения не требуют представительства, потому что им вообще не следует входить в общий уровень?

Каков путь отказа?

Каков путь форка?

Каков путь локального отклонения?

Как держатель доказывает контроль без действующего реестра?

Как контрагент проверяет состояние без реестра?

Может ли Интернет продолжить работу, если RIR рухнет?

Могут ли числовые ресурсы оставаться уникальными без разрешения действующего субъекта?

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

Может ли процесс разработки правил отличить инвариант исполняемого кода от институциональной воли?

Может ли старый реестровый уровень исчезнуть без потери проверяемого состояния?

Может ли реестр описывать реальность, не становясь её сувереном?

Любой заинтересованный человек может связаться со мной через LinkedIn. Серьёзные исследователи, технические авторы, учреждения или специалисты по политике, желающие помочь превратить это в первый Internet‑Draft и впоследствии в RFC или обсуждение BCP, если сообщество сочтёт это полезным, могут написать мне. LARUS Foundation и я готовы поддержать и финансировать серьёзные исследования в этом направлении.

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

Она спрашивала, кто может говорить в комнате.

Следующая система должна перевернуть этот порядок.

Это не отмывание мандатов.

Это не предательство исполняемого кода.

Приоритет исполняемого кода.

Приложение: Минимальная исходная спецификация, локализованное будущее решение и добровольное принятие для систем интернет‑координации

Заметка 64

Резюме

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

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

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

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

Документ не определяет сетевой протокол (wire protocol). Он устанавливает наилучшие текущие практики (BCP) для проектирования протоколов, систем идентификаторов, распределённых реестров и координационных механизмов, которые не должны превращаться в постоянные институты управления.

1. Введение

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

Обычно это происходит в три шага.

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

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

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

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

Этот документ предлагает другую проектную дисциплину:

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

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

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

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

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

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

2. Область применения

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

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

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

3. Соглашения и определения

3.1. Язык требований

Термины требований, написанные в верхнем регистре, должны толковаться в смысле BCP 14, в частности RFC 2119 и RFC 8174.

3.2. Терминология

Исходная спецификация:
Набор правил, структур данных, форматов, инвариантов, процедур валидации, правил перехода состояния и правил конфликтов, необходимых для первого развёртывания системы.

Общий уровень (Common Layer):
Минимальный набор общих правил или справочная структура, необходимая независимым участникам для взаимодействия. Общий уровень — не учреждение, а техническое содержание, которое участники реализуют и проверяют.

Распределённый реестр (Distributed Ledger):
Реплицируемая или иным образом распределённая запись переходов состояния, позволяющая участникам проверять обычную валидность без зависимости от постоянного реестра, комитета или иного органа. Термин не требует определённого алгоритма консенсуса или реализации.

Детерминированное правило валидации (Deterministic Validation Rule):
Правило, позволяющее участнику посредством локального вычисления или проверки определить, является ли состояние, запись, переход, утверждение или сообщение действительным в рамках заданного набора правил.

Глобальный инвариант (Global Invariant):
Свойство, которое должно сохраняться общим в пределах набора совместимости для защиты уникальности, базовой совместимости, целостности доказательства контроля, общей безопасности или защищённости.

Участник (Participant):
Оператор, реализация, узел, сеть, организация или иной субъект, который исполняет, проверяет, развёртывает систему или зависит от неё.

Набор совместимости (Compatibility Set):
Группа участников, чьи реализованные правила валидации позволяют им взаимодействовать. Последующее изменение может создать новый набор совместимости, если одни участники его принимают, а другие нет.

Принятие (Adoption):
Фактическая реализация, развёртывание, валидация и использование участниками, исполняющими систему.

Принятие контрагента (Counterparty Acceptance):
Добровольное решение участника принять состояние другого участника, проводить сделки, взаимодействовать или доверять ему по правилам валидации, которые он исполняет.

Непринятие (Non-Adoption):
Решение участника не реализовывать или не использовать предлагаемое изменение. Непринятие не создаёт состояния недействительности; оно означает лишь, что участник не вошёл в набор совместимости, созданный изменением.

Локальный отказ (Local Rejection):
Локальное решение участника игнорировать, отклонить или не взаимодействовать с состоянием, сообщением, записью или переходом, недействительным или несовместимым по исполняемым им правилам валидации.

Форк (Fork):
Расхождение правил валидации или операционной практики, создающее два или более набора совместимости.

Координационный артефакт (Coordination Artifact):
Документ, рекомендация, заметка по реализации, профиль, эталонная реализация, обозреватель реестра, реплика или иной артефакт, помогающий участникам координироваться. Координационный артефакт не создаёт обязательной операционной реальности, пока участники не примут его в работающих системах.

4. Постановка проблемы

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

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

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

Во‑вторых, она создаёт двусмысленность между технической валидностью и институциональным признанием.

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

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

Цель этого документа — не лучшая институциональная дискреция. Цель — избежать потребности в ней.

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

5. Принцип 1: Минимальная исходная спецификация

5.1. Формулировка

В исходной спецификации СЛЕДУЕТ определять только минимальные общие детерминированные правила, необходимые для базовой совместимости, уникальности, доказательства контроля, общей безопасности и защищённости.

5.2. Требования

Проект, применяющий этот принцип:

• ДОЛЖЕН явно определить свои глобальные инварианты.
• ДОЛЖЕН определить детерминированные правила валидации для каждого глобального инварианта.
• ДОЛЖЕН определить, как действительное состояние представляется, реплицируется, проверяется и обновляется.
• НЕ ДОЛЖЕН включать правило в исходную спецификацию, если оно не нужно для сохранения заявленного глобального инварианта или первоначального развёртывания.
• ДОЛЖЕН отделять правила валидации от политических предпочтений, коммерческих соглашений, институциональных ролей, управленческих устремлений и дискреционного суждения.
• ДОЛЖЕН позволять участникам локально проверять обычную валидность без запроса информации у учреждения, реестра, комитета, политического органа или иной власти.
• В проекте СЛЕДУЕТ определять структуры данных, подписи, доказательства, правила перехода состояния, правила обработки конфликтов или другие механизмы, необходимые для локальной проверки.
• СЛЕДУЕТ определять сигнализацию расширений, версионирование, маркировку совместимости или идентификацию форков, если будущее разнообразие предсказуемо.
• ДОЛЖЕН обеспечивать переносимость, проверяемость, воспроизводимость и заменяемость необходимых координационных артефактов.
• СЛЕДУЕТ предпочитать машинно проверяемые объективные условия субъективным суждениям о достоинствах.
• НЕ ДОЛЖЕН делать будущее институциональное признание единственным способом узнать, зарегистрировать или использовать действительное состояние.

5.3. Проектные следствия

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

Системе по‑прежнему нужна достаточная общая структура для работы. Дисциплина состоит в различении:

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

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

6. Принцип 2: Локализованное будущее решение

6.1. Формулировка

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

6.2. Требования

Проект, применяющий этот принцип:

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

6.3. Проектные следствия

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

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

Будущее изменение не утверждается централизованно. Его принимают, игнорируют, разветвляют или оставляют участники, исполняющие код.

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

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

7. Принцип 3: Добровольное принятие

7.1. Формулировка

Изменения в системе интернет‑координации СЛЕДУЕТ превращать в операционную реальность через реализацию, валидацию, развёртывание, принятие контрагентами и принятие участниками, а не только через публикацию или заявление.

7.2. Требования

Проект, применяющий этот принцип:

• НЕ ДОЛЖЕН считать публикацию, рекомендацию, одобрение на собраниях или процедурное утверждение достаточными для создания универсальной операционной обязанности.
• ДОЛЖЕН позволять участникам, решившим исполнять новые правила, расширения, профили или процедуры, развёртывать их постепенно.
• ДОЛЖЕН позволять участникам отвергать последующее изменение без приобретения недействительного статуса, если их собственные переходы состояния соответствуют детерминированным правилам их набора совместимости.
• ДОЛЖЕН позволять участникам продолжать использовать прежний набор совместимости, когда исходная спецификация допускает такую непрерывность.
• ДОЛЖЕН позволять участникам одного набора совместимости локально отклонять или игнорировать состояния другого набора, если правила несовместимы.
• СЛЕДУЕТ определять пути принятия важных изменений, включая сигнализацию версий, маркировку совместимости, руководства по переходу и тестовые векторы.
• СЛЕДУЕТ определять пути отказа от важных изменений, включая продолжение работы непринявших участников, идентификацию их набора совместимости и предотвращение неоднозначной совместимости.
• ДОЛЖЕН обеспечивать возможность отказаться от необходимых координационных артефактов, реплицировать, реализовать заново или заменить их без непосильных переходных издержек.
• СЛЕДУЕТ делать так, чтобы реестры, рекомендации и координационные артефакты описывали принятое состояние, а не объявляли существующей непринятую будущую реальность.
• НЕ ДОЛЖЕН проектировать систему, в которой единственный способ сделать изменение реальным — предварительное признание действующим органом.

7.3. Проектные следствия

Добровольное принятие — операционная проверка того, полезно ли изменение, терпимо ли оно и совместимо ли с реальным развёртыванием.

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

Непринятие не создаёт нарушения. Оно создаёт только факт: участник не вошёл в набор совместимости, созданный изменением.

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

8. Связь между тремя принципами

Три принципа усиливают друг друга и неэффективны по отдельности.

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

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

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

Система, принявшая только один или два принципа, может воспроизвести ту же централизацию другими средствами.

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

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

9. Рекомендуемый проектный шаблон

9.1. Детерминированный распределённый общий уровень

Общий уровень СЛЕДУЕТ ограничивать:

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

В общий уровень НЕ СЛЕДУЕТ включать:

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

9.2. Поверхность решений оператора

Следующее СЛЕДУЕТ оставлять вне общего уровня, если только оно прямо не изменяет заявленный глобальный инвариант:

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

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

9.3. Цикл принятия

По возможности предпочтительный порядок существенных изменений системы таков:

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

Координационный артефакт СЛЕДУЕТ создавать после принятия, а не пытаться предвосхитить его.

9.4. Форк, локальный отказ и принятие контрагента

В проекте, соответствующем этому документу, СЛЕДУЕТ рассматривать форк, локальный отказ и принятие контрагентов как нормальные проектные требования, а не как сбои.

В системе СЛЕДУЕТ определить, как участник может:

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

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

10. Применимость и ограничения

Этот проектный шаблон особенно применим, когда:

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

Он может быть менее применим, когда:

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

Даже в этих случаях проектировщикам СЛЕДУЕТ минимизировать общий уровень и по возможности избегать будущего дискреционного контроля.

11. Не является целью

Этот документ:

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

12. Соображения безопасности

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

Поэтому проектировщики, применяющие этот документ, ДОЛЖНЫ явно определить инварианты безопасности. В частности:

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

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

13. Соображения IANA

Этот документ не требует действий со стороны IANA.

14. Ссылки

14.1. Нормативные ссылки

• RFC 2119 — Bradner, S., Ключевые слова для обозначения уровней требований в RFC, BCP 14, RFC 2119.
• RFC 8174 — Leiba, B., Неоднозначность прописных и строчных букв в ключевых словах RFC 2119, BCP 14, RFC 8174.

14.2. Информационные ссылки

• RFC 6709 — Carpenter, B. и B. Aboba, Проектные соображения для расширений протоколов, RFC 6709.
• RFC 7282 — Resnick, P., О консенсусе и гудении в IETF, RFC 7282.

Приложение A. Контрольный список проектирования

Проект, заявляющий о соответствии этому документу, СЛЕДУЕТ строить так, чтобы можно было ясно ответить на следующие вопросы:

• Каковы глобальные инварианты?
• Какие детерминированные правила валидации сохраняют эти глобальные инварианты?
• Какие правила исходной спецификации строго необходимы для первого развёртывания?
• Как представляется и проверяется действительное состояние?
• Является ли состояние распределённым, реплицированным или иным образом независимо проверяемым?
• Какие будущие вопросы намеренно оставлены за пределами общего уровня?
• Какие будущие решения участники могут принимать, не меняя набор совместимости?
• Как участник принимает последующее изменение?
• Как участник отвергает последующее изменение без присвоения ему недействительного статуса?
• Как маркируются или обнаруживаются наборы совместимости?
• Как работает локальный отказ, когда состояние недействительно или несовместимо по исполняемым участником правилам?
• Каков путь форка?
• Как держатель доказывает контроль без действующего реестра?
• Как контрагент проверяет состояние без реестра?
• Могут ли участники проверять обычную валидность без зависимости от действующего реестра?
• Описывают ли реестры и координационные артефакты принятое состояние или пытаются объявить существующей непринятую будущую реальность?
• Минимизировала ли система число решений, встроенных в общий уровень?
• Избегает ли система постоянной власти, определяющей обычное состояние участников?
• Могут ли участники добровольно принимать или отклонять контрагентов?
• Может ли система продолжить работу, если все действующие реестры исчезнут?

Адрес автора

Lu
[TBD]