Кратко

  • DRAFT02, представленная AFRINIC 25 сентября 2026 года, допускает, что автоматическая проверка может выявить возможные признаки несоблюдения политики. Сотрудники должны проверить эти сведения до расследования или меры по RSA либо уставу.
  • По сравнению с DRAFT01 изменился смысл автоматического результата: это уже не вывод системы о нарушении, а сигнал для проверки человеком.
  • В карте «политика—тест» должны быть указаны правило, его редакция и дата вступления в силу, охват ресурсов, источник данных и версия проверки — вместе с тем, чего этот сигнал доказать не может.
  • Предложение по-прежнему имеет статус «На обсуждении». В открытых источниках нет свидетельств о работающей панели, уведомлении участника, установленном нарушении или санкции.

Несовпадение в данных ещё не означает нарушения

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

Эта граница проходит через проект панели контроля соблюдения политики AFRINIC, AFPUB-2026-GEN-002-DRAFT02. Версия от 25 сентября предлагает автоматизировать прежде всего то, что можно измерять насколько возможно объективно, и сообщать лишь о возможных признаках несоблюдения. Панель не должна подменять проверку: сотрудники обязаны перепроверить сведения, полученные автоматически. Если данные указывают на нарушение, проект упоминает более подробное расследование и возможные дальнейшие меры по RSA или уставу.

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

DRAFT02 меняет смысл автоматического результата

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

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

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

Версия правила должна сопровождать результат теста

В проекте говорится, что автоматизация должна развиваться вместе с изменениями Сводное руководство по политикам (CPM). Это не только вопрос технического обслуживания. Тест, который вчера правильно отражал правило, после его изменения может неверно классифицировать ресурс или применить новый критерий до даты его вступления в силу. Красный или зелёный статус без ссылки на редакцию скрывает это различие.

В оценке воздействия, приложенной к DRAFT01, перечислены примеры: точность контактных данных, действительность адреса для жалоб на злоупотребления, согласованность объектов маршрутов, покрытие RPKI в подходящих случаях и требования обратного DNS. Это примеры из оценки предыдущей версии, а не окончательный перечень тестов DRAFT02 и не доказательство их внедрения. Они показывают, почему «автоматический» не значит «самообъясняющийся». Отсутствующее поле можно наблюдать напрямую; требовала ли применимая политика заполнить его именно для данного ресурса — отдельный вопрос.

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

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

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

Между данными, сигналом и мерой нужны отдельные этапы

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

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

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

История объясняет редакцию, но не решает судьбу DRAFT02

На AFRINIC-37 24 июня обсуждали DRAFT01. В протоколе сказано, что сопредседатели не установили приблизительного консенсуса и вернули эту редакцию в список рассылки; августовское уведомление повторяет тот же исход. DRAFT02 представили 25 сентября; в истории версий говорится, что она учитывает обсуждение в RPD и оценку воздействия. Июньское решение относится к DRAFT01, а не к текущему варианту.

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

Источники и границы. Текст DRAFT02 и актуальный перечень предложений подтверждают действующую формулировку и статус. Архивная DRAFT01 и её оценка воздействия содержат прежний текст и примеры проверок. Протокол AFRINIC-37 и уведомление сопредседателей от 12 августа фиксируют возврат DRAFT01 в список рассылки. Ни один из этих материалов не доказывает внедрение или результат для конкретного участника.