Резюме

  • Американский институт дипломированных бухгалтеров (AICPA) не получил нынешние полномочия в отношении.CPA лишь потому, что назвал свою заявку 2012 года основанной на сообществе. Его заявка сообщества набрала 11 из 16 баллов при оценке приоритета сообщества (CPE), что ниже порога в 14 баллов. Оценщик не присудил баллы за связь, поскольку строка существенно выходила за пределы сообщества, определённого AICPA, и не присудил балл за правоприменение, поскольку поданная заявка не содержала согласованного и надлежащего механизма апелляции. Запрос о пересмотре 15-17 не пересматривал это решение по существу; он проверял, была ли соблюдена установленная политика или процедура ICANN. В записи о статусе заявки сообщества теперь указано «Отозвана».Отчёт ICANN об оценке приоритета сообщества
  • Действующая цепочка полномочий начинается в другом месте. ICANN и AICPA подписалиБазовое неспонсируемое соглашение о реестре11 июня 2019 года. В подписанном соглашении содержатся обязательства Спецификации 11 для строго регулируемого сектора, но нет приложенной Спецификации 12; в его Спецификации 11 также указано, что пункт об обязательствах из заявки намеренно опущен. Таким образом, текущее право на участие основывается на двух отдельных решениях: компетентные органы определяют, является ли учётная запись юридически действительной, а AICPA решает, какие органы, учётные данные, классы заявителей и правила именования он принимает для.CPA. Механизмы проверки и условия для регистрантов реализуют эту границу в рамках, но не полностью определённых контрактом ICANN.
  • Архитектура апелляций разделена по предмету спора, праву на подачу, срокам и средствам правовой защиты. Специфичная для реестраПолитика разрешения споров о праве на регистрацию.CPA (REDRP)охватывает зарегистрированное имя, которое предположительно нарушало правила выбора имени при регистрации, продолжающееся несоответствие требованиям о праве после регистрации и предположительно неправомерный отказ в регистрации правильно поданной заявки. Первые два пути могут привести к аннулированию, с возможным периодом исправления до 14 дней для продолжающегося соответствия; путь отказа может привести к предписанию разрешить регистрацию, с последующими 30 днями для успешного заявителя на выполнение оставшихся требований. Десятидневный интервал реализации, предусмотренный политикой, прямо ограничен решением, изменяющим статус зарегистрированного имени. Его не следует переносить на случай отказа в регистрации незарегистрированного имени. Приостановка за злоупотребление или безопасность, арбитраж с регистрантом, судебные разбирательства, PICDRP или обеспечение соблюдения, арбитраж между ICANN и реестром и техническая реализация остаются отдельными цепочками.
  • Таким образом, распределение полномочий асимметрично. Государственные лицензирующие органы и юридически признанные профессиональные организации решают, кто может законно позиционировать себя как CPA или эквивалент в их юрисдикциях. Согласно своейполитике приёма регистрантов, AICPA отдельно решает, какие органы, учётные данные и классы заявителей соответствуют требованиям.CPA, и сохраняет за собой право изменять эти правила. Заявители и регистраторы предоставляют данные; реестр или назначенный поставщик проверяет их; регистраторы и системы реестра реализуют статус домена; а пакет политик AICPA сохраняет широкие полномочия по отказу, блокировке, удержанию, передаче, приостановке или аннулированию. Официальные источники, рассмотренные для этой статьи, не установили опубликованного решения REDRP по существу, определения PICDRP, уведомления о соблюдении ICANN, присуждения убытков или судебного предписания о регистрации. Доступ к формальному пересмотру задокументирован; совокупная эффективность средств правовой защиты — нет.

Шесть записей, шесть видов полномочий

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

Первая запись — этозаявка сообщества 2012 года. В ней предлагалось определение сообщества, классы регистрантов, поэтапный доступ, полномочия по правоприменению и постоянный контроль над политикой. Это свидетельство того, что AICPA просил ICANN одобрить. Это не действующий контракт реестра. Вторая запись —отчёт об оценке приоритета сообщества от 3 сентября 2015 года. Он решал, должна ли эта заявка сообщества избежать обычной конкуренции, набрав не менее 14 баллов. Он не решал, кто лицензирован как CPA в какой-либо юрисдикции, и не присуждал реестр другому заявителю.Заявка сообщества AICPA

Третья запись —решение по запросу о пересмотре 15-17. Оно рассматривало, противоречили ли сотрудники ICANN и процесс оценки установленной политике или процедуре. Это не было общим апелляционным пересмотром оценки CPE. Четвёртая —страница статуса заявки сообщества, на которой теперь указано «Отозвана». Этот статус не отменяет задним числом заявку, CPE или запись о пересмотре; он предотвращает рассмотрение этой заявки как продолжающегося юридического источника действующих ограничений реестра.Решение ICANN по запросу о пересмотре 15-17

