Кратко

  • Протокол AFRINIC-37 связывает с MyAFRINIC v2 полную реализацию ROA AS0, техническую систему передачи ресурсов и внутреннюю техническую работу по контактам для жалоб; отдельная оценка помещает за портал предложение AS-SET, которое оставалось в Last Call.
  • Это не четыре одинаковых модуля. Три политики ратифицированы, четвёртая — нет; пути проходят через RPKI, процедуры между RIR, внутреннюю проверку, WHOIS и IRR.
  • Доступность портала доказывает состояние платформы, но не активацию правила. Нужен отдельный журнал зависимости и приёмки для каждой политики: точный текст, release baseline, тесты, частичное/полное состояние, время активации, исключение и исправление.
  • Общая основа способна сократить дублирование и расхождения старых систем. Риск возникает, если одно объявление о запуске стирает разницу между Awaiting Implementation, внутренним тестом, частичным исполнением, процедурной подготовкой и отсутствием ратификации.

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

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

Первый путь касается ROA AS0 для нераспределённого и неназначенного адресного пространства. Второй — передачи номерных ресурсов, включая межрегиональные. Третий — проверки контакта для сообщений о злоупотреблениях. Четвёртый — обязательных иерархических имён для вновь создаваемых AS-SET. В проверенном реестре первые три текста ратифицированы, а четвёртый находился в Last Call.

Вопрос поэтому не должен звучать: «вошли ли четыре политики в портал?». Интерфейс, служебная система, процедура и правовое основание — разные объекты. Следует спросить, какой отдельный набор доказательств превращает каждый путь из плановой зависимости в принятое, атрибутируемое и исправимое рабочее состояние.

Общий срок и разная глубина обещания

Протокол AFRINIC-37, заседания 24 июня 2026 года, сообщает: разработка MyAFRINIC v2 началась в 2020 году, затем столкнулась с многолетними бюджетными и иными ресурсными ограничениями, позже была возобновлена. В июне ожидался ввод до конца 2026 года. Чтобы удержать срок, требовалось ограничить объём и избежать scope creep.

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

Страница AFRINIC на AfPIF 2026 описывает MyAFRINIC v2 как полную перестройку портала. До user acceptance testing и live beta AFRINIC искал участников испытаний и собеседований о рабочих процессах. Это доказательство подготовки и приглашения. Оно не подтверждает завершённую UAT, начавшуюся или закончившуюся beta либо production-запуск.

В оценке AS-SET появляется более точная дата — 15 ноября 2026 года. Там сказано, что ресурсы были направлены на MyAFRINIC v2, а реализация предложения получит приоритет после завершения портала. В июньском протоколе стоит более широкое «до конца года». Две формулировки нельзя незаметно объединять. Первая принадлежит конкретной staff assessment, вторая — общему отчёту о статусе.

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

AS0: частичное состояние должно иметь границу

Текущий реестр политик называет AFPUB-2019-GEN-006-DRAFT03, RPKI ROAs for Unallocated and Unassigned AFRINIC Address Space, ратифицированной и Awaiting Implementation. Протокол AFRINIC-37 раскрывает промежуточные состояния. Шло внутреннее тестирование с развитой версией KRILL. К концу месяца ожидалась beta с обозначением partly implemented. Полное исполнение текста зависело от MyAFRINIC v2.

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

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

Будущий акт должен соединить ратифицированный текст, baseline MyAFRINIC v2, соответствующее состояние KRILL, тестовые случаи и наблюдение публикации. Внутренний тест отвечает за логику в контролируемой среде. Он не обязательно подтверждает пользовательские роли, интеграции и долговременное исправление. Partly implemented полезно, только если перечислены наличие, отсутствие и условие выхода.

Передачи: интерфейс не включает вторую организацию

Обзор ратифицированных политик датирует 4 февраля 2026 года ратификацию Number Resources Transfer Policy AFPUB-2020-GEN-006-DRAFT03. Протокол говорит, что она охватывает intra-RIR и inter-RIR transfers, а взаимность с четырьмя другими RIR была подтверждена к апрелю. Member Services сопоставлял процедуры с коллегами; техническая система должна была получить приоритет после MyAFRINIC v2.

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

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

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

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

Abuse contact: принять нужно цепочку событий

