Резюме

  • 15 сентября 2003 года VeriSign добавил в уже делегированные реестры.COM и.NET записи с подстановочным символом (wildcard). Запросы о многих несуществующих именах, которые ранее получали отрицательный ответ DNS, стали получать синтезированный адрес, связанный с Site Finder. VeriSign мог выполнить это операционное изменение, потому что управлял авторитетной инфраструктурой реестра. ICANN не изменяла зоны напрямую: сначала она попросила добровольно приостановить сервис, а затем выдвинула подкреплённое дедлайном договорное требование вернуться к прежнему состоянию. VeriSign приостановил сервис к 4 октября, при этом прямо оспаривая доказательства, полномочия и толкование договора со стороны ICANN.
  • Техническая картина не сводилась к утверждению, что подстановочные записи запрещены протоколом DNS. Internet Architecture Board и Security and Stability Advisory Committee ICANN сосредоточились на другой проблеме: подстановочная запись на верхнем уровне реестра изменила архитектурное допущение, на которое опирались веб-браузеры, почтовые системы, фильтры и другие приложения. VeriSign заявлял, что сервис был протестирован, и оспаривал методологию и масштаб предполагаемого вреда. Консультативные органы могли анализировать и давать рекомендации, но ни у одного из них не было ни операционного рубильника, ни полномочий принудительно исполнять договор.
  • Судебные разбирательства создали площадки для оспаривания действий ICANN, однако найденные итоговые судебные акты не устанавливают окончательного решения по существу о том, что Site Finder нарушил реестровые соглашения 2001 года. Долгосрочный институциональный ответ был ориентирован на будущее. Соглашение.NET 2005 года, решение Правления ICANN от ноября 2005 года по консенсусной политике, соглашение.COM 2006 года и Registry Services Evaluation Policy превратили импровизированный конфликт «запуск и откат» в предварительное уведомление, первичную проверку персоналом, передачу вопросов конкуренции в соответствующие органы, экспертную и публичную оценку существенных вопросов безопасности или стабильности, решение Правления и ограниченную процедуру пересмотра.

Две даты и два разных вида власти

15 сентября 2003 года пользователь, который ошибся в наборе незарегистрированного имени.COM или.NET, уже не обязательно получал обычный сигнал о том, что имя не существует. VeriSign разместил подстановочные записи в авторитетных зонах. Для затронутых запросов серверы реестра возвращали синтезированный адрес, который направлял веб-трафик к Site Finder — поисково-навигационному сервису, управляемому VeriSign. Четыре дня спустярекомендация ICANNописывала изменение, указывала на последствия, о которых сообщали сетевые операторы и пользователи программного обеспечения, просила VeriSign добровольно приостановить сервис и направляла технические вопросы в Internet Architecture Board и Security and Stability Advisory Committee ICANN.

3 октября ICANN перешла от просьбы к требованию. Вписьме Пола Туми VeriSignICANN утверждала, что Site Finder противоречит нескольким положениям соглашений.COM и.NET, требовала восстановить работу в том виде, в каком она была до запуска, к 18:00 по тихоокеанскому времени 4 октября, и предупреждала, что организация предпримет шаги по принудительному исполнению договоров, если VeriSign не подчинится. Вответе VeriSign, направленном в тот же день, говорилось, что требование необоснованно, отвергались заявленные фактические и правовые предпосылки, выражалось согласие приостановить сервис в установленный срок, и за компанией сохранялись все права. Подстановочная запись была удалена.Архивная хронология событий с подстановочными записями ICANNфиксирует развёртывание 15 сентября и приостановку 4 октября, а письма того времени показывают противоположные позиции сторон. Сторона, способная изменить авторитетные зоны, операционно подчинилась, не признав при этом правоту стороны, заявлявшей о договорных полномочиях.

Это разделение и есть институциональная суть дела. У VeriSign был контроль над реализацией. У ICANN были договор, заявленные полномочия по его принудительному исполнению и возможность повысить цену отказа. У IAB и SSAC были экспертиза и публичный авторитет, но не было рубильника. Регистраторы, сетевые операторы, разработчики программного обеспечения и пользователи могли сообщать о последствиях, адаптировать системы и участвовать в политической работе, но не могли заставить приостановить сервис.

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

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