Пятая запись —подписанное соглашение о реестре 2019 года. Оно создаёт права и обязанности оператора реестра перед ICANN. ICANN классифицирует его как базовое неспонсируемое; в подписанном соглашении содержатся обязательства Спецификации 11 в общественных интересах и механизмы соглашения по соблюдению, спорам и передаче, но нет приложенной Спецификации 12. Шестая запись — пакет политик оператора:Политика приёма регистрантов,Политика разрешения споров о праве на регистрацию,Политика допустимого использования и противодействия злоупотреблениям, страновые условия и руководство по подаче заявок. Эти документы регулируют практические вопросы, с которыми сталкивается заявитель или регистрант.

Столкновение между шестью записями и составляет суть дела. Предложение сообщества говорило на языке пространства имён, управляемого профессией. CPE указала, что предложенная связь и дизайн апелляции не оправдывают приоритет. Пересмотр оставил эту оценку в силе. Позднейший контракт не превратил провалившийся текст сообщества в обязательства Спецификации 12. Затем оператор построил отдельную систему политик и условий для проверки и апелляции. AICPA фигурирует на каждом этапе, но его полномочия не исходят из одного и того же документа на каждом этапе.Отчёт ICANN об оценке приоритета сообщества

Две заявки не означали двух источников полномочий

AICPA подал две заявки на.CPA: заявку сообщества 1-1911-56672 и стандартную заявку 1-1910-48133. В решении о пересмотре указано, что они находились в наборе из шести конкурирующих заявок. Подача двух заявок создала две процедурные позиции, а не два права на управление. Заявка сообщества могла претендовать на приоритет через CPE; стандартная заявка могла остаться в обычной конкуренции. Ни одна из заявок, просто находясь в статусе «Активна», не равнялась соглашению о реестре, изменению корневой зоны или праву продавать имена.Решение ICANN по запросу о пересмотре 15-17

Это различие имело значение после проигрыша в CPE. AICPA утверждал в пересмотре, что заявка сообщества остаётся активной и что запрошенные изменения следует рассмотреть. Комитет по управлению советом трактовал «активна» более узко. Заявки оставались в процессе конкуренции; конкуренцию всё ещё нужно было разрешить, будь то частным образом или через механизм ICANN последней инстанции, прежде чем заключать контракт и делегировать. Формулировка комитета полезна, потому что панели статусов провоцируют чрезмерное толкование. «Активна» описывала право продолжать участие в программе. Это не удостоверяло победу, не одобряло бизнес-модель реестра, не создавало контрактных прав и не помещало.CPA в корневую зону.Решение ICANN по запросу о пересмотре 15-17

Публичные первичные источники, рассмотренные здесь, не устанавливают окончательных частных условий, на которых был разрешён набор из шести конкурирующих заявок. Поэтому они не поддерживают утверждение, что AICPA выиграл конкретный частный аукцион, заплатил конкретную сумму, добился отзывов путём названного урегулирования или победил потому, что другой заявитель принял указанное условие. Позднейшее соглашение о реестре доказывает, что AICPA стал оператором. Само по себе оно не раскрывает каждый юридический или коммерческий шаг, который устранил другие заявки. Этот пробел — не незначительное повествовательное упущение. Частное разрешение конкуренции распределяет экономическую власть, но может оставить общественности только состояния «до» и «после»: несколько заявителей в конкуренции, затем один оператор, заключивший контракт.Решение ICANN по запросу о пересмотре 15-17

Существование отдельной стандартной заявки также блокирует заманчивый ретроспективный аргумент. Фактическое управление AICPA доменом.CPA не доказывает, что заявка сообщества была по существу оправдана. Результат CPE остался проигрышем, пересмотр остался отклонённым, а заявка сообщества теперь отозвана. Позднейшие полномочия оператора должны прослеживаться к подписанному контракту и действующим политикам, а не задним числом приписываться заявке, которая не получила приоритет.Отчёт ICANN об оценке приоритета сообщества

Предложенное сообщество частично было дизайном членства

Заявка сообщества описывала узнаваемый институциональный контингент, но не просто отражала совокупность лиц, юридически уполномоченных использовать «CPA». AICPA определил сообщество через категории, связанные с его собственной организационной структурой. В заявке упоминались действительные члены, ассоциированные члены, международные ассоциированные члены, ассоциированные члены без статуса CPA и аффилированные лица, а также описывалась ирландская связь через Chartered Accountants Ireland. В ней также предусматривались контролируемые этапы, на которых AICPA сам держал регистрации, а позже допускал избранных третьих лиц.Заявка сообщества AICPA

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

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