Тот же обзор датирует 4 февраля 2026 года Abuse Contact Policy Update AFPUB-2018-GEN-001-DRAFT07. В протоколе указано, что техническая реализация во внутренних системах будет приоритетной после завершения MyAFRINIC v2.

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

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

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

AS-SET: техническая готовность не ратифицирует текст

AFPUB-2026-ASN-001-DRAFT02 в проверенном реестре находилось в Last Call. Ратификация не установлена. Оценка персонала описывает изменения во всех точках создания WHOIS и интерфейсе IRR в MyAFRINIC, чтобы запрещать новые неиерархические AS-SET. Существующие объекты не должны переименовываться.

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

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

Путь Проверенное состояние Связь с MyAFRINIC v2 Недостающее доказательство приёмки
ROA AS0 Ратифицирована; Awaiting Implementation; внутренний тест и ожидаемая частичная beta Полное исполнение текста зависит от портала Объекты, охват, граница частичного/полного, исправление, активация и стабильная публикация
Передачи Ратифицирована 4 февраля 2026 года; процедуры сопоставлялись Техническая система после портала Маршрут и контрагент, end-to-end тест, решение, запись, уведомление и исправление
Abuse contact Ратифицирована 4 февраля 2026 года Внутренняя техника после завершения портала Связь с Draft 7, валидация, уведомление, исправление, исключение и предел последствий
Иерархические AS-SET Предложение в Last Call WHOIS/портал оценены; приоритет после Ратификация, финальный текст, все точки создания, защита и исправление старых объектов

Минимальный журнал зависимости и приёмки

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

Первая группа полей фиксирует полномочие: название, идентификатор, версия и статус. Она предотвращает привязку системы к неправильному draft и удерживает AS-SET в колонке предложения до отдельного акта.

Вторая фиксирует baseline. MyAFRINIC v2 — имя программы, не воспроизводимая версия. Нужен идентификатор выпуска или датированное состояние. Если патч меняет Policy-поведение, возникает новое событие, а не исправленная задним числом приёмка.

Третья классифицирует зависимость: интерфейс, WHOIS, IRR, RPKI, внутренний workflow, миграция данных или процедура внешнего RIR. Она не позволяет зелёному front-end автоматически присвоить завершение непроверенному back-end.

Далее идут предпосылка, ответственный, тест и критерий. Ответственность здесь — способность засвидетельствовать, а не обвинение. Registry Products может подтвердить baseline; Member Services — маршрут; операционная команда — публикацию или проверку; процесс политики — полномочие текста.

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

В конце строка определяет частичное и полное, уведомление и активацию, исключение, rollback, исправление и окно наблюдения. Доступность портала — метрика платформы. Охват AS0, работоспособность маршрута, состояния проверки и единое применение правила — метрики политики.

Разные исключения за одинаковым статусом

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

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

В abuse contact отправка, доставка, ответ и исправление — отдельные события. Технический результат не должен незаметно становиться политическим решением. Для AS-SET до ратификации преждевременная активация была бы проблемой полномочий; после неё ошибкой станет непокрытая точка создания или изменение старого объекта.

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

Почему одного отчёта о релизе недостаточно

Обычная release note отвечает на вопрос, что добавлено в продукт. Для политики этого недостаточно, потому что добавленное поведение может ещё не иметь силы, применяться не ко всем допустимым случаям или зависеть от процедуры, которая находится за пределами продукта. Поэтому один и тот же элемент должен появляться в двух связанных, но разных записях: в техническом составе выпуска и в акте Policy-приёмки.

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

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

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

Наконец, активация и наблюдение должны быть разнесены во времени. То, что правило включено, не доказывает его устойчивую работу. AS0 требует наблюдения публикации, передача — результата каждой включённой категории, abuse contact — прохождения уведомления и исправления, AS-SET — одинакового поведения всех точек создания. Окно наблюдения превращает демонстрацию функции в доказательство процесса.

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

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

Что не доказано

Источники не подтверждают production-запуск MyAFRINIC v2, завершённую UAT или beta, ратификацию AS-SET, полную реализацию AS0, передач или abuse contact. Они не устанавливают простой, пропущенный срок, неудачный тест, отклонённую передачу, недействительный контакт, коллизию AS-SET или эффект маршрутизации RPKI.

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

AFRINIC уже публикует точные слова: Awaiting Implementation, внутренний тест, partly implemented, сопоставление процедур, приоритет после портала, Last Call. Это каркас журнала. Ему нужны версия, тест и исправление.

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

Источники