Это была попытка изменить последовательность так, чтобы самые сложные вопросы рассматривались до того, как сервис на уровне реестра изменит поведение систем за пределами реестра.

Существующее делегирование, а не новая заявка

Зоны.COM и.NET не были заявителями, ожидающими входа в корневую зону. Это были давние делегирования, регулировавшиеся в 2003 году отдельными соглашениями, заключёнными в 2001 году.Соглашение о реестре.COM от 16 апреля 2001 годаиСоглашение о реестре.NET от 25 мая 2001 годапризнавали VeriSign оператором реестра и возлагали на него операционные функции, посредством которых формировались авторитетные ответы. Корневая зона делегировала.COM и.NET авторитетным серверам, управляемым VeriSign, который поддерживал данные реестра и обслуживал ответы. Таким образом, Site Finder возник внутри уже существующих отношений. Не было ни заявки на новый gTLD, ни набора претендентов, ни оценки приоритета сообщества, ни этапа заключения договора, ни повторного делегирования IANA, которые ICANN могла бы одобрить или отклонить.

Тем не менее соглашения 2001 года давали правовые объекты, вокруг которых спорили ICANN и VeriSign. Их положения определяли реестровые сервисы, устанавливали технические и функциональные обязательства, регулировали доступ регистраторов и создавали пути для принудительного исполнения и разрешения споров. Соглашение.NET, например, разграничивало изменения, которые можно было внести с предварительным уведомлением, и существенные функциональные изменения, требующие взаимного письменного согласия или применения применимой процедуры консенсусной политики. Оно также содержало обязательства о равном доступе и кодексе поведения.

В письме от 3 октября ICANN опиралась на эту договорную архитектуру, утверждая, что Site Finder был несанкционированным реестровым сервисом и что его внедрение повлияло на нейтральную работу реестра, протоколы регистраторов и равное обращение. VeriSign отвечал, что сервис соответствовал соглашениям и техническим стандартам. Наличие договора делало требование возможным, но не делало толкование ICANN самоочевидным.

Договоры также не устанавливали, что у ICANN был прямой технический рубильник. Соглашение.NET 2001 года содержало чрезвычайное средство защиты, по которому ICANN после уведомления и неустранённого обоснованного определения опасности могла приостановить действие соглашения на пять календарных дней, одновременно ходатайствуя о более длительной обеспечительной мере. Это был правовой механизм, направленный на договорные отношения.

Найденные материалы не показывают, что какой-либо суд или арбитражный состав окончательно решил, что эта оговорка применялась к Site Finder; оговорка также не уполномочивала ICANN входить в производственную среду VeriSign и самостоятельно удалять подстановочную запись. Материалы показывают требование, дедлайн, угрозу договорных мер и выполнение отката оператором. Приравнивание этих фактов к рубильнику, управляемому ICANN, означало бы сведение рычага принудительного исполнения к контролю над инфраструктурой.

Такая же осторожность требуется при описании «приостановки». VeriSign приостановил Site Finder; ICANN не приостанавливала делегирования.COM или.NET. Делегирования в корневой зоне и лежащие в основе реестровые отношения остались в силе. Спорная функция подстановочных записей была удалена без последующего перехода или повторного делегирования. Такой ограниченный операционный результат менее драматичен, чем остановка реестра, но институционально более показателен: конфликт касался того, что действующий оператор может добавить к критически важному сервису и какая процедура должна предшествовать такому добавлению.

Почему подстановочная запись была больше, чем поисковая страница

На уровне DNS важное изменение произошло ещё до того, как браузер что-либо отобразил. Авторитетный сервер обычно различает по крайней мере три релевантных состояния. Запрошенное имя и тип записи могут существовать, что даёт положительный ответ. Имя может существовать без запрошенного типа записи, что даёт отрицательный ответ для этого типа. Или само имя может не существовать, что даёт ответ NXDOMAIN. Приложения и промежуточные системы привыкли использовать эти различия. Site Finder изменил третье состояние для многих запросов.COM и.NET, синтезируя запись A через подстановочную запись.

Для программного обеспечения, получавшего ответ, отсутствующее имя теперь выглядело так, будто оно разрешается в IP-адрес.

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