Это различие также объясняет позднейшую проблему связи. Строка может быть тесно связана с профессией и всё же быть шире, чем сообщество, которое заявитель решил определить. «CPA» может описывать лицензированных профессионалов, не являющихся членами AICPA, а глобальное использование обозначения или признанных эквивалентов не ограничивается организационными границами заявителя. Определённое AICPA сообщество могло быть связным, в то время как строка выходила за его пределы. CPE оценивала это соответствие; она не решала, является ли AICPA легитимной профессиональной организацией.Отчёт ICANN об оценке приоритета сообщества

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

Гарантии GAC ограничили будущего оператора; они не выбрали его

Пекинское коммюнике 2013 годаПравительственного консультативного комитета создало два соответствующих направления гарантий. Категория 1 касалась регулируемых и профессиональных секторов, включая надёжность учётных данных и их действительность после регистрации; Категория 2 касалась ограниченного доступа к общим строкам.Запись о реализации Категории 2ICANN перечисляет обе заявки AICPA. Эти меры определили, что будущий оператор должен будет обещать. Они не выбрали, какой из шести заявителей должен получить строку.

Для строки профессионального сектора гарантии были направлены на надёжность учётных данных и продолжающуюся действительность права на участие.Письмо ICANN профессиональным регуляторам 2017 годаописывало обязательства, требующие соблюдения применимого права, канала отчётности перед регулятором, заверений об учётных данных, консультаций при сомнениях в подлинности и отчётности о существенных изменениях в авторизации. Та же корреспонденция классифицировала.CPA как строго регулируемый сектор или строку с закрытым входом в нескольких юрисдикциях и указывала, что вытекающие обязательства будут помещены в Спецификацию 11.Письмо ICANN о гарантиях от 15 сентября 2017 года

Категория 2 касалась иного риска: заявителя, добивающегося исключительного доступа к общей строке для себя или аффилированных лиц. Запись о реализации идентифицирует обе заявки AICPA в процессе Категории 2. Контрактный ответ содержится в положении Спецификации 11 об общих строках, которое не позволяет ограничивать эксклюзивный доступ к реестру одним лицом или его аффилированными лицами в обстоятельствах, охватываемых этим положением. Это правило ограничило дизайн реестра. Оно не превратило правительственные рекомендации в лицензию на управление.CPA и не сделало регуляторов совладельцами решения о распределении.Запись ICANN о гарантиях Категории 2

Регуляторы могли предоставлять данные об учётных данных, сообщать о злоупотреблениях и влиять на гарантии, но программа по-прежнему отделяла это участие от распределения. Оценщики выставляли баллы CPE, ICANN проверяла процесс, заявители устраняли конкуренцию, ICANN заключала контракт, а IANA обрабатывала делегирование. Опубликованные записи не предоставляют профессиональному регулятору права голоса по отдельной заявке.CPA.Письмо ICANN о гарантиях от 15 сентября 2017 года

Письмо ICANN 2017 года сделало границу средств правовой защиты необычно явной. В нём говорилось, что обязательства Спецификации 11 будут обеспечиваться через Контроль соблюдения контрактов ICANN и могут быть предметом жалобы по Процедуре разрешения споров об обязательствах в общественных интересах (PICDRP). Отдельно в нём говорилось, что Процедура разрешения споров об ограничениях реестра (RRDRP) применялась бы, если бы заявитель сообщества стал оператором реестра. Эта условная формулировка предвосхитила позднейший контракт:.CPA получил обязательства регулируемого сектора, но подписанное соглашение не содержало специфичной для сообщества архитектуры Спецификации 12.Письмо ICANN о гарантиях от 15 сентября 2017 года

CPE проверяла приоритет, а не профессиональную легитимность

Оценка приоритета сообщества предлагала способ для соответствующей заявки сообщества одержать верх над другими заявками на ту же или сходную до степени смешения строку без обычного разрешения конкуренции. Порог был высок: 14 из 16 баллов. AICPA получил 11. Оценщик присудил четыре балла за создание сообщества, ноль за связь между предложенной строкой и определённым сообществом, три за политики регистрации и четыре за поддержку сообщества.Отчёт ICANN об оценке приоритета сообщества

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

