Резюме

  • .NGO и.ONG стали «проверенными» не благодаря одному лишь брендингу. Реальная сила исходила из двух соглашений о реестре, Спецификации 12, процесса оценки услуг реестра (RSEP) ICANN, одобрения Совета директоров, договорных поправок и соглашения реестра с регистраторами, которое встроило сбор доказательств и исполнение жизненного цикла в процессы регистраторов.
  • Изначальная система намеренно отделяла создание домена от окончательной документальной проверки. Регистрант мог пройти первичную сертификацию и получить имя, однако невыполнение дополнительного шага могло привести к удалению и освобождению. С конца 2014 года до последующего разделения парные метки в.NGO и.ONG были также спроектированы как единый технический пакет, поэтому заданные команды и решения реестра коррелировали в обоих пространствах имён.
  • Договорное изменение 2022 года удалило положение о связке из каждого соглашения о домене верхнего уровня, допустив раздельную регистрацию и управление жизненным циклом. Оно не отменило Спецификацию 12 и не передало регистраторам окончательные полномочия по определению соответствия. Текст 2014 года отдельно называл ориентированную на использование процедуру RDRP с заявленной апелляцией, а раздел 2.19 включал RRDRP для несоблюдения на уровне оператора; ни тот, ни другой источник не устанавливает опубликованную индивидуальную апелляцию по существу проверки соответствия, автоматическое приостановление или маршрут восстановления после освобождения.

Три текста, одна проблема принудительного исполнения

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

Первый —Спецификация 12 к соглашению о реестре.NGO от 6 марта 2014 года. Её первоначальная модель проверки позволяла создать домен сразу после подтверждения первичной сертификации заявителя. Документальная проверка продолжалась после этого. Если регистрант не предоставлял дополнительную информацию, требуемую на втором шаге, спецификация предписывала удалить и освободить домен. Таким образом, проверка была не просто вступительным тестом перед использованием. Это было постоянное условие, привязанное к идентификатору, который уже мог быть введён в эксплуатацию.

Второй — бывший раздел 5 Приложения A, добавленный договорной поправкой 2014 года. Это положение, воспроизведённое в более позднейпоправке №2 к.NGO, рассматривало соответствующие метки в.NGO и.ONG как единый пакет. Оно требовало, чтобы работа двух доменов верхнего уровня была идентичной для связанного имени, и в общих чертах устанавливало, что услуги, действия, изменения, решения и требования, затрагивающие один домен, должны применяться и к другому. Команда преобразования, отправленная для одной метки, должна была применяться ко всему пакету и завершаться успехом только при успехе для всех соответствующих объектов. Парные имена были отдельными регистрациями в отдельно делегированных доменах верхнего уровня, но договор делал их обычный жизненный цикл взаимозависимым.

Третий текст — сама поправка №2.Инструмент.NGOи его отдельныйаналог.ONGполностью удалили раздел 5, оставив в силе остальную часть каждого соглашения о реестре. Связка была устранена; ограничения сообщества — нет.

Именно это различие составляет суть дела. До разделения контроль соответствия требованиям и техническое управление жизненным циклом были многослойными. Спецификация 12 задавала правила сообщества и санкции. Связка позволяла определённым последствиям распространяться на парную метку в обоих пространствах имён. После разделения второй слой исчез, но Public Interest Registry сохранил договорную роль: определять операционные требования к проверке и решать, удовлетворяет ли регистрация этим требованиям. Реформа изменила радиус действия команды жизненного цикла, а не базовое распределение полномочий по определению соответствия.

Четвёртый документ объясняет, почему удаление одного пункта потребовало большего, чем изменение страницы с ценами. В своёмзапросе 2021 года о разделении доменов верхнего уровняPublic Interest Registry сообщил, что обе DNS-зоны тогда создавались из единого реестра.NGO. Разделение требовало независимого реестра.ONG, переноса в него данных, нового тестирования и перехода, при котором будущие команды могли давать разные результаты для двух строк. Договор, данные и инфраструктура были намеренно связаны. Поэтому отмена такой схемы потребовала договорного процесса контроля изменений и операционной миграции.

Лестница статусов: заявка, договор, одобрение услуги и делегирование

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