Это архитектурное различие объясняет, почему утверждение «это был всего лишь веб-поисковый сервис» было недостаточным. DNS-запрос не сообщает надёжно, какое приложение его вызвало. Один и тот же тест на существование мог быть инициирован браузером, агентом передачи почты, спам-фильтром, средством защиты, утилитой командной строки, автоматизированной системой выделения ресурсов или программой, написанной за годы до Site Finder. Реестр мог направлять HTTP-трафик на целевую страницу, но не мог ограничить изменённый DNS-ответ только протоколом HTTP.

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

Доклад SSAC, опубликованный в июле 2004 года, описывал это как замену синтезированным ответом того условия ошибки, на которое опирались приложения. В нём документировались последствия для электронной почты, антиспам-инструментов, ожиданий в отношении конфиденциальности и сетевых обходных решений. Он также отверг часть самой сильной риторики вокруг этого эпизода: в докладе не делался вывод, что Site Finder «разрушил интернет», и признавалось, что имеющиеся данные не позволяют надёжно количественно оценить каждое последствие. Его институциональная аргументация основывалась на сочетании архитектурной зависимости, масштаба и разнообразия.COM и.NET, недостаточно раскрытых доказательств, ограниченного предварительного уведомления и издержек, переложенных на внешних участников, которые не выбирали это изменение.

Здесь же следует уточнить утверждение, которое часто делается об этом споре. Первичные материалы не подтверждают, что VeriSign вообще не проводил тестирование. Вписьме от 21 сентябрякомпания заявила, что проводила месяцы тестирования и анализа, что сервис соответствовал техническим стандартам и что она создаёт независимую комиссию технической экспертизы. В более поздних материалах компания продолжала оспаривать методы и выводы SSAC. Процедурным недостатком было не доказанное отсутствие внутреннего тестирования, а отсутствие до запуска общей и проверяемой доказательной базы, способной оценить, как изменение авторитетной зоны повлияет на стороны за пределами собственных систем VeriSign.

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

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

Первая просьба: приостановить добровольно, пока формируется доказательная база

Рекомендация ICANN от 19 сентябряне начиналась с формального объявления о нарушении. В ней описывался сервис, сообщалось об опасениях технических операторов, содержалась просьба к VeriSign добровольно приостановить его, а вопросы направлялись в SSAC и IAB. Такая последовательность сигнализировала и о неопределённости, и о срочности. ICANN пыталась сформировать техническую доказательную базу уже после того, как сервис изменил поведение в промышленной среде. Просьба имела институциональный вес, но не означала завершённого разбирательства или согласованной чрезвычайной процедуры, адаптированной к запускам реестровых сервисов.

Вответе VeriSign от 21 сентябрявыражалось несогласие с немедленной приостановкой. Site Finder представлялся как инновация, призванная улучшить навигацию для пользователей, подчёркивались предварительное тестирование и соответствие стандартам, и утверждалось, что ICANN должна изучить доказательства, прежде чем требовать отзыва сервиса. Позиция компании обнажала предсказуемую проблему стимулов. Оператор, вложивший средства в сервис и запустивший его в широком масштабе, получает факты на месте: пользователи видят его, начинаются коммерческие отношения, и стоимость отката становится очевидной. Тем временем другие участники вынуждены диагностировать последствия в условиях операционной нагрузки. Поэтому управление по принципу «сначала запуск» возлагает бремя неопределённости на тех, кто не выбирал этот сервис.

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

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

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

Вопрос был в том, должен ли оператор быть обязан ждать.

Требование от 3 октября: полномочия заявлены до разрешения по существу

К 3 октября ICANN перешла от призыва к добровольной сдержанности к заявленному договорному требованию. Вписьме-требовании Туминазывалось несколько правовых теорий. Утверждалось, что Site Finder представляет собой несанкционированный реестровый сервис или функциональное изменение; мешает нейтральной работе реестра и равному доступу; создаёт несоответствия с протоколами взаимодействия реестра и регистраторов и положениями о регистрации; и вызывает задокументированные последствия, выходящие за пределы веб-навигации. Требовалось вернуться к состоянию до 15 сентября и устанавливался конкретный срок. Если VeriSign откажется, ICANN заявляла, что предпримет шаги по принудительному исполнению соглашений.

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