Нулевой балл за связь следовал из вывода оценщика о том, что.CPA обозначает лиц за пределами сообщества, определённого AICPA. Сертифицированные бухгалтеры, не являющиеся членами AICPA, и профессионалы, связанные с другими органами, могли быть описаны этой строкой. Поэтому оценщик счёл имя существенно выходящим за предложенную границу сообщества. По правилам оценки это было серьёзно: строка могла быть тесно связана с профессией и всё же не пройти конкретный тест «сообщество-строка», поскольку определение заявителя было уже обычного или международного использования.Отчёт ICANN об оценке приоритета сообщества

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

Позднее AICPA ссылался на механизм апелляции при запросе пересмотра и изменения заявки. Решение о пересмотре отказалось рассматривать позднейшее или предложенное дополнение так, как если бы оно было частью заявки, которую оценивал оценщик. Этот ответ сохранил базовую процедурную дисциплину: оценщики судят по поданной записи в соответствии с правилами программы, а не по улучшенному дизайну, представленному после проигрышного результата. Это также не позволило одному заявителю пересмотреть заявку на приоритет таким образом, который мог бы поставить в невыгодное положение других членов набора конкуренции, после того как они выстроили свои стратегии вокруг существующей заявки.Решение ICANN по запросу о пересмотре 15-17

Последствия CPE были ограниченными, но исполнимыми. AICPA не получил приоритет сообщества. Отчёт не отвергал профессию, не признавал AICPA недействительным, не запрещал.CPA в DNS и не решал окончательного оператора. Он оставил заявку в конкуренции. Это первый повторяющийся урок дела: институциональное значение решения зависит от объекта, которым оно управляет. CPE управляла приоритетом. Она не управляла лицензированием, окончательным соглашением о реестре или делегированием.Отчёт ICANN об оценке приоритета сообщества

Пересмотр предоставил доступ к проверке, а не апелляцию по существу

Запрос о пересмотре 15-17 проверял иной объект. AICPA оспаривал аспекты процесса CPE и обращение сотрудников ICANN с запрошенным изменением заявки. Задача Комитета по управлению советом в соответствии с тогдашним стандартом пересмотра заключалась в определении, противоречило ли действие или бездействие установленной политике или процедуре ICANN. Он не был уполномочен подменять собственную оценку CPE лишь потому, что заявитель оспаривал рассуждения оценщика.Решение ICANN по запросу о пересмотре 15-17

«Проверка» может означать процедурное исправление, проверку законности, возврат на новое рассмотрение или пересмотр по существу. Пересмотр не объединял все эти полномочия. Комитет рассмотрел жалобы AICPA и отклонил запрос; доступ к механизму не гарантировал нового оценщика или оценку.Решение ICANN по запросу о пересмотре 15-17

Комитет также подтвердил отсрочку запрошенного AICPA изменения заявки. Его обоснование связывало процедуру с правами других заявителей. Разрешение существенного изменения после CPE до разрешения спора могло изменить конкурентные условия внутри набора конкуренции. Поэтому решение рассматривало справедливость не просто как право заявителя улучшить свою заявку, а как интерес программы в последовательном применении процедур изменений ко всем соперникам.Решение ICANN по запросу о пересмотре 15-17

Опора AICPA на статус «Активна» не удалась по той же причине, по которой текст заявки нельзя рассматривать как контракт. Комитет пояснил, что активные заявки всё ещё должны были устранить конкуренцию и пройти через заключение контракта и делегирование. Метка статуса была административно значимой — она показывала, что заявка ещё не устранена, — но не создавала права на строку. Публичная страница статуса может раскрывать, где находится дело, без предоставления полномочий, связанных с более поздними этапами.Решение ICANN по запросу о пересмотре 15-17

Отказ в пересмотре оставил результат CPE в силе. Сам по себе он не присуждал.CPA другому заявителю, не требовал от AICPA отказаться от стандартной заявки и не определял частные условия разрешения конкуренции. Он также не устанавливал, что отсутствующий механизм апелляции никогда не может быть создан. Он устанавливал лишь, что этот механизм нельзя задним числом использовать для изменения оценки, выставленной поданной заявке сообщества, через этот путь пересмотра.Решение ICANN по запросу о пересмотре 15-17

Поэтому нынешняя REDRP лучше всего понимается как более поздний операционный ответ на потребность в апелляции по вопросам права на участие, а не как доказательство того, что заявка 2012 года заслуживала потерянный балл CPE. Её текст был внедрён в 2020 году в рамках действующего пакета политик оператора. Теперь она может производить специфичные для домена средства правовой защиты. Она не переписывает историю оценки 2015 года.Политика разрешения споров о праве на регистрацию.CPA

Контракт 2019 года изменил юридический источник полномочий

