Кратко

  • 12 августа 2018 года проект 1 обновления политики контактных данных (Abuse Contact Policy Update Draft 1) предлагал сделать обязательным контактabuse-cдля непосредственно выделенных записейinetnum,inet6numиaut-num, заменив более ранний порядок, в котором использование отдельного контактного объекта на основе IRT поощрялось, но оставалось необязательным.
  • Процедура проверки отправляла URL и код в двух последовательных текстовых письмах, давала контакту два рабочих дня на прохождение подтверждения с CAPTCHA, а затем предоставляла LIR ещё три рабочих дня до наступления постоянной недействительности; ещё одна неудачная проверка могла стать нарушением политики с последствиями, связанными с отзывом ресурсов.
  • Реестр может требовать один доступный ролевой почтовый ящик и проверять объективную доставляемость. Он не вправе использовать эту запись, чтобы диктовать фильтры, формы, ручную обработку, меры или ответы, поскольку AFRINIC — частный технический регистратор, а не регулятор в сфере злоупотреблений и не публичный орган.

L3 — Пятидневная машина проверки

Механизм начинался с двух последовательных текстовых писем. Первое содержало URL для проверки. Второе — уникальный код. Человек, контролирующий предлагаемый почтовый ящикabuse-c, должен был не позднее чем через два рабочих дня открыть защищённую CAPTCHA-форму, вставить код и отметить подтверждение. Этот флажок не просто означал, что на адрес можно получать почту. Он требовал подтвердить, что ящик регулярно контролируется, что принимаются меры и что на жалобу о злоупотреблении поступает ответ. Если код не использовали, контакт становился временно недействительным, и сотрудники AFRINIC связывались с местным интернет-реестром (LIR). У члена организации было не более трёх дополнительных рабочих дней, чтобы исправить проблему. Если по истечении этого второго окна проблема не была устранена, контакт становился постоянно недействительным. Последующий сбой проверки мог рассматриваться как нарушение политики с более тщательными мерами, особенно в рамках процедур, касающихся отзыва ресурсов.

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

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

Предложение называлось Abuse Contact Policy Update Draft 1 и было обозначено какAFPUB-2018-GEN-001-DRAFT01. Jordi Palet Martinez подал его 12 августа 2018 года для замены раздела 8.0 Сводного руководства по политике AFRINIC. Это было обсуждаемое предложение, а не действующее правило. Этот статус принципиален. Документ фиксирует попытку институционального проектирования; он не доказывает, что первая редакция была принята, реализована или применена к какому-либо члену организации.

Отправной точкой был не пустой каталог. У AFRINIC уже был порядок работы с abuse-контактами, разработанный в 2011 году и, как сообщалось, внедрённый в 2012-м. Он использовал специальный объект на основе IRT для публикации контактной информации об abuse. Записи ресурсов, такие какinetnum,inet6numиaut-num, могли ссылаться на этот объект, но ссылка была необязательной. Членов поощряли публиковать информацию как надлежащую практику. Слабость была очевидна: поощрение могло оставить непосредственно выделенный ресурс без понятного, актуального и единообразного отдела по работе с жалобами. Обратившийся мог искать по нескольким записям, писать на общий административный адрес или угадывать ответственного оператора. Почтовый ящик, сохранённый только в устаревшем объекте, мог вообще не принимать сообщения.

Проект 1 предлагал гораздо более жёсткое правило каталога. Каждый номерной ресурс, выделенный напрямую AFRINIC, должен был включать контактabuse-cв соответствующую записьinetnum,inet6numилиaut-numв WHOIS. По крайней мере один связанный abuse-почтовый ящик должен был быть действительным, контролируемым и активно управляемым. Дочерним объектам не обязательно требовался отдельный укомплектованный отдел: они могли наследовать контакт родительской записи или публиковать собственный. Адрес должен был оставаться свободно доступным через WHOIS, интерфейсы приложений и любые дальнейшие способы доступа. На этом уровне предложение устраняло реальный дефект публичных данных реестра. Общее поле делает точку контакта читаемой. Наследование сокращает дублирование. Объективная проверка может выявить мёртвую ролевую учётную запись до того, как реальный инцидент сделает сбой дорогостоящим.

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

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

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

