Угроза ICANN в адрес AFRINIC и отсутствующее правило замены

Кратко

Письма ICANN от июня и июля 2025 года назначенному временному управляющему AFRINIC предупреждали, что может потребоваться проверка соответствия: ICANN связывала предполагаемые нарушения на выборах и проблемы с учетом с обязательствами по ICP-2 и требовала обоснованных ответов. Это было предупреждение о возможном пересмотре признания, а не готовый план замены.
Пробел не только в том, кто может стать аварийным оператором. Вопрос в том, как при чрезвычайной ситуации переходят реестровые услуги, полномочия членов, записи, материалы RPKI, обратный DNS, трансферы, выставление счетов, конфиденциальные данные, споры и судебные ограничения — без ущерба для обычных держателей ресурсов.
Правило замены должно предусматривать четкие триггеры, согласие оператора, объем услуг, депонирование данных, проверку переносимости, публичное уведомление, участие сообщества, сроки, возврат услуг, независимый контроль и отчет после события, прежде чем угроза пересмотра признания превратится в переход услуг.

Угроза без принимающей стороны

Самая важная фраза после отказа реестра — не «реестр находится на проверке». Она должна звучать так: «где завтра будут работать услуги?» Регион может пережить спор в совете директоров, судебный иск, отложенные выборы и даже временного управляющего, если данные о регистрации, служба поддержки, обратный DNS, RPKI, публичные записи, трансферы, выставление счетов и коммуникация с членами остаются стабильными. Ситуация становится хрупкой, когда пересмотр признания упоминается без видимой принимающей стороны для публичной функции.

AFRINIC сделал это различие неизбежным. К июню 2025 года африканский региональный реестр уже несколько лет находился в юридическом и управленческом кризисе. Суды Маврикия назначили временного управляющего. У реестра отсутствовало обычное управление советом. Выборы, призванные восстановить совет, были приостановлены, а затем аннулированы после заявлений, связанных с правом голоса и доверенностями. Затем ICANN обратилась к назначенному управляющему и предупредила AFRINIC, что может потребоваться проверка соответствия.

Это предупреждение не было случайным. Вписьме от 25 июня 2025 годаICANN связала эти заявления с обязательствами по ICP-2, задала тринадцать подробных вопросов, потребовала обоснованный ответ в течение суток, распорядилась сохранить записи и заявила, что ситуация может поставить серьезные вопросы о способности AFRINIC продолжать действовать как организация, способная ответственно управлять номерными ресурсами. Вписьме от 3 июля 2025 годаICANN заявила, что аннулирование выборов не снимает большинства ее вопросов, и снова оставила за собой право начать проверку.

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

Но предупреждение вскрыло и отсутствующее правило замены. Если бы ICANN перешла от предупреждения к официальной проверке и проверка выявила существенное несоответствие, что бы произошло дальше? Лишился бы AFRINIC признания немедленно? Стал бы другой RIR управлять только техническими услугами? Остался бы временный управляющий? Продолжали бы члены платить AFRINIC? Продолжились бы трансферы? Остались бы действительными сертификаты RPKI? Обрабатывались бы изменения обратного DNS? Были бы скопированы конфиденциальные записи временному оператору? Обязали бы этого оператора решения местных судов?

Получили бы держатели ресурсов возможность оспорить ошибочный перенос своих файлов?

Публичного ответа на эти вопросы не было. Пресса тогда зафиксировала риск. The Register 26 июня 2025 года сообщил, что письмо ICANN предупреждало о возможной проверке соответствия и что в случае провала проверки ICANN может попросить другой RIR временно взять на себя функции реестра для Африки. Эта фраза — сильная идея. Но это не процедура. Убедительное правило замены не может быть газетным объяснением возможной экстренной поддержки. Это должен быть документ, который операторы могут исполнить, а члены — проверить.

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

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

Выборный кризис превратил непрерывность в практический вопрос

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

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

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

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

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

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

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

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

NRO признала проблему непрерывности уже при назначении управляющего. В своемзаявлении от 14 сентября 2023 годаона приветствовала назначение управляющего как путь к функциональному управлению и заявила, что это поможет обеспечить членам продолжение реестровых услуг. Это была правильная рамка: сохранить услуги, пока восстанавливается управление. Но затяжной кризис превращает временное сохранение в более трудный вопрос. Если само сохранение не удается, кто берет на себя только те части, которые должны продолжаться?

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

Экстренная услуга — это не преемственное управление

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

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

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

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

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

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

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

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

Согласие оператора нельзя предполагать

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

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

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

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

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

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

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

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

Переносимость записей — ключевой актив

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

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

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

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

Текст ICP-2 2001 года уже признавал ведение записей необходимым. Он требовал надлежащих записей о деятельности реестра и архивной информации, собранной от LIR при выделении адресных пространств, описывая эти данные как необходимые для будущей оценки и возможности аудита ответственных нейтральных операций. Это требование не было написано как полноценное правило переносимости, но оно указывает на ключевую истину: непрерывность реестра зависит от записей, которые можно проверить.

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

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

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

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

Поэтому переносимость записей — ключевой актив замены. Без нее аварийный оператор — только имя. С ней замена становится дисциплинированным актом сохранения, а не политическим актом.

Состояние данных должно перемещаться раньше, чем полномочия

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

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

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

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

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

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

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

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

Членам нужна процедура миграции, а не лозунг

Для членов и держателей ресурсов замена переживается как последовательность практических вопросов. Где мне войти? Кто может подписывать? Засчитывается ли мой счет? Могу ли я обновить контакт для жалоб? Могу ли я изменить делегирование обратного DNS? Действителен ли мой статус RPKI? Может ли завершиться незавершенный трансфер? Переместятся ли мои конфиденциальные документы? Какой закон защищает мои данные? Что делать, если старый реестр и временный оператор дают разные ответы?

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

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

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

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

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

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

Лозунг говорит: «другой RIR может вступиться». Процедура миграции говорит, как каждый член пройдет утро понедельника. Именно это требуется для непрерывности.

Что ICANN может законно требовать

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Оно должно определять сроки и продление. Начальный период в девяносто дней из проекта NRO — полезный ориентир, но продление должно требовать обновленных причин, свидетельств работы, отзывов сообщества и плана возврата или эскалации.

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

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

Правило должно быть достаточно детальным, чтобы работать, и достаточно сдержанным, чтобы не централизовать обычную автономию реестров. Именно этот баланс обнажил AFRINIC.

Обычная зависимость нуждается в собственной защите

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

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

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

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

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

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

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

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

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

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

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

Она должна быть проверена по правилу экстренной аутентификации.

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

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

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

Риск бездействия

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

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

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

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

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

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

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