11 июня 2019 года ICANN и AICPA подписали Соглашение о реестре.CPA. Метаданные ICANN указывают его как «Базовое, неспонсируемое». Метка метаданных — не единственное доказательство, но подписанный документ содержит решающие сопутствующие факты: в нём нет приложенной Спецификации 12 и нет действующего пакета раздела 2.19, основанного на сообществе, регулирующего.CPA.Запись о соглашении о реестре.CPA

Подписанный PDF и доступный для поиска HTML-документ соглашения распределяют несколько уровней власти. AICPA как оператор реестра управляет доменом верхнего уровня в соответствии с соглашением. Регистрации должны осуществляться через аккредитованных ICANN регистраторов, и оператор может устанавливать недискриминационные квалификационные критерии, разумно связанные с надлежащим функционированием TLD. ICANN может проводить аудит соблюдения, расследовать контрактные обязательства, направлять уведомления о нарушениях и использовать механизмы соглашения по устранению, арбитражу и прекращению. Деловые отношения оператора с регистраторами и его поставщик услуг реестра реализуют регистрации, но ни один из них не заменяет ICANN как контрагента по контракту.Подписанное соглашение о реестре.CPA

Спецификация 11 является мостом между гарантиями профессионального сектора и контрактом. Она требует прозрачных политик регистрации, мер против злоупотреблений, соблюдения применимого права, заверений, связанных с учётными данными, каналов отчётности перед регуляторами, консультаций при сомнениях в учётных данных и постоянного уведомления о существенных изменениях. Эти обязательства подлежат принудительному исполнению со стороны ICANN и через рамки PICDRP. Поэтому оператор не может описывать право на участие как полностью частное усмотрение. Некоторые внешние ограничения являются контрактными и могут подвергнуть реестр принудительным мерам на уровне ICANN.Подписанное соглашение о реестре.CPA

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

Подписанная Спецификация 11.CPA содержит ещё один необычно важный сигнал. Пункт 2 — место, где обязательства заявки или бизнес-планы могут стать обязательными, — намеренно опущен. Таким образом, соглашение не делает обещания заявки сообщества 2012 года контрактно исполнимыми через этот пункт. Это упущение подкрепляет необходимость прослеживать каждое текущее правило к контракту, позднейшей политике или применимому праву, а не предполагать, что заявка прошла нетронутой в соглашение.Подписанное соглашение о реестре.CPA

Контракт также не имеет приложенной Спецификации 12.Глобальная поправка 2023 годаделает свою клаузу о сообществе условной: она применяется, если ICANN определила при заключении применимого соглашения, что соглашение касалось TLD на основе сообщества. В этом случае раздел 2.19 и Спецификация 12 требовали бы функционирования в соответствии с политиками регистрации сообщества и подвергали бы существенные отклонения RRDRP. Сама поправка не устанавливает эту предпосылку. Метаданные ICANN по.CPA остаются «Базовое, неспонсируемое», а подписанное соглашение не содержит Спецификации 12. Таким образом, поддерживаемый контрактный вывод заключается в том, что поправка задним числом не преобразовала.CPA в реестр на основе сообщества.Глобальная поправка 2023 года

Эта граница меняет, кто может жаловаться и что может сделать панель. В модели RRDRP устоявшийся институт, связанный с определённым сообществом, может оспорить существенное отклонение от контрактных ограничений регистрации. В фактической структуре.CPA нет Спецификации 12 сообщества, которую можно было бы принудительно исполнить черезрамки RRDRP. Сторона, утверждающая нарушение опубликованных обязательств Спецификации 11, должна обращаться в Контроль соблюдения контрактов ICANN или PICDRP. Лицо, оспаривающее индивидуальное решение о праве на участие, обращается к специфичной для реестра REDRP или другим контрактным и судебным путям. Один и тот же фактический спор может затрагивать более одной системы, но системы не имеют взаимозаменяемых правил правоспособности или средств правовой защиты.Процедура разрешения споров об обязательствах в общественных интересах ICANN

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

Соглашение о реестре было подписано 11 июня 2019 года.Запись о делегировании.CPA в IANAуказывает дату регистрации 11 сентября 2019 года и ссылается на отчёт о делегировании от 21 сентября 2019 года. Эти даты отделяют контракт от технических и административных шагов, которые поместили.CPA в корневую зону. Они также предшествуют публичным этапам подачи заявок в 2020 и 2021 годах.Запись о соглашении о реестре.CPA