Разделы 8.2–8.7 совместно выстраивали переход. Правило публикации давало обязательное поле. Требования к доступности и обработке предписывали путь, по которому могут поступать жалобы. Положения о проверке задавали ритм и подтверждение. Положения о сроках превращали задержку во временную, а затем постоянную недействительность. Положения об эскалации вводили посредничество AFRINIC. Язык о несоблюдении связывал повторяющиеся сбои с нарушением и процедурами, которые могут дойти до отзыва. Это были не взаимозаменяемые детали. Уберите поведенческие и карательные слои — и каталог всё равно станет полезнее.

Уберите поле контакта — и никакие формулировки об обеспечении соблюдения не подскажут обратившемуся, куда писать.

Опубликованная в тот же день оценка персонала помогает понять, как институция понимала текст. Сотрудники прочитали Проект 1 как делающийabuse-cобязательным для непосредственно выделенных объектовinetnum,inet6numиaut-num, с сохранением выбора для дочерних записей. Они понимали, что проверки проводятся при создании и не реже одного раза в квартал, и рассматривали неудачную проверку как нарушение политики, подпадающее под обычные меры. Персонал оценил минимум в полтора месяца на разработку, тестирование и развёртывание. В оценке не зафиксировано комментариев юрисконсульта. Само по себе это отсутствие не решает вопрос о действительности предложения, но оно значимо для проектной записи: механизм, способный поднимать дефект контакта до процедур, связанных с отзывом, оценивался операционно без задокументированного юридического анализа принудительной юрисдикции.

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

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

Этот безобидный сценарий поддерживает обязательный контакт, но не остальную часть машины. Объективная доставляемость задаёт ограниченный вопрос: может ли сообщение достичь указанного ролевого адреса? Проект 1 задавал другой набор вопросов. Позволяет ли оператор предпочтительный канал ввода реестра? Приемлема ли его политика фильтрации? Вмешается ли человек вручную? Принимает ли оператор «меры» и что требует это слово? Должен ли каждый отчёт получать ответ, даже если он дубликат, оскорбителен, автоматизирован, с некорректным форматом или необоснован? Это решения о проектировании и достаточности операционной системы реагирования.

Их нельзя вывести из корректности записи реестра.

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

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

Жизненный цикл после 12 августа подтверждает, что эти ставки были осознаны, но его нельзя проецировать назад на Проект 1. Проект 2 появился 20 ноября 2018 года. На AFRINIC-29 в конце того же месяца участники спорили о подтверждённых контактах, ограничениях в MyAFRINIC, влиянии на голосование, наказаниях и о том, не берёт ли AFRINIC на себя функцию «интернет-полиции». Сопредседатели не зафиксировали консенсуса и вернули предложение на доработку. В годовом отчёте AFRINIC за 2018 год позднее описывались обязательныйabuse-c, проверка и карательные меры, включая ограничения, затрагивающие доступ к порталу и голосованию. Эти записи — контекст более позднего этапа, после появления Проекта 2; они не являются дословным содержанием или юридическим эффектом документа от 12 августа.

Нельзя также включать Проект 7 в Проект 1. В реестре версий числятся семь проектов, седьмой был подан 17 мая 2021 года. Актуальные материалы на дату отсечения доказательств описывают эту более позднюю версию как ратифицированную. Любые формулировки, процессы, апелляции или позднейший статус Проекта 7 принадлежат его собственной истории. Они не могут сделать Проект 1 ретроактивно действующим, восполнить отсутствующую в первом тексте юридическую силу или доказать, что исходный пятидневный механизм привёл к фактическому отзыву. Точным объектом анализа остаётся первое предложение и институциональная линия, которую оно впервые попыталось провести.

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

Второй начинает отвечать на вопрос «вёл ли себя оператор сети приемлемо?». У реестра номерных ресурсов есть записи, необходимые для ответа на первый вопрос. У него нет ни фактов, ни публичной власти, необходимых для ответа на второй.