Приложение к заявке Public Interest Registry на.NGO полезно как доказательство на стадии предложения. Оно фиксирует, что заявитель заявлял о намерении построить и как он ожидал работы систем реестра и регистраторов. Оно не может доказать, что ICANN принял каждое предложение, что услуга стала договорно обязательной, что регистраторы её внедрили или что конкретное принудительное действие имело место. Такие выводы требуют более поздних инструментов.

Юридическая операционная база появилась благодаря двум соглашениям от 6 марта 2014 года. Официальнаязапись о соглашении по.NGOICANN определяет Public Interest Registry как оператора и классифицирует домен верхнего уровня как реестр сообщества, подпадающий под Спецификацию 12. Параллельнаязапись о соглашении по.ONGподтверждает отдельный договор для другой строки. Парная маркетинговая концепция не превращала два домена верхнего уровня в один юридический объект.

Исполненное соглашение также оставляло ворота для услуг, которые ещё не были одобрены. Раздел 2.1 требовал от оператора использовать Политику оценки услуг реестра, или RSEP, прежде чем предлагать дополнительную услугу реестра за пределами одобренного описания. ICANN мог одобрить услугу в письменной форме и потребовать поправку. Раздел 2.9 требовал, чтобы регистрации осуществлялись через аккредитованных ICANN регистраторов на основе единого соглашения реестра с регистраторами. Раздел 2.19 делал политики регистрации сообщества принудительными и подчинял оператора процессу разрешения споров об ограничениях.

Вместе эти положения создавали цепочку: предложение оператора, проверка изменений ICANN, договорная поправка при необходимости, внедрение регистратором и постоянное соблюдение.

Делегирование снова было отдельным этапом. Записи корневой зоны IANA показывают, что оба домена верхнего уровня были внесены в корень 10 июля 2014 года, но имеют отдельные записи делегирования:запись.NGOссылается на отчёт о делегировании от 16 июля, азапись.ONG— на отчёт от 23 июля. Public Interest Registry указан как спонсирующая организация для каждой из них. Эти записи устанавливают техническое делегирование; они не решают, соответствует ли отдельная организация критериям НКО, и не доказывают, что более поздняя связка была одобрена. Связка прошла собственный путь RSEP и Совета директоров.

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

Спецификация 12 как исполнимая конституция соответствия

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

Согласноисполненному соглашению по.NGO, каждый регистрант должен был продемонстрировать принадлежность к неправительственной организации или её статус. Public Interest Registry должен был работать с профильными членскими организациями, консультативным советом и более широким сообществом НКО. Такая формулировка создавала каналы для экспертизы и участия. Она не давала этим участникам права голоса по отдельному результату проверки, права вето на политику реестра или полномочий направлять договорную реакцию ICANN. Оператор оставался ответственным за применение ограничений; ICANN оставался контрагентом, способным обеспечить исполнение соглашения.

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

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

Положения о принудительном исполнении усиливали этот временной выбор. Public Interest Registry должен был проводить проактивные проверки при регистрации и реактивное принуждение через аудиты и споры. Спецификация разрешала выборочные аудиты в отношении членства, выбора имени и использования. Когда оператор приходил к выводу, что регистрация не соответствует требованиям, он должен был уведомить регистранта и поместить имя под блокировку реестра. Если проблема не устранялась, регистрация могла быть прекращена.

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

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

Текущую политику не следует проецировать назад без оговорок. Действующаяполитика регистрации и валидации.NGO/.ONGPublic Interest Registry перечисляет семь критериев, включая общественно полезную направленность, некоммерческий фокус, ограниченное государственное влияние, независимость, активную деятельность, организационную структуру и законное поведение. Она также содержит ограничения, связанные с юрисдикцией и санкциями. Найденный первичный источник не даёт полной датированной истории версий, показывающей, когда каждый критерий, триггер жалобы, ожидание активного DNS или санкция вошли в политику. Безопасный вывод уже: договор 2014 года установил принудительное соответствие НКО и постоянную валидацию; текущая политика показывает, как Public Interest Registry теперь формулирует и администрирует эти полномочия. Точная преемственность каждой операционной детали ещё подлежит документированию.