База данных корневой зоны IANA называет AICPA «Спонсирующей организацией». Это название поля базы данных корневой зоны; оно не превращает соглашение ICANN в спонсируемый контракт реестра. Метаданные контракта контролируют эту отдельную классификацию и указывают «Базовое, неспонсируемое». Терминология показывает, почему институциональные записи нужно читать по функции. Страница IANA идентифицирует субъект, ответственный за делегированный домен верхнего уровня, и его контакты. Страница соглашения ICANN идентифицирует юридическую форму контракта реестра.Запись о делегировании.CPA в IANA

Делегирование также не открыло пространство имён для каждого правомочного специалиста немедленно. Согласнообъявлению о запускеоператора от сентября 2020 года, лицензированные фирмы могли подавать заявки в течение первоначального периода до 31 октября, с методом распределения на основе логики, проверенным независимой третьей стороной, за которым следовало скользящее распределение. Более позднееуведомление об этапах запускаописывало этап защиты брендов до 31 октября 2020 года, период раннего внедрения с 5 ноября 2020 года по 14 января 2021 года и индивидуальные заявки с 15 января 2021 года.Объявление о запуске CPA.com

Эти этапы распределяли сроки и приоритет среди правомочных пользователей. Они не делегировали полномочия по политике. Фирма, допущенная к подаче заявки в сентябре 2020 года, не получала права голоса по вопросу о том, какие юрисдикции AICPA допустит позже. Независимая третья сторона, проверявшая логику распределения, не становилась регулятором учётных данных. Роль EnCirca, описанная настранице партнёра-регистраторареестра, не давала ей права собственности на правила приёма, а техническая роль поставщика услуг реестра не определяла юридическое значение «CPA». Цепочка запуска была операционной: заявитель, регистратор, процесс проверки, реестр и поставщик услуг реестра. Полномочия по определению цепочки оставались разделёнными между публичным лицензионным правом, контрактом реестра и политиками AICPA.Страница партнёра-регистратора EnCirca

Действующая цепочка приёма начинается с закона, но не заканчивается им

Политика приёма регистрантов, версия 1.0, вступила в силу 13 марта 2020 года. Она признаёт лиц или субъектов, имеющих активную лицензию CPA или эквивалент, выданную национальным, государственным или иным регулятором, одобренным оператором реестра и уполномоченным правительством регулировать, кто может позиционировать себя под этой учётной записью. Она также предусматривает правомочные профессиональные некоммерческие организации. Эта формулировка делает применимое право и компетентных регуляторов незаменимыми, но оставляет второй барьер для AICPA: регулятор и учётная запись должны быть одобрены оператором для целей реестра.Политика приёма регистрантов.CPA

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

Политика требует такую информацию, как юридическое имя, деловое имя, номер лицензии, лицензирующая юрисдикция и срок действия. Она позволяет AICPA или назначенной третьей стороне запрашивать и проверять доказательства.Уведомление о конфиденциальности и проверке для СШАговорит, что CPA.com может собирать информацию от регистраторов, публичных источников, лицензирующих органов, веб-сайтов, работодателей, учебных заведений и агрегаторов данных для проверки права на участие, и определяет EnCirca как возможный источник данных заявки. Эти документы раскрывают сеть доказательств; они не полностью раскрывают, какой поставщик услуг принимает окончательное решение о праве на участие, а какой лишь сообщает о фактическом совпадении.

Оператор остаётся принципалом политики. Он может изменять Политику приёма по своему исключительному усмотрению, публикуя изменения, с указанным 15-дневным периодом до вступления в силу, и политика характеризует аннулирование как единственное средство правовой защиты регистранта при возражении против поправки. Она также сохраняет за собой право отказать или аннулировать, если регистрация нарушила бы закон, санкции или другие установленные ограничения. Лицензирующий орган может сообщить, что учётная запись истекла; поставщик может сообщить, что база данных не совпадает; регистратор может передать запрос на доказательства. Но политики AICPA определяют, что эти факты означают для доступа к реестру и статуса.Политика приёма регистрантов.CPA

Текущееруководство по подаче заявокговорит, что программа доступна в Соединённых Штатах, Канаде и Ирландии, и что отказы могут основываться на праве на участие, выборе имени или географии. Оно описывает доступ для США для лицензированных фирм CPA и индивидуальных держателей лицензий государственных советов и предупреждает, что нелицензированная фирма не может использовать имя, равнозначное незаконному позиционированию. Эта страница является полезным свидетельством программы, как она публично описана на момент публикации. Это не неизменное расписание юрисдикций, и она не идентифицирует каждый одобренный регулятор, базу данных или документальный заменитель.Руководство по подаче заявок.CPA

