Приоритет работающего кода: исправление, необходимое для сохранения исходного замысла Интернета

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

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

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

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

Они были вскрытием.

Они прослеживали одну и ту же институциональную патологию на разных уровнях: ответственность, оторванную от последствий; числовые ресурсы, переименованные в политическую собственность; уникальность, превращённую в двойное извлечение ренты; перевёрнутый суверенитет; бедность, обложенную поборами во имя равенства; консенсус, обращённый против сетей, которым он должен был служить; и, наконец, отмывание полномочий, в результате которого конторский служащий заговорил как суверен. Последовательность важна: дело было не в одном плохом правлении, одной плохой регистратуре, одном судебном иске или одном неприятном рыночном событии. Это был системный дефект в разных обличьях. На странице автора в CircleID теперь отчётливо видна эта последовательность, включая «Предательство работающего кода» и «Отмывание полномочий». (circleid.com)

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

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

Это дополнение — приоритет работающего кода.

Необходимость в нём уже не теоретическая. В недавней дискуссии на 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. В заключении утверждалось, что на протяжении 25 лет APNIC Pty Ltd была частной компанией, контролируемой одним директором, одним акционером и одним секретарём — одним и тем же человеком. (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 вмешалась, исходя из того, что адреса не являются собственностью и не могут быть проданы свободными от ограничений правил регистратуры. Министерство промышленности Канады поддержало эту позицию. Суд по делам о банкротстве её отверг; позднее Microsoft подписала соглашение о ранее выделенных ресурсах. Практический результат был ясен: правила регистратуры не могли оставаться единственным источником реальности, когда суды и рынки стали рассматривать числовые ресурсы как активы. (btw.media)

Главный урок не в том, что ARIN была особенно ущербной.

Урок в том, что слой регистратур перешёл в другую категорию.

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

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

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

Это последствия регулирования без ответственности регулятора.

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

Регистратура, отказывающаяся признавать реальность, не становится сувереном.

Она становится устаревшей базой данных.

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

Нет регистратуры, в которую нужно переходить.

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

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

AFRINIC: когда теория регистратуры поставила под угрозу работающие активы

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

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

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

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

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

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

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

Они его вскрыли.

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

И всё же в своих притязаниях регистратура сделала эти вопросы основаниями для отзыва ресурсов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Она эксплуатационная.

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

Спор вокруг выборов AFRINIC выявил второй дефект: представительство.

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

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

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

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

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

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

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

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

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

Собрание — не мандат.

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

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

Регион обслуживания — не суверенное политическое сообщество.

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

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

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

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

RIPE NCC и LACNIC: клуб и узкое горлышко

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

Клуб решает, кто достоин уважения. Узкое горлышко решает, кому доступны изменения регистрационного статуса.

Отказ RIPE NCC принять спонсорство LARUS для RIPE 90 ясно показал клубный слой. Член организации предложил спонсорство. Экосистема вокруг регистратуры его отвергла из-за не связанного с этим спора в другом регионе. Это не было решением о безопасности маршрутизации. Не было решением об уникальности. Не было детерминированным правилом проверки. Это было внесение в частный чёрный список через доступ к конференции. LACNIC также отказалась от моего спонсорства. Другой регион, тот же инстинкт: клуб регистратур защищает себя, контролируя собрания, публичное присутствие, спонсорство, репутацию и общественное признание.

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

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

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

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

В этом ошибка проектирования.

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

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

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

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

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

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

Исправление — не в лучшем этикете.

И не в более прозрачной очереди санкционных проверок.

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

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

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

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

Это коллективная реакция системы.

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

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

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

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

Не устранение зависимости от регистратуры.

Не отделение ведения записей от принуждения.

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

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

Инстинктом было бегство наверх.

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

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

Это отмывание полномочий на уровне всей системы.

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

Это путь к катастрофе.

Приоритет работающего кода его отвергает.

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

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

Никакой регистратуры как источника корректности.

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

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

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

Нынешняя система понимает, что что-то сломалось.

На странице ICANN для публичного обсуждения второго проекта документа об управлении 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

Аннотация

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

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

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

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

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

1. Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Термины требований, написанные в этом документе прописными буквами, следует понимать в смысле, определённом BCP 14, а именно RFC 2119 и RFC 8174.

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

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

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

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

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

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

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

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

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

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

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

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

Форк:
Расхождение в правилах проверки или практике эксплуатации, создающее две или более группы совместимости.

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

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

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

Избыточная детализация исходного слоя имеет три издержки.

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

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

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

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

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

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

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

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

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

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

Архитектура, использующая этот принцип:

1. ДОЛЖНА явно обозначать свои глобальные инварианты.
2. ДОЛЖНА определять детерминированные правила проверки для каждого глобального инварианта.
3. ДОЛЖНА определять, как корректное состояние представляется, реплицируется, проверяется и обновляется.
4. НЕ ДОЛЖНА включать правило в исходную спецификацию, если оно не требуется для сохранения заявленного глобального инварианта или для обеспечения первого развёртывания.
5. ДОЛЖНА отделять правила проверки от предпочтений в отношении правил координации, деловых договорённостей, институциональных ролей, притязаний на управление и дискреционных суждений.
6. ДОЛЖНА позволять участникам локально проверять корректность обычного состояния, не обращаясь ни к какой организации, регистратуре, комитету, органу выработки правил или иной власти.
7. Архитектуре СЛЕДУЕТ определять структуры данных, подписи, доказательства, правила переходов состояния, правила разрешения конфликтов или другие механизмы, необходимые для локальной проверки.
8. Архитектуре СЛЕДУЕТ определять сигнализацию расширений, управление версиями, маркировку совместимости или идентификацию форков там, где можно предвидеть будущие различия.
9. ДОЛЖНА обеспечивать переносимость, проверяемость аудитом, воспроизводимость и заменяемость обязательных вспомогательных средств координации.
10. Архитектуре СЛЕДУЕТ отдавать предпочтение объективным машинно проверяемым условиям перед субъективной оценкой достоинств.
11. НЕ ДОЛЖНА делать будущее институциональное признание единственным способом узнать, зафиксировать или использовать корректное состояние.

5.3. Следствия для проектирования

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

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

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

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

6. Принцип 2: будущие решения на уровне участников

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

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

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

Архитектура, использующая этот принцип:

1. НЕ ДОЛЖНА требовать от участников разрешения действующей организации, регистратуры, комитета, правления, органа выработки правил или иной власти на выбор, который не изменяет детерминированные правила проверки их группы совместимости.
2. НЕ ДОЛЖНА создавать постоянно действующий орган, чьё признание является единственным способом превращения последующего изменения в эксплуатационную реальность.
3. ДОЛЖНА различать корректность по исходной спецификации и совместимость с последующим необязательным изменением.
4. НЕ ДОЛЖНА считать непринятие последующего изменения некорректностью.
5. ДОЛЖНА позволять участникам оставаться в существующей группе совместимости, если они не принимают последующее изменение.
6. ДОЛЖНА позволять участникам присоединяться к новой группе совместимости, принимая новые правила проверки или эксплуатационные профили.
7. ДОЛЖНА позволять участникам локально отклонять состояния, записи, переходы или сообщения, которые некорректны либо несовместимы по применяемым ими правилам проверки.
8. ДОЛЖНА позволять участникам добровольно выбирать контрагентов в соответствии с принимаемыми ими правилами проверки и группами совместимости.
9. НЕ ДОЛЖНА наделять какую-либо организацию, регистратуру, комитет, орган выработки правил или иного субъекта правом объявлять участника некорректным лишь потому, что он отказался от последующего изменения.
10. Архитектуре СЛЕДУЕТ явно обозначать форки, версии, профили или группы совместимости, чтобы участники знали, какие правила они применяют и с какими другими участниками могут взаимодействовать.
11. Архитектуре СЛЕДУЕТ избегать архитектуры, в которой действующий хранитель записей может препятствовать продолжению взаимодействия участников, в остальном удовлетворяющих правилам корректности.

6.3. Следствия для проектирования

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

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

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

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

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

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

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

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

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

Архитектура, использующая этот принцип:

1. НЕ ДОЛЖНА считать публикацию, рекомендацию, одобрение на собрании или процедурное одобрение достаточными для создания универсальной обязанности по эксплуатации.
2. ДОЛЖНА позволять участникам, решившим применять новые правила, расширения, профили или процедуры, внедрять их постепенно.
3. ДОЛЖНА позволять участникам отказываться от последующего изменения без получения некорректного статуса, пока их собственные переходы состояния соответствуют детерминированным правилам проверки их группы совместимости.
4. ДОЛЖНА позволять участникам продолжать использовать прежнюю группу совместимости там, где исходная спецификация допускает такую непрерывность.
5. ДОЛЖНА позволять участникам одной группы совместимости локально отклонять или игнорировать состояние из другой группы совместимости, если правила несовместимы.
6. Архитектуре СЛЕДУЕТ определять способы принятия крупных изменений, включая сигнализацию версий, маркировку совместимости, рекомендации по переходу и тестовые векторы.
7. Архитектуре СЛЕДУЕТ определять способы отказа от крупных изменений, включая то, как не принимающие их участники продолжают работу, обозначают свою группу совместимости и избегают неоднозначности взаимодействия.
8. ДОЛЖНА обеспечивать возможность отказаться от обязательных вспомогательных средств координации, зеркалировать их, реализовать заново или заменить без неподъёмных затрат на переход.
9. Архитектуре СЛЕДУЕТ обеспечивать, чтобы записи, рекомендации и вспомогательные средства координации описывали принятую на практике реальность, а не пытались декларацией вызвать к жизни непринятую будущую реальность.
10. ДОЛЖНА избегать устройства системы, при котором единственный способ сделать изменение реальным — предварительное признание действующим органом.

7.3. Следствия для проектирования

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

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

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

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

8. Связь трёх принципов

Три принципа усиливают друг друга и не работают по отдельности.

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

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

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

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

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

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

9. Рекомендуемая архитектура

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

Общему слою СЛЕДУЕТ ограничиваться следующим:

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

Общему слою НЕ СЛЕДУЕТ содержать:

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

9.2. Область решений оператора

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

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

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

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

Там, где это осуществимо, предпочтительный порядок существенного изменения системы таков:

1. предложение;
2. реализация;
3. тестовые векторы или детерминированный метод проверки;
4. ограниченное развёртывание участниками, готовыми его принять;
5. наблюдение за последствиями для совместимости и защищённости;
6. маркировка группы совместимости;
7. документация или рекомендация, описывающая принятую на практике реальность.

Вспомогательному средству координации СЛЕДУЕТ следовать за принятием, а не пытаться его предрешить.

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. Контрольный список для проектирования

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

1. Каковы глобальные инварианты?
2. Какие детерминированные правила проверки сохраняют эти глобальные инварианты?
3. Какие правила исходной спецификации строго необходимы для первого развёртывания?
4. Как корректное состояние представляется и проверяется?
5. Является ли состояние распределённым, реплицированным или независимо проверяемым иным способом?
6. Какие будущие вопросы намеренно оставлены за пределами общего слоя?
7. Какой будущий выбор участники могут сделать, не изменяя группу совместимости, к которой принадлежат?
8. Как участник принимает последующее изменение?
9. Как участник отказывается от последующего изменения, не получая некорректного статуса?
10. Как группы совместимости обозначаются или обнаруживаются?
11. Как работает локальное отклонение, когда состояние некорректно или несовместимо по правилам, которые применяет участник?
12. Как устроено создание форка?
13. Как держатель подтверждает контроль без действующего хранителя записей?
14. Как контрагент проверяет состояние без регистратуры?
15. Могут ли участники проверять корректность обычного состояния, не полагаясь на действующего хранителя записей?
16. Описывают ли записи и вспомогательные средства координации принятую на практике реальность или пытаются декларацией вызвать к жизни непринятую будущую реальность?
17. Сократила ли система до минимума число решений, встроенных в общий слой?
18. Избежала ли система постоянно действующей власти, определяющей обычный статус участников?
19. Могут ли участники добровольно принимать или отклонять контрагентов?
20. Может ли система продолжить работу, если исчезнут все действующие регистратуры?

Автор: Lu Heng