Вответе VeriSign от 3 октябряэто разделение было выражено прямо. Компания назвала действия ICANN необоснованными и превышающими полномочия, заявила, что Site Finder соответствует стандартам и был тщательно протестирован, критиковала обращение ICANN с доказательствами и сообщила, что приостановит сервис только после того, как ICANN откажет в предоставлении дополнительного времени. Компания оставляла за собой иски и средства защиты и заявляла, что соблюдение требования не должно рассматриваться как отказ от прав или уступка. Формулировки важны. Сторона может подчиниться требованию из-за серьёзности угрожаемых последствий, сохраняя при этом аргумент о незаконности требования. Операционное подчинение — это доказательство того, что рычаг принуждения сработал, но не доказательство правильности лежащей в основе теории.

Собственное письмо ICANN указывало на более долгосрочное решение. В нём содержалась просьба к Generic Names Supporting Organization разработать процесс, который сделает рассмотрение предлагаемых реестровых сервисов своевременным, прозрачным и предсказуемым. Сама эта просьба показывает институциональный пробел, выявленный спором: существующие механизмы не обеспечивали бесспорную, полную и соразмерную процедуру до запуска спорного реестрового сервиса.

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

Оператор больше не мог рассчитывать на продолжение работы Site Finder, пока эти вопросы обсуждались, но сам спор переместился в консультативные, политические и судебные каналы.

Рекомендации могли легитимировать ответ, но не исполнить его

IAB и SSAC находились в трудном положении. Их экспертиза была центральной, поскольку спор затрагивал семантику протоколов, зависимости приложений и операционные риски. Однако их формальные полномочия были узкими. IAB мог выпускать архитектурные рекомендации. SSAC мог консультировать Правление ICANN и сообщество. Ни один из органов не был регулятором с независимыми полномочиями давать указания VeriSign, взыскивать убытки или изменять реестровое соглашение. Вдокладе SSACего роль описывалась как консультативная, а не как судебная или правоприменительная.

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

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

Более длительное расследование SSAC объединило доклады, публичные встречи и технические наблюдения. В его материалах были октябрьский публичный форум 2003 года и серия слушаний, комментарии операторов и пользователей, а также анализ почты, конфиденциальности, обработки ошибок и мер по смягчению последствий. В докладе был сделан вывод, что Site Finder изменил смысл отрицательных ответов и вынудил некоторые внешние системы адаптироваться. Он также признавал ограниченность доказательств.

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

Вответе VeriSign для SSAC от августа 2004 годаоспаривались методы и выводы доклада. Утверждалось, что SSAC не дал адекватной количественной оценки предполагаемого вреда, не придал должного значения тестированию VeriSign и подходил к сервису с предубеждением против него. Эти возражения не давали VeriSign право вето на консультативные материалы, так же как доклад SSAC не давал SSAC полномочий принудительно добиваться отката. Однако они не позволяли рассматривать эти материалы как технический консенсус, свободный от институционального конфликта. Спор касался того, кто определяет адекватные доказательства, когда внешние стороны могут их изучить и какой уровень неопределённости оправдывает вмешательство.

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

Такое распределение ролей легко размыть, поскольку все участники фигурировали в одном публичном споре. Участие давало регистраторам, инженерам, пользователям, компаниям и правительствам возможность внести доказательства в материалы. Экспертиза давала IAB и SSAC влияние на то, как понимали риск. Процесс разработки политики давал GNSO формальный путь рекомендовать общеприменимые правила. Полномочия Правления давали ICANN возможность принимать эти правила. Договорный и операционный контроль определял, может ли конкретный сервис быть развёрнут или удалён.

Позднейшая система была построена путём соединения этих ролей без притворного утверждения об их равенстве.

Судебные разбирательства дали доступ к пересмотру, но не решение по существу Site Finder

VeriSign не принял вмешательство ICANN в 2003 году как окончательное юридическое слово. В феврале 2004 года компания подалафедеральный искс обвинениями в нарушении антимонопольного законодательства и заявлениями договорных и связанных с ними требований по праву штата. Site Finder был частью более широкого спора о подходе ICANN к предлагаемым сервисам и договорным полномочиям. VeriSign добивался деклараторной и обеспечительной защиты, принудительного исполнения в натуре и возмещения убытков. В иске утверждалось, что у ICANN не было надлежащего основания для ультиматума о приостановке и что Site Finder был допустим по договору и технически обоснован. Эти утверждения были требованиями, предъявленными суду, а не выводами, сделанными судом.