В Соединённых Штатах публично-правовая опора фрагментирована по государственным советам и другим одобренным органам по учётным данным.Условия для СШАAICPA включают политики приёма и допустимого использования в контракт регистранта и требуют постоянного соответствия. Таким образом, реестр не выдаёт независимо национальную профессиональную лицензию. Он использует государственные или иные одобренные учётные данные как входные данные для отдельного решения о распределении доменов.Условия обслуживания.CPA для США

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

Ирландия более непрозрачна в рассмотренных публичных материалах. Текущее руководство перечисляет Ирландию, а заявка 2012 года ссылалась на Chartered Accountants Ireland, но первичные документы, найденные для этой статьи, не предоставляют полного текущего ирландского определения учётных данных, матрицы регуляторов, списка принятых доказательств или страновой инструкции по апелляции, сравнимых с условиями для США и Канады. Ответственный вывод не в том, что Ирландия не имеет правил. В том, что собранная здесь публичная запись не устанавливает их полной операционной детализации.Заявка сообщества AICPA

Карта средств правовой защиты имеет отдельные маршруты для отдельных институциональных объектов

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

Неправомерный отказ до регистрации

Пункт 3.3 REDRP касается узкого утверждения: оператор реестра не разрешил регистрацию доменного имени, которое было правильно подано в соответствии с Политикой приёма регистрантов. Он не говорит, что каждый спор о выборе имени или географии автоматически является иском о неправомерном отказе. Заявитель несёт бремя доказывания по стандарту перевеса доказательств, предусмотренному политикой, и должен представить применимую Политику приёма и указанную причину отказа.Страница споров, специфичных для реестра, FORUMидентифицирует поставщика, через которого администрируется политика.Политика разрешения споров о праве на регистрацию.CPA

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

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

Различие во времени важно. Пункт 5.5 говорит, что регистратор или реестр ждёт десять рабочих дней только если решение панели требует изменения статусазарегистрированногоимени. Дело о неправомерном отказе касается незарегистрированного имени. Таким образом, рассмотренный здесь текст REDRP не устанавливает автоматической десятидневной приостановки реализации для этого средства защиты от отказа. Политика позволяет любой стороне инициировать параллельные административные или судебные разбирательства, и панель может приостановить или прекратить дело REDRP в пользу другого разбирательства. Этот общий доступ к суду не следует переписывать как конкретную десятидневную приостановку, которую политика привязывает только к изменениям статуса зарегистрированных имён.Политика разрешения споров о праве на регистрацию.CPA

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

Зарегистрированное имя предположительно нарушало ограничения выбора имени с самого начала

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

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

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

Регистрант позже перестаёт удовлетворять продолжающемуся праву на участие

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

Язык средства защиты позволяет панели предоставить до 14 дней для приведения регистрации в соответствие и представления доказательств продолжающегося права, а также допускает аннулирование и возврат имени в пул. Текст не является общим правом на 14 дней в каждом случае; он даёт панели усмотрение в пределах этого лимита. Зарегистрированный держатель получает период ответа REDRP, имя блокируется, пока дело находится на рассмотрении, а приказ об аннулировании подлежит десятидневному интервалу реализации для зарегистрированного имени и указанной приостановке при предоставлении судебных документов.Политика разрешения споров о праве на регистрацию.CPA

Операционный риск заключается в передаче между системами. Публичный совет может изменить статус лицензии до того, как реестр узнает об этом. База данных может отставать от восстановления. Имена могут не совпадать в разных записях. Политика допустимого использования требует от регистранта уведомить реестр в течение одного рабочего дня об определённых действиях регулятора или отзыве лицензии, в то время как Спецификация 11 предусматривает каналы отчётности и консультаций. Однако публичные источники не раскрывают совокупные данные о времени до обнаружения, ложных срабатываниях, исправлениях, аннулированиях, отменах или восстановлениях. Формальные полномочия действовать задокументированы; частота и точность действий — нет.Политика допустимого использования и противодействия злоупотреблениям.CPA

Приостановка за злоупотребление, безопасность, оплату или более широкий контрактный риск

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

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

Условия для США предусматривают неформальную эскалацию к высшему руководству, за которой для охватываемых споров следует обязательный арбитраж в соответствии с указанной структурой Американской арбитражной ассоциации. Они содержат положения о применимом праве, форуме и ответственности. Канадские условия изменяют контрактную позицию, включая исключения для потребителей Квебека. Эти маршруты могут обеспечить контрактные средства защиты в рамках регулирующих условий и права, но они не являются заменой приказа REDRP, прямо разрешающего регистрацию, и не дают истцу доступа к отдельному контрактному арбитражу ICANN с AICPA.Условия обслуживания.CPA для СШАКанадские условия обслуживания.CPA

PICDRP и Контроль соблюдения контрактов ICANN

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