Связка превратила два имени в одну машину жизненного цикла

Дополнительная услуга реестра, предложенная в 2014 году, не была рыхлым торговым пакетом.Запрос RSEP на обязательный технический пакетописывал связанное поведение реестра для одинаковых меток второго уровня в.NGO и.ONG. Регистрант, приобретающий одну, получал парное имя в другой. Один и тот же регистратор спонсировал оба имени. Основные контактные данные, даты регистрации и истечения, информация о статусе и поведение в льготных периодах синхронизировались с ограниченными техническими исключениями.

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

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

Public Interest Registry предложил политическое обоснование. В запросе говорилось, что НКО выражали обеспокоенность по поводу стоимости и путаницы защитных регистраций и что связка позволит организации закрепить обе языковые формы одной транзакцией. Также утверждалось, что с регистраторами были проведены консультации и возражений не ожидается. Эти заявления показывают позицию оператора в пользу услуги. Они не являются независимым доказательством широты спроса НКО, репрезентативности консультаций или отсутствия затрат на внедрение. Более поздний запрос о разделении сообщит именно о таких затратах.

Самое широкое юридическое выражение связки появилось в бывшем разделе 5 Приложения A. Как воспроизведено впоправке о разделении.NGO, это положение применялось, находилось ли имя в состоянии удержания, выделения, активации или в другом статусе. Оно требовало единообразного обращения в двух доменах верхнего уровня и делало Public Interest Registry единолично ответственным за поддержание такой согласованности. Оно распространялось шире, чем регистрация, обращённая к клиенту. Положение связывало услуги, политики регистрации, учёт транзакций, депонирование данных, авторизацию регистраторов, обязательства по аварийному переходу, средства правовой защиты и Спецификацию 12. Неспособность поддерживать согласованность могла рассматриваться как нарушение, затрагивающее оба соглашения.

Именно поэтому связка увеличивала коррелированную подверженность. Согласно первоначальной Спецификации 12, невыполнение второго шага проверки прямо вело к удалению и освобождению, тогда как более поздняя находка аудита шла по иному пути: уведомление, блокировка реестра, возможность устранения и возможное прекращение. Бывший раздел 5 требовал, чтобы соответствующие действия, решения, средства правовой защиты и политики Спецификации 12 действовали для всего пакета доменов.

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

Кто на самом деле одобрил услугу

Процесс RSEP 2014 года показывает, как участие, технические консультации и полномочия по принятию решений были разделены. Согласно резолюциям Совета директоров ICANN от 9 сентября 2014 года, Public Interest Registry подал запрос в марте, а ICANN опубликовал его публично в мае. Предварительный анализ персонала не выявил существенной проблемы конкуренции, но обнаружил возможный вопрос безопасности или стабильности, что привело к передаче в Группу технической оценки услуг реестра, или RSTEP.

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

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

Совет директоров осуществил эти полномочия через две связанные резолюции. Резолюция 2014.09.09.05 одобрила предлагаемую услугу реестра. Резолюция 2014.09.09.06 уполномочила Президента и генерального директора или назначенное лицо разработать и исполнить поправки, учитывающие вопросы внедрения. Совет также ясно указал, что его одобрение не создаёт прецедента для IDN-вариантов. Технические консультации сузили вопрос риска; персонал администрировал процесс; публичные комментаторы имели возможность предоставить информацию; Совет принял действующее решение об одобрении.

Контраст с первоначальным ожиданием оператора поучителен. Запрос RSEP указывал, что поправка к соглашению о реестре не предполагается. Тем не менее Совет санкционировал её, и поправка №1 к.NGO вместе с параллельным инструментом.ONG закрепила связку в декабре 2014 года. Заявитель или оператор может предлагать, как классифицировать изменение. ICANN контролирует, требует ли услуга договорного текста и на каких условиях она может продолжаться.

Договор с регистраторами сделал конструкцию исполнимой

Одобрение Совета и поправка остались бы неполными без обязательств регистраторов. Регистраторы держали отношения с клиентом, принимали запрос на регистрацию, получали согласие с политиками, собирали доказательства и отправляли команды, которые создавали или преобразовывали имя.Соглашение реестра с регистраторами.NGO/.ONG 2014 годаPublic Interest Registry преобразовало конструкцию уровня реестра в эти нижестоящие обязанности.