Федеральное постановление от августа 2004 годане решило, что Site Finder нарушил реестровые соглашения. Оно отклонило федеральный антимонопольный иск с лишением права на повторное предъявление и отклонило остальные требования по праву штата без лишения права на повторное предъявление, отказавшись от дополнительной юрисдикции, что оставило эти требования доступными для рассмотрения в другом форуме. Это решение сузило форум и изменило рычаги в судебном споре, но не превратило договорные теории ICANN от октября 2003 года в установленные судом факты.

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

Именно это показывают найденные итоговые документы.Дело в Калифорнии было прекращено с лишением права на повторное предъявлениев декабре 2006 года после мирового соглашения, аДевятый окружной апелляционный суд прекратил апелляциюпозже в том же месяце по соглашению сторон. Вобъявлении ICANN о мировом соглашении от февраля 2006 годаурегулирование более широких споров связывалось с новым соглашением.COM, которое на том этапе требовало одобрения Министерства торговли США. Доступные судебные акты устанавливают закрытие дел. Они не устанавливают окончательного судебного решения о том, что соглашения 2001 года запрещали Site Finder, присуждения убытков, связанных с приостановкой 2003 года, или постоянного судебного запрета в отношении сервиса.

Это различие между доступом к пересмотру и средством правовой защиты. VeriSign мог заявлять требования, подавать апелляции, участвовать в арбитраже и вести переговоры. Эти пути увеличивали его способность сопротивляться, добиваться защиты и вести переговоры о более широком урегулировании. Но сам сервис уже был приостановлен. В найденных материалах нет последующего решения по существу, которое восстановило бы его или компенсировало приостановку на основе теории, связанной именно с Site Finder. С другой стороны, ICANN не получила окончательного судебного решения, подтверждающего каждую теорию из её требования.

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

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

От чрезвычайного ответа к процессу разработки политики

Работа Generic Names Supporting Organization превратила спор из двустороннего конфликта в общий вопрос: как ICANN должна оценивать изменения реестровых сервисов до их развёртывания? Процесс GNSO был шире, чем Site Finder. Реестры различались по размеру, сервисам и технической архитектуре; многие предлагаемые изменения были рутинными; конфиденциальность могла иметь коммерческое значение; а задержка могла препятствовать полезным инновациям. Политику, написанную как замаскированное постоянное наказание для одного оператора, было бы трудно оправдать как общеприменимое консенсусное правило.

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

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

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

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

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

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

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

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

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

Сама роль GNSO иллюстрирует участие без окончательного контроля. Группы интересов, реестры, регистраторы и другие участники предоставляли доказательства и согласовывали рекомендации. Совет мог одобрить политическую рекомендацию через назначенные ему процедуры. Правление всё равно должно было принять консенсусную политику и дать указания по реализации. Затем договоры должны были сделать эту дисциплину применимой к конкретным операторам, где это уместно. Разработка политики была незаменимым этапом, но сама по себе она не удаляла и не добавляла ни одной строки в зоне реестра.

Закрепление предварительной проверки в договорах.NET и.COM

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

8 ноября 2005 годаПравление ICANN приняло процедуру оценки реестровых сервисов как консенсусную политику после единогласной рекомендации Совета GNSO. Правление указало, что реализация должна руководствоваться определениями и положениями о конфиденциальности соглашения.NET. Это был отдельный юридический шаг. Согласованные условия в.NET продемонстрировали работоспособную модель; решение Правления придало процедуре статус и сферу действия консенсусной политики в рамках соответствующих договоров. Было бы неточно рассматривать любой из этих шагов как простое дублирование другого.

Копия соглашения о реестре.COM 2006 года, поданная в SEC, показывает дисциплину проверки, встроенную в отношения, находившиеся в центре спора о Site Finder. В нём реестровые сервисы определялись достаточно широко, чтобы включать сервисы, которые мог предоставлять только оператор реестра, и существенные изменения одобренных сервисов. Оно требовало письменного уведомления и достаточной информации для того, чтобы ICANN могла сделать предварительное определение, и не позволяло скрывать назначение сервиса и его влияние на пользователей DNS под грифом конфиденциальности. В нём излагались первоначальная проверка, передача вопросов конкуренции и проверка безопасности или стабильности.

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

Роль технической комиссии была влиятельной, но не обязывающей; исполнимое решение «не предлагать» следовало из решения Правления в рамках договорной и политической системы.

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

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

Всё же было бы преувеличением утверждать, что только Site Finder вызвал каждый элемент механизмов 2005 и 2006 годов. Процесс GNSO рассматривал более широкие проблемы сообщества реестров, а положения.NET и.COM появились из отдельных договорных направлений. Site Finder стал каталитической демонстрацией проблемы «сначала запуск»: изменение на уровне реестра, оспариваемые внешние эффекты, неполная предварительная проверка, чрезвычайное требование и судебные разбирательства. Итоговые гарантии также отражали более широкие интересы в инновациях, конфиденциальности, конкуренции и предсказуемом администрировании.

Институциональная преемственность сильна; исключительная причинность — нет.

RSEP: изменение последовательности действий

Политика оценки реестровых сервисов(Registry Services Evaluation Policy) была опубликована 25 июля 2006 года и вступила в силу 15 августа. Она превратила консенсусное решение в повторяемый административный процесс. В более позднемобъявлении о создании Технической комиссии по оценке реестровых сервисов и Службы запросов реестровзафиксировано, что защищённая система запросов заработала 22 августа и была публично объявлена 30 августа. Эти даты не следует смешивать: публикация, дата вступления в силу и административный запуск были отдельными этапами.

Предлагаемый сервис в рамках RSEP проходит через ряд этапов.

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

Во-вторых, персонал ICANN проводит предварительную проверку, как правило, в течение 15 календарных дней после получения достаточной информации. Если персонал не находит существенных вопросов безопасности, стабильности или конкуренции, реестр вправе развернуть сервис при соблюдении других договорных обязательств. Это быстрый путь. Он сохраняет пространство для рутинных инноваций и не позволяет каждому изменению становиться делом Правления. Формулировка «существенных вопросов не выявлено» не является сертификацией того, что сервис никогда не причинит вред; это пороговое определение политики на основе представленных материалов.

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

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

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

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

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

Короткая кодовая реализация: search.travel

Ценность процедуры наиболее очевидна, когда она меняет операционный результат до запуска. В 2006 году Tralliance предложил сервис на основе подстановочных записей для.travel, который направлял бы запросы, обычно не разрешающиеся, на search.travel.Техническая оценка RSTEPне рассматривала предложение как идентичное Site Finder и не утверждала, что код подстановочных записей в принципе невозможен. В ней было установлено, что Tralliance может реализовать предложенный сервис и что план тестирования и предшествующий уровень техники выглядели адекватными для этой цели, но был сделан вывод, что сервис представляет обоснованный риск существенного неблагоприятного эффекта, поскольку подстановочная запись на уровне реестра может повлиять на нынешние и будущие DNS-зависимые приложения и не может быть ограничена только веб-просмотром.

22 ноября 2006 года, рассмотрев доклад RSTEP, материалы SSAC и At-Large, а также другие публичные комментарии, Правление ICANN поручило персоналу сообщить Tralliance, что предложение не одобрено. Значение здесь процедурное, а не аналогическое. В отличие от Site Finder, предложение для.travel прошло техническую и правленческую проверку до развёртывания в масштабах реестра. Экспертная комиссия предоставила анализ; авторы комментариев — доказательства; Правление реализовало полномочия по принятию решений; реестр не создал сначала производственный факт и не заставил внешних участников добиваться отката.

Что устанавливает дело и что остаётся нерешённым

Первичные материалы подтверждают ограниченный вывод. VeriSign контролировал авторитетную реализацию и удалил Site Finder. ICANN использовала договорные рычаги и дедлайн, чтобы добиться этого удаления, но найденные документы не устанавливают, что у ICANN был отдельный технический рубильник. IAB и SSAC сформировали технически серьёзную доказательную базу, не имея полномочий принуждения. VeriSign оспаривал и доказательства, и толкование договора и сохранил за собой правовые требования.

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

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

Объявление ICANN от февраля 2006 года устанавливает, что завершение пакета урегулирования тогда зависело от одобрения Министерства торговли США; само по себе оно не устанавливает более позднюю дату одобрения. Найденные материалы также не устанавливают, подавал ли позже VeriSign Site Finder или существенно аналогичный сервис через RSEP. Поэтому приостановку в октябре 2003 года не следует переписывать как доказательство постоянного отказа.

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

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

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