Средство защиты PICDRP соответственно институционально. Если панель находит несоблюдение, ICANN выпускает уведомление о правоприменении, и у оператора есть 30 дней для его устранения; если нарушение остаётся, ICANN определяет дальнейшую меру исправления в соответствии с Соглашением о реестре. Податель отчёта не получает автоматический приказ о регистрации конкретного имени лишь потому, что жалоба прошла предварительную проверку. Процесс может проверить, поддерживал ли реестр и внедрял ли требуемые гарантии, в то время как REDRP может решать указанные споры на уровне имён в рамках своей политики. Один набор фактов может поддерживать оба вопроса, но успех в одном маршруте не устанавливает правоспособность и не диктует средство защиты в другом.Процедура разрешения споров об обязательствах в общественных интересах

Публичная страница PICDRP ICANN перечисляет отчёты панелей для.FEEDBACK и.PHARMACY, но не для.CPA, и запись.CPA не была обнаружена на страницеформальных уведомлений о правопримененииICANN. Это отсутствие не устанавливает идеальное соблюдение, отсутствие отчётов или отсутствие частных исправлений. Оно устанавливает лишь, что рассмотренная здесь публичная запись не показывает спора о гарантиях.CPA, достигшего опубликованного решения по существу или формального уведомления о правоприменении.Страница PICDRP ICANN

Медиация и арбитраж между ICANN и реестром

Положение о спорах Соглашения о реестре двустороннее. Спор, возникающий из этого соглашения или в связи с ним, сначала подлежит медиации между ICANN и оператором реестра, а если он не разрешён, может перейти в обязательный арбитраж ICC. Соглашение допускает запросы о конкретном исполнении и, в определённых обстоятельствах, операционные санкции. Этот маршрут защищает контрактное распределение между ICANN и AICPA. Это не апелляция регистранта и не делает отклонённого заявителя стороной Соглашения о реестре.Подписанное соглашение о реестре.CPA

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

Суды, параллельные разбирательства и техническая реализация

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

Техническая реализация — последнее звено, а не ещё один апелляционный орган. Регистратор и реестр исполняют регистрацию или изменения статуса домена, предписанные через применимый маршрут. Роль IANA в корневой зоне касается делегирования и, если требуется по Соглашению о реестре, передачи домена верхнего уровня; она не решает, заслуживает ли индивидуальный заявитель второуровневое имя.CPA. Прекращение контракта, экстренная передача и изменения базы данных IANA действуют на уровне TLD. Удержание, аннулирование или регистрация на уровне регистранта реализуются внутри цепочки реестра и регистратора.Подписанное соглашение о реестре.CPA

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

Что доказывает публичная запись — и чего она не доказывает

Цепочка высокой уверенности документальна. AICPA подал и заявку сообщества, и стандартную заявку. Заявка сообщества прошла CPE и получила 11 баллов, ниже порога. Оценщик нашёл проблему связи и неадекватный дизайн апелляции. Пересмотр не предоставил переоценку по существу и был отклонён. Заявка сообщества теперь помечена как «Отозвана». AICPA позже подписал Базовое неспонсируемое соглашение о реестре. Это соглашение включает Спецификацию 11, опускает обязательства заявки в пункте 2 Спецификации 11 и не имеет приложенной Спецификации 12. IANA фиксирует позднейшее вхождение в корневую зону. Политики оператора ввели чувствительную к юрисдикции проверку, широкие полномочия правоприменения и REDRP с доменно-специфичными средствами защиты.Решение ICANN по запросу о пересмотре 15-17

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

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

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

Ограниченный ответ: кто решает, кто является CPA онлайн?

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

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

Панели FORUM могут исправлять определённые нарушения REDRP и предписывать средства защиты домена. Арбитраж регистранта и суды могут решать иски в рамках своих контрактов и юрисдикции. ICANN может проводить аудит и принудительно исполнять Спецификацию 11, добиваться контрактных средств защиты и, если сам TLD должен быть передан, использовать механизмы непрерывности Соглашения о реестре и корневой зоны. Эти полномочия затрагивают одно и то же пространство имён, но не взаимозаменяемы.

Провалившаяся заявка сообщества важна, потому что она идентифицирует архитектуру, которая так и не вступила в силу. Нынешние ограничения не вытекают из успешной CPE или спецификации сообщества Спецификации 12. Позднейшая REDRP отвечает на часть проблемы дизайна апелляции, выявленной в 2015 году, но из другого источника полномочий: Базового неспонсируемого контракта плюс политик оператора и условий регистранта.Отчёт ICANN об оценке приоритета сообщества

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

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