Резюме

  • История изменений AFRINIC указывает, что в версии 3 документа AFPUB-2019-V4-003-DRAFT03 были изменены только разделы 5.7.3.2 и 5.7.4.3. В поле Details архива датой подачи указано 22 сентября 2020 года, тогда как история изменений датирует версию 3 21 сентября; доступная запись не разрешает это расхождение в один день.
  • Первое изменение заменило немедленное право источника на дальнейшие распределения или выделения IPv4-адресов AFRINIC из редакции 2 на двенадцатимесячную невозможность их получения после одобренного переноса. Второе отменило правило редакции 2 об утрате легаси-статуса, поэтому переданные легаси-ресурсы оставались бы легаси.
  • В редакции 3 сохранилась более глубокая проблема совместимости. Её правило для источника по-прежнему ссылалось на соблюдение политик принимающего RIR, а процедура по-прежнему направляла передающую сторону в принимающий RIR. Эти положения пересекали институциональные отношения: реестр просили оценивать иностранный источник, который он не обслуживает, а этот источник отправляли в реестр, с которым у него могло не быть соглашения.
  • Оценка сотрудников AFRINIC от 13 октября 2020 года зафиксировала существенные возражения о несовместимости со стороны всех четырёх обсуждавшихся реестров-контрагентов: ARIN, APNIC, LACNIC и RIPE NCC. Сотрудники объяснили обычное разделение работы проще: каждый RIR работает со стороной из своего региона, а реестры взаимодействуют друг с другом.
  • Поэтому наиболее обоснованная взаимная конструкция является узкой. Реестр-источник проверяет источник и ресурс; принимающий реестр проверяет получателя; реестры обмениваются аутентифицированными подтверждениями, выбирают единый момент вступления в силу и согласованно обновляют свои служебные записи. Это защищает уникальность и непрерывность, не создавая юрисдикции иностранного реестра.
  • Оба изменения редакции 3 имели правдоподобные цели. Период ожидания мог препятствовать немедленному повторному использованию бесплатно выделенного пространства, а сохранение легаси-статуса могло избежать автоматического наказания за статус. Но ни одна из целей не доказывает, что взаимная процедура работала, а доступная запись не подтверждает ни принятия, ни внедрения, ни завершённой сделки, ни ценового эффекта, ни реализованного изменения членства.

Небольшая правка с серьёзным институциональным испытанием

Номера версий могут создавать обманчивое ощущение движения вперёд. Новый проект появляется после публичной встречи; пункты перемещены; возражения услышаны; история изменений фиксирует перемены. Возникает соблазн прочитать эту последовательность как постепенное решение проблемы. AFPUB-2019-V4-003-DRAFT03 не подтверждает эту простую историю. Его значение состоит именно в разрыве между тем, что изменилось, и тем, что осталось.

Предложение было попыткой дополнить раздел 5.7 Сводного руководства по политикам AFRINIC (CPM) взаимным маршрутом меж-RIR переноса IPv4-адресов. Архив AFRINIC называет авторами Anthony Ikechukwu Ubah и Taiwo Oyewande. Редакция 1 была подана 30 октября 2019 года. Редакция 2 последовала 13 августа 2020 года. AFRINIC-32 рассмотрел редакцию 2 16 и 17 сентября, и протокол встречи сохранил плотный блок вопросов о взаимности, праве источника, потребности получателя, легаси-ресурсах, спорном адресном пространстве и предложенной процедуре контакта.

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

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

Даже дата версии 3 требует точности. В поле Details архива указано, что документ подан 22 сентября 2020 года. История изменений датирует версию 3 21 сентября. Нет оснований молча выбирать одну дату и отбрасывать другую. Ответственный вывод: официальная страница сохраняет расхождение в один день, а не одну бесспорно верную дату.

История изменений гораздо яснее по существу. В ней сказано, что редакция 3 изменила только разделы 5.7.3.2 и 5.7.4.3. Слово «только» несёт аналитическую нагрузку всего эпизода. Соответствие источника в разделе 5.7.3.1 и потребность входящего получателя в разделе 5.7.4.1 были изменены ещё в редакции 2. Они остались частью текста версии 3, но не были правками версии 3. Любое описание этих положений как нововведений редакции 3 превратило бы унаследованную архитектуру в новый ответ и скрыло бы, почему дефект совместимости сохранился.

Первое изменение: двенадцатимесячная пауза для источника

Предложенный в редакции 2 раздел 5.7.3.2 позволял источнику сохранять право на дальнейшие распределения или выделения IPv4-адресов AFRINIC, пока он соблюдает действующую политику. Редакция 3 заменила это положение двенадцатимесячным периодом невозможности получения ресурсов после одобренного переноса. Практически организация, передающая ресурсы, не могла сразу вернуться в службу распределения AFRINIC за новым IPv4-пространством.

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

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

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

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

Второе изменение: легаси-статус переживает перенос

Предложенный в редакции 2 раздел 5.7.4.3 говорил, что переданные легаси-ресурсы IPv4 перестанут быть легаси. Редакция 3 отменила это последствие: переданные легаси-ресурсы останутся легаси. Это было прямое и понятное изменение статуса. Вместо того чтобы делать перенос событием, автоматически гасящим историческую классификацию, новый текст сохранял эту классификацию на протяжении сделки.

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

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

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

Положения, которые выжили

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

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

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

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

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

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

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

Октябрьский вердикт о совместимости

Официальная страница редакции 3 AFRINIC содержит оценку сотрудников от 13 октября 2020 года. Эта оценка даёт самый ясный тест того, сделали ли две правки взаимный мост работоспособным. Записанный там ответ не был тонким разногласием о вкусах в drafting. Сотрудники сообщили о существенных возражениях о несовместимости от ARIN, APNIC, LACNIC и RIPE NCC.

ARIN и APNIC сочли положение о соответствии источника несовместимым. LACNIC заявил, что его политика не требует от источника соответствия другому RIR. RIPE NCC счёл процедуру начала в разделе 5.7.5 несовместимой и нереализуемой. Детали различались, но общая структура была очевидна: процедуры контрагентов не возлагали межрегиональную проверку и первый контакт так, как ожидала редакция 3.

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

Оценка также указала работу по внедрению в MyAFRINIC, обратном DNS, ROA RPKI, журналах переносов и тикетах, а также пересмотр процессов, меж-RIR координацию, контракты, персонал и программную инженерию. Это не декоративные административные детали. Это системы, через которые признанный контроль и операционная непрерывность должны были оставаться согласованными. Политическое предложение могло объявить взаимность, но завершение сделки требовало согласованного изменения нескольких записей и служб.

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

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