Соглашение определяло «Пакет зарегистрированных имён» и требовало одновременного выделения идентичной метки в другом домене верхнего уровня. Оно обязывало регистратора отображать или давать ссылку на применимые политики и получать явное согласие регистранта. Оно запрещало регистратору проводить процедуру по одной регистрации, если соответствующая процедура не выполнялась для парной. Оно также признавало требования к валидации, установленные Public Interest Registry, и возлагало поддержку клиентов первой линии на регистратора, тогда как реестр поддерживал регистратора.

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

Соглашение 2014 года также выравнивало коммерческие и технические стимулы, взимая одну плату за пакет. Это снижало видимую клиенту стоимость закрепления обеих меток, но требовало от регистраторов поддержки нестандартного парного процесса. Позднейшие данные о низком uptake и ошибках конфигурации исходили от Public Interest Registry, а не из независимого аудита, однако правдоподобно, что специальный командный путь налагал издержки на регистраторов, чьи системы были спроектированы вокруг одного объекта регистрации за раз. Важный управленческий вывод не в том, было ли бремя неизбежным.

Он в том, что договор возложил его на регистраторов как цену за исполняемость политики.

После разделенияверсия 2022 соглашения реестра с регистраторамисохраняет распределение полномочий по принудительному исполнению политики, но убирает правило парного жизненного цикла. Регистраторы по-прежнему должны предъявлять соответствующие политики и получать согласие. Они остаются ответственными за поддержку, обращённую к клиенту. Public Interest Registry сохраняет широкие права отказывать, приостанавливать, отменять, передавать, блокировать или удерживать регистрации по соглашению и его политикам. Конкретная связка исчезла; позиция реестра по принудительному исполнению — нет.

Цепочка доказательств изменилась, но окончательные полномочия — нет

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

Согласно конструкции Спецификации 12 2014 года, заявитель сначала проходил первичную сертификацию. Создание следовало после подтверждения этой сертификации. Затем заявитель должен был предоставить дополнительную информацию. Её непредоставление вело к удалению и освобождению. Такая модель встраивала проверку после создания в каждую регистрацию и делала окончательную документацию условием сохранения контроля.

Текущая политика Public Interest Registryописывает процесс аудита, запускаемый жалобой. Регистратора уведомляют и просят собрать официальное название организации, страну и документальные доказательства. Примеры включают записи в государственных или иных признанных списках, учредительные документы и материалы, связанные с налогами. Public Interest Registry также заявляет, что может связываться с проверяемыми регистрантами через адрес электронной почты регистрации. Он изучает доказательства и может запросить у регистратора дополнительные. У регистратора есть 30 дней, чтобы ответить от имени регистранта, хотя реестр может принять решение раньше, если сочтёт доступную запись достаточной. Если Public Interest Registry приходит к выводу, что регистрант не соответствует требованиям, политика гласит, что домен будет удалён и освобождён без возврата средств. Если регистрант не отвечает в указанный срок, имя переводится в состояние ServerHold.

Распределение доказательной силы, таким образом, многослойно. Лицензирующие органы, корпоративные реестры, налоговые органы или другие признанные источники могут создавать базовые документы. Регистрант выбирает, что подать. Регистратор собирает и передаёт материалы. Public Interest Registry решает, удовлетворяют ли они политике. Документ публичного органа может быть решающим доказательством, не делая этот орган лицом, принимающим решение о домене. Регистратор может влиять на скорость и качество коммуникаций, не приобретая полномочий переопределять соответствие НКО.

Текущая страница не утверждает, что жалобщик получает право направлять исход. Жалоба, по-видимому, запускает аудит реестра; она не превращает жалобщика в арбитра. Политика также не называет независимую коллегию по существу для регистранта. Public Interest Registry проверяет, запрашивает дополнительную информацию и принимает решение о соответствии. Такая концентрация может обеспечивать последовательность, но она также означает, что институт, определяющий операционные стандарты, является тем же институтом, который применяет их к отдельным записям.

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

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

Удержание, удаление и освобождение — разные события непрерывности

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

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

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

После разделения парные метки могут иметь разных спонсоров, данные, даты и результаты команд. Это делает структурно возможным, что одна регистрация остаётся, пока другая удерживается, передаётся или удаляется. ТекущийFAQ Public Interest Registryсообщает клиентам, что.NGO и.ONG больше не входят в одну регистрацию и должны закрепляться отдельно. Изменение снижает коррелированную подверженность. Оно не гарантирует непрерывность для каждого отдельного имени, поскольку каждое остаётся подчинённым Спецификации 12 и политике валидации реестра.

Наиболее серьёзный момент — освобождение. Удержание может быть отменено в рамках той же регистрации. Удалённая и освобождённая метка может быть приобретена кем-то другим при условии правил соответствия реестра. Как только вмешиваются права третьих лиц и использование, простое административное восстановление становится труднее. Это ограниченный вывод из опубликованного правила жизненного цикла, а не свидетельство того, что конкретное имя.NGO или.ONG было занято новым регистрантом после ошибочного удаления. Запись на уровне дел, необходимая для проверки этого риска, не найдена.

Два маршрута пересмотра, и ни один не является задокументированной апелляцией на восстановление после аудита

Соглашение 2014 года определяет две разные процедуры по ограничениям, и их названия достаточно близки, чтобы спровоцировать существенную ошибку.Спецификация 12говорит, что утверждение о том, что домен не используется преимущественно для целей НКО, должно принудительно исполняться в рамках Политики разрешения споров об ограничениях, или RDRP. В том же предложении сказано, что RDRP будет включена в качестве приложения к соглашению о реестре и что RDRP содержит апелляцию. Раздел 2.19 соглашения о реестре отдельно обязывает оператора соблюдать Процедуру разрешения споров об ограничениях реестра, или RRDRP, которая является механизмом ICANN после делегирования, направленным на соблюдение оператором реестра. RDRP и RRDRP не следует сводить к одному маршруту.

Ссылка на RDRP ориентирована на использование. Она касается утверждения о том, используется ли зарегистрированное имя преимущественно для целей НКО. Документальный аудит, описанный в текущей политике Public Interest Registry, задаёт другой вопрос: удовлетворяет ли регистрант требованиям соответствия оператора и может ли подтвердить этот статус запрошенными доказательствами. Заявление договора о наличии апелляции внутри RDRP само по себе, таким образом, не устанавливает апелляцию на административное решение Public Interest Registry о соответствии.

Апелляция на решение по спору об использовании и пересмотр аудита по существу — разные институциональные объекты, даже если лежащие в основе факты пересекаются.

Найденный текст соглашения также оставляет пробел во внедрении. В нём сказано, что RDRP будет приложена, но публичные материалы, рассмотренные для этой статьи, не выявили опубликованной серии решений по.NGO/.ONG, показывающей, кто обращался к этому маршруту, какое бремя доказывания применял провайдер, приостанавливала ли подача команду реестра или какое средство правовой защиты следовало в реальном деле. Договор поддерживает более узкое утверждение: процедура, ориентированная на использование, с заявленной апелляцией была предусмотрена и включена в конструкцию принудительного исполнения.

Он не поддерживает трактовку этой апелляции как продемонстрированного маршрута для приостановки удаления или восстановления имени, освобождённого после аудита соответствия.

RRDRPимеет более полно определённую, но иную цель. Её стороны — пострадавшая устоявшаяся организация, связанная с определённым сообществом, и оператор реестра; ICANN стороной не является. Жалобщик должен доказать правовой интерес, указать нарушенное ограничение сообщества, доказать, что оператор нарушил соглашение о реестре, и показать измеримый вред. Бремя лежит на жалобщике в соответствии с заявленным доказательственным стандартом процедуры. Регистрант, оспаривающий собственный результат аудита, не становится стороной RRDRP только потому, что его имя стало частью фактического фона.

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

Любая сторона RRDRP может запросить процедурную апелляцию de novo по существующей записи с ограниченной возможностью для более старых материалов. Эта апелляция пересматривает экспертное заключение RRDRP; это не апелляционное слушание по досье доказательств отдельного регистранта.

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

Текущая страница политики Public Interest Registry не называет поименованного независимого рецензента по существу для аудитов соответствия, автоматического приостановления на время оспаривания или процесса восстановления после удаления и освобождения. Соглашение реестра с регистраторами даёт регистратору роль поддержки клиента и передачи доказательств, но не превращает регистратора в апелляционный орган.

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

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

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

Разделение потребовало нового реестра, а не просто нового предложения

Запрос RSEP 2021 годаPublic Interest Registry представил разделение и как коммерческую корректировку, и как техническую миграцию. Оператор заявил, что эксперимент дал низкий uptake, лишь немногие организации активно использовали оба имени, регистраторы сталкивались со специализированным бременем внедрения, а исследование развёртывания 2019 года обнаружило, что многие пакеты были настроены неправильно. Это существенные утверждения, поскольку они дали основание для изменений. Они остаются доказательствами, представленными оператором. Базовое исследование, методология, исходные результаты и полный набор данных до и после разделения в найденной записи отсутствуют.

Описанная в запросе архитектура была конкретной. На момент подачи обе зоны.NGO и.ONG создавались из единого реестра.NGO. Чтобы разделить их, Public Interest Registry предложил создать независимый реестр.ONG и наполнить его соответствующими метаданными из.NGO. Большинство парных полей изначально копировалось; уникальные материалы DNSSEC сохранялись. После миграции требование общих метаданных исчезало. Регистраторы могли получать разные результаты EPP и управлять разными контактами, датами, статусами, передачами, продлениями и удалениями для парных меток.

Запрос также предполагал операционное тестирование и уведомление. Среда Operational Test and Evaluation должна была позволить регистраторам протестировать раздельную услугу. Public Interest Registry предложил уведомить регистраторов не менее чем за 90 дней и связаться с затронутыми регистрантами. На момент подачи он признал, что ещё не проводил конкретных коммуникаций о предлагаемом изменении. Таким образом, процесс отделял одобрение от планирования внедрения, как и в 2014 году.

Индекс статусов RSEPICANN фиксирует и техническую связку 2014 года, и техническое разделение 2021 года как одобренные услуги реестра. Более позднее одобрение привело к отдельным инструментам поправки №2 для.NGO и.ONG. Каждый удалил бывший раздел 5 Приложения A и сохранил остальную часть соглашения. Соглашение с регистраторами после разделения больше не содержит обязательных положений о парных транзакциях, а текущие рекомендации для клиентов рассматривают имена как отдельные покупки.

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

Разделение решило конкретную проблему: одна регистрация больше не должна была нести парную метку через жизненный цикл другого домена верхнего уровня. Оно также убрало договорное правило, согласно которому решения и средства правовой защиты, затрагивающие одно имя, автоматически применялись к другому. Оно не переписало Спецификацию 12. Оно не сделало регистраторов окончательной инстанцией по соответствию. Оно не устранило полномочия Public Interest Registry устанавливать требования к валидации через операционные стандарты и политики. Оно не добавило опубликованную индивидуальную апелляцию по существу аудита соответствия.

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

Вывод на 31 июля 2026 года

Принудительно исполняемая система.NGO/.ONG прошла три институциональные формы. Сначала появились ограничения сообщества и двухэтапная валидация, содержащиеся в соглашениях марта 2014 года. Затем — обязательный технический пакет, одобренный через RSEP и Совет директоров и преобразованный в договорные и регистраторские обязанности в конце 2014 года. Наконец — одобренное разделение и поправки 2022 года, устранившие положение о связке при сохранении базовых соглашений.

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

ICANN контролирует договорные изменения и окончательное принуждение против реестра. Функция корневой зоны IANA фиксирует делегирование; она не выносит решений о статусе НКО.

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

Самый сильный вывод, следовательно, ограничен..NGO/.ONG стали принудительно исполняемой услугой реестра, потому что юридические соглашения закрепили полномочия по доказательствам и командам, а не потому что слово «проверенный» несло самоисполняющееся доверие. Первоначальная связка усиливала эти полномочия для пары идентификаторов. Разделение снизило корреляцию, но сохранило конституцию валидации. Нерешённый управленческий вопрос больше не в том, должны ли две строки двигаться вместе.

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