Skip to main content
Resources

Протокол | Очередное заседание Правления ICANN

Страница также доступна на следующих языках:

Очередное заседание Правления ICANN было очным и состоялось в Кобе 14 марта 2019 года в 16:00 по местному времени.

Председатель Шерин Шалаби (Cherine Chalaby) без промедления открыл это заседание.

Помимо председателя на протяжении всего заседания или его части в нем участвовали следующие члены Правления: Бекки Берр (Becky Burr), Маартен Боттерман (Maarten Botterman), Рон да Сильва (Ron da Silva), Сара Дойч (Sarah Deutsche), Крис Дисспейн (Chris Disspain, заместитель председателя), Аври Дориа (Avri Doria), Рафаэль Лито Ибарра (Rafael Lito Ibarra), Данко Йевтович (Danko Jevtovic), Халед Кубаа (Khaled Koubaa), Акинори Маемура (Akinori Maemura), Йоран Марби (Göran Marby, президент и генеральный директор), Найджел Робертс (Nigel Roberts), Леон Санчес (León Sanchez), Мэтью Ширс (Matthew Shears) и Трипти Синха (Tripti Sinha).

На протяжении всего заседания или его части в нем участвовали следующие представители в Правлении: Харальд Альвестранд (Harald Alvestrand), представитель IETF, Манал Исмаил (Manal Ismail), представитель GAC, Мерике Каэо (Merike Kaeo), представитель SSAC и Каве Ранжбар (Kaveh Ranjbar) представитель RSSAC.

Секретарь: Джон Джеффри (John Jeffrey), генеральный юрисконсульт и секретарь.

 

  1. Согласованная повестка дня:
    1. Утверждение протоколов
    2. Утверждение поправки для удовлетворения заявки о предоставлении услуги регистратуры, поступившей от Verisign для получения разрешения на регистрацию односимвольного домена второго уровня O.COM
    3. Перенос срока соблюдения положений политики в области расширенного варианта записи данных WHOIS
    4. Назначение независимых аудиторов на 2019 ФГ
    5. Одобрение поправок к уставу Комитета Правления по организационной эффективности
    6. Назначение представителя оператора корневого сервера в RSSAC
    7. Утверждение поправки к контракту на исполнение функций IANA в отношении имен
    8. Выражение благодарности местному организатору 64-й конференции ICANN
    9. Выражение благодарности спонсорам 64-й конференции ICANN
    10. Выражение благодарности переводчикам, персоналу, группе поддержки мероприятий и сотрудникам гостиницы, обеспечившим возможность проведения 64-й конференции ICANN
  2. Основная повестка дня:
    1. Рекомендации в отношении управления вариантами IDN-доменов верхнего уровня
    2. Подготовка к реализации последующих процедур для новых gTLD
    3. Передача домена верхнего уровня .VU (Вануату) организации Telecommunications Radiocommunications and Broadcasting Regulator (TRBR)
    4. Рассмотрение апелляции 16-5: DotMusic Limited
    5. Рассмотрение заявки на домен .AMAZON
    6. Одобрение результатов второй организационной проверки NomCom – итоговый отчет и рекомендации
    7. Дальнейшие действия по определению состава группы по проверке исполнения функций IANA
    8. Утвержденные резолюции Правления (AOB)
      1. Проект анализа доменных коллизий – первое исследование
  1. Согласованная повестка дня:

    Председатель открыл заседание и ознакомил присутствующих с пунктами согласованной повестки дня. Председатель поинтересовался, есть ли у кого-либо из членов Правления предложения по переносу пунктов из согласованной повестки дня в основную. Аври Дориа предложила перенести в основную повестку дня пункт «Одобрение результатов второй организационной проверки NomCom – итоговый отчет и рекомендации». Крис Дисспейн предложил перенести в основную повестку дня пункт «Дальнейшие действия по определению состава группы по проверке исполнения функций IANA».

    Рон да Сильва выдвинул, а Лито Ибарра поддержал предложение. Затем председатель предложил проголосовать и Правление приняло следующее решение:

    1. Утверждение протоколов

      Принята резолюция (2019.03.14.01): Правление утверждает протоколы особого заседания Правления ICANN, состоявшегося 16 января 2019 года и очередного заседания Правления ICANN, состоявшегося 27 января 2019 года.

    2. Утверждение поправки для удовлетворения заявки о предоставлении услуги регистратуры, поступившей от Verisign для получения разрешения на регистрацию односимвольного домена второго уровня O.COM

      Принимая во внимание, что корпорация ICANN оценила предлагаемую поправку к Соглашению с Verisign об администрировании домена верхнего уровня .COM как услугу регистратуры, в соответствии с требованиями разделов 3.1(d)(iii) и 3.1(d)(iv) указанного соглашения .COM и политики оценки услуг регистратур, не обнаружила существенных угроз безопасности или стабильности и вынесла предлагаемую поправку на общественное обсуждение.

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

      Принимая во внимание, что корпорация ICANN провела период общественного обсуждения предлагаемой поправки с 10 мая по 20 июня 2018 года, чтобы выполнить одобренную заявку Verisign на оказание услуги регистратуры и разрешить регистрацию односимвольного имени O.COM, а сводка и анализ поступивших комментариев были переданы Правлению.

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

      Принимая во внимание, что Правление ICANN

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

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

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

      Обоснование резолюции 2019.03.14.02

      Почему Правление решает этот вопрос сейчас?

      В ноябре 2017 года Verisign подала заявку на оказание услуги регистратуры чтобы получить разрешение на регистрацию доменного имени .COM, метка которого состоит из одного символа O.COM, путем проведения пробного аукциона и направить аукционную выручку на благо интернет-сообщества, в соответствии с принятой в ICANN Концепцией выделения односимвольных доменов второго уровня (SCSLD).

      Корпорация ICANN рассмотрела предлагаемую услугу регистратуры и не обнаружила существенных угроз безопасности или стабильности. Однако ICANN решила, что предлагаемая услуга регистратуры может затрагивать важные вопросы конкуренции. 7 декабря 2017 года корпорация ICANN передала вопрос для рассмотрения Министерству юстиции США. 14 декабря 2017 года Антимонопольный комитет Министерства юстиции США сообщил корпорации ICANN, что не собирается начинать расследование по данному вопросу.

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

      Был выполнен анализ предлагаемой поправки в соответствии с рекомендациями по односимвольным доменным именам, которые дали Рабочая группа GNSO по зарезервированным именам, Совет GNSO и корпорация ICANN. Также были приняты во внимание комментарии сообщества и резолюции Правления ICANN об одобрении регистрации односимвольных доменных имен в других исторических доменах верхнего уровня общего пользования (gTLD). На сегодняшний день Правление ICANN уже одобряло регистрацию односимвольных доменных имен во многих исторических gTLD, включая .ORG, .BIZ, .INFO, .MOBI и .PRO. Кроме того, односимвольные имена не подлежат резервированию в gTLD, созданных в рамках Программы New gTLD.

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

      Какое предложение рассматривается?

      В соответствии с предлагаемой поправкой односимвольное доменное имя O.COM будет выделено путем проведения аукциона и его администратором станет сторонний поставщик услуг. Verisign не получит прямо или косвенно никаких доходов от продажи, выделения, передачи или продления регистрации доменного имени O.COM и получит только стандартный сбор регистратуры за регистрацию O.COM в размере $7,85. Выручка от продажи O.COM на аукционе будет перечислена одной или нескольким некоммерческим организациям или их правопреемникам, деятельность которых направлена во благо интернет-сообщества. Аукционная выручка никоим образом не будет прямо или косвенно использоваться в интересах Verisign, ее аффилированных лиц или директоров, должностных лиц или сотрудников. Любой потенциальный владелец домена может принять участие в аукционе и выбрать любого аккредитованного ICANN регистратора для управления зарегистрированным именем, если получит имя O.COM. Выбор регистратора, аккредитованного ICANN, этим владельцем домена никоим образом не ограничивается.

      Выигравший аукцион владелец домена обязан: (i) перечислить полную сумму выигравшей ставки в течение 14 (четырнадцати) календарных дней, начиная с даты, когда его признали победителем, и (ii) взять на себя обязательство ежегодно перечислять Фонду по 5% (пять процентов) Первого взноса по выигравшей ставке за каждый год продления регистрации доменного имени, по истечении первых 5 (пяти) лет срока регистрации (каждый такой платеж — «Последующий взнос»), пока срок регистрации односимвольного доменного имени выигравшим аукцион владельцем домена не достигнет 25 (двадцати пяти) лет включительно. Очередные взносы призваны стимулировать непрерывный поток финансирования некоммерческой организации (некоммерческих организаций) вплоть до истечения срока выплаты Последующих взносов. Например, если аукцион был проведен в 2020 году и выигравшая ставка составила $10 000, размер первого взноса по выигравшей ставке для этого односимвольного доменного имени составил бы $10 000 и подлежал бы уплате в 2020 году, а размер ежегодного последующего взноса по истечении первоначального срока в 5 (пять) лет составил бы $500 (то есть по 5% первого взноса по выигравшей ставке) и подлежал бы уплате с 2026 по 2045 год включительно.

      С какими заинтересованными сторонами или иными лицами были проведены консультации?

      Корпорация ICANN провела период общественного обсуждения предлагаемой поправки с 10 июня по 20 июня 2018 года. Поступило 29 (двадцать девять) комментариев к этому предложению от 24 (двадцати четырех) организаций.

      Какие вызывающие озабоченность вопросы или проблемы были подняты сообществом?

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

      1. Заявления о поддержке предлагаемой для регистрации O.COM поправки.
      2. Опасения, что O.COM может создать угрозу безопасности и стабильности.
      3. Опасения по поводу того, что «пробные» условия отмены резервирования O.COM могут создать прецедент для будущей отмены резервирования всех односимвольных доменных имен во всем пространстве имен .COM.
      4. Опасения, что предлагаемые Verisign «Последующие взносы», уплачиваемые владельцем домена за продление срока регистрации O.COM, могут быть для Verisign средством увеличения стоимости продления регистрации доменов во всем пространстве имен .COM.
      5. Обеспокоенность по поводу предлагаемого компанией Verisign ограничения возможности переноса доменного имени O.COM после его выделения.
      6. Озабоченность в связи с отсутствием в предлагаемой поправке определенных механизмов защиты прав при отмене резервирования O.COM.
      7. Опасения по поводу возможности введения ограничений организатором торгов в отношении процедуры проведения аукциона и предварительных квалификационных требований к его участникам, которого Verisign предлагает использовать при продаже O.COM, и непрозрачность процесса.
      8. Предложения касательно распределения средств после аукционной продажи O.COM в соответствии с предлагаемой поправкой.

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

      Двое авторов комментариев высказали предположение, что O.COM, если будет зарегистрирован, может создать угрозы безопасности и стабильности в пространстве имен .COM. Более того, авторы комментариев выразили озабоченность по поводу предлагаемого Verisign подхода к проведению аукциона и регистрации доменного имени O.COM, по поводу того, что предлагаемые для O.COM требования не согласуются с текущим подходом к регистрации и продлению доменных имен .COM, и по поводу отсутствия определенных мер защиты при регистрации O.COM.

      Основной темой опасений в части безопасности и стабильности, которые высказывались в период общественного обсуждения, была возможность «путаницы из-за внешнего сходства строк на разных алфавитах» при регистрации односимвольного доменного имени O.COM на латинице, учитывая, что варианты O.COM на греческом и кириллице уже есть в пространстве имен .COM. После выполнения внутренней оценки было установлено, что риск не больше, чем для других односимвольных доменных имен, которые уже разрешено регистрировать в других TLD.

      В нескольких комментариях выражались опасения, что предложенные условия отмены резервирования O.COM могут создать прецедент для будущей отмены резервирования всех односимвольных доменных имен во всем пространстве имен .COM. В частности, авторы комментариев высказали мнение, что предлагаемый Verisign «Последующий взнос», уплачиваемый владельцем домена за продление регистрации O.COM, дает Verisign возможность ввести в будущем премиальные сборы за регистрацию или продление регистрации других односимвольных доменных имен в пространстве имен .COM или всех доменных имен .COM. Корпорация ICANN отмечает, что RSEP и предлагаемая Verisign поправка к Соглашению об администрировании домена верхнего уровня .COM гарантируют, что Verisign получит только стандартный сбор регистратуры за первичную регистрацию O.COM и все последующие продления срока регистрации, которые должны соответствовать положениям раздела 7.3(d) Соглашения об администрировании домена верхнего уровня .COM, регламентирующим ценообразование. На дату подачи предложения размер этого сбора регистратуры, определенный как Максимальная цена в Соглашении об администрировании домена верхнего уровня .COM, составляет $7,85. Единственный сбор за продление регистрации, который сможет получить Verisign, — это стандартный сбор за продление, действующий в момент продления. «Последующий взнос», который обязан уплатить владелец домена, выигравший аукцион, призван «стимулировать непрерывный поток финансирования некоммерческой организации (некоммерческих организаций) вплоть до истечения срока выплаты Последующих взносов».

      Авторы комментариев также выразили обеспокоенность по поводу предлагаемого Verisign ограничения возможности переноса доменного имени O.COM после его выделения и высказали мнение, что это создает ненужные сложности в пространстве имен .COM. Кроме того, авторы комментариев выразили обеспокоенность, что, если это ограничение будет признано допустимым, Verisign могла бы распространить это ограничение на все односимвольные доменные имена, которые после отмены резервирования могут быть зарегистрированы в пространстве имен .COM. Авторы комментариев отмечали, что из-за малого количества односимвольных доменов в пространстве имен .COM выигравшему аукцион владельцу домена следует разрешить использовать это имя по своему усмотрению. После ознакомления с результатами общественного обсуждения Verisign в добровольном порядке отказалась от включенного ранее в состав поправки предложения ограничить передачу домена другому владельцу.

      Также выражались опасения по поводу отсутствия определенных механизмов защиты прав (RPM), применимых к регистрации O.COM, и по поводу возможности возникновения угроз безопасности и стабильности после добавления O.COM в пространство имен .COM. Однако в Соглашении об администрировании домена верхнего уровня .COM не предусмотрено требование проводить период ранней регистрации перед отменой резервирования любых имен. Кроме того, поданные и впоследствии одобренные Правлением запросы RSEP о выдаче разрешения на регистрацию односимвольных и двухсимвольных зарезервированных имен .BIZ (2008 год), .INFO (2010 год) и .ORG (2011 год) не предусматривали проведение периода ранней регистрации. Для урегулирования споров, возникающих по причине выделения какого-либо имени в пространстве имен .COM, включая O.COM, есть Единая политика разрешения споров о доменных именах (UDRP).

      Какие важные материалы были рассмотрены Правлением?

      В ходе обсуждений Правление рассмотрело множество различных материалов, в том числе следующие материалы и документы:

      Какие факторы Правление сочло значимыми?

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

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

      Правление также с пониманием относится к опасениям некоторых членов сообщества по поводу возможности возникновения «путаницы из-за внешнего сходства строк на разных алфавитах» из-за регистрации односимвольного доменного имени O.COM и угроз безопасности и стабильности по причине регистрации этого односимвольного доменного имени. Однако Правление признает, что сегодня уже есть другие односимвольные доменные имена как в исторических, так и в новых gTLD, и сообщество продолжает работу по смягчению возможных проблем безопасности и стабильности из-за совпадения доменных имен, для которых используются разные алфавиты. К результатам такой работы относится версия 4.0 Руководящих принципов внедрения интернационализированных доменных имен (Руководство по IDN-доменам, версия 4). В этом документе, который был опубликован рабочей группой по разработке руководящих принципов для IDN-доменов (IDNGWG), рекомендованы практические методы, позволяющие максимально снизить риск киберсквоттинга и обмана потребителей. Правление отмечает, что в проекте четвертой версии Руководства по IDN-доменам «регистратурам TLD рекомендуется вводить дополнительные ограничения регистрации, снижающие вероятность путаницы из-за внешнего совпадения строк на разных алфавитах…», но не предлагаются конкретные обязательные меры по смягчению ситуации. Кроме того, документ «Руководство по IDN-доменам, версия 4» еще не одобрен Правлением. Корпорация ICANN старается придерживаться действующих процедур и политики и вводит новые требования по рекомендациям сообщества только после их утверждения и реализации. Правление недавно — на семинаре в Женеве в сентябре 2018 года — обсуждало вопрос о том, как корпорация ICANN должна обрабатывать запросы, поступающие от сторон, связанных договорными обязательствами, в условиях, когда результатом текущей работы сообщества может стать изменение процесса, способное повлиять на этот запрос.

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

      Правление далее принимает к сведению опасения, которые высказывались по поводу предусмотренного в поправке аукциона и процедуры его проведения в целом, и отмечает, что предлагаемая процедура проведения аукциона аналогична той, что используется большинством операторов регистратур. Кроме того, операторы регистратур исторических TLD, таких как .BIZ, .INFO и .ORG, использовали аналогичные процедуры для аукционной продажи своих односимвольных и двухсимвольных имен. Все операторы регистратур, исторических и новых gTLD, могут определить процедуру и проводить аукционы без контроля и ограничений для своих TLD и редко заранее раскрывают сведения о своем аукционе или о комиссии, уплачиваемой организатору аукциона.

      Правление также с пониманием относится к опасениям по поводу предлагаемого Verisign плана регистрации O.COM без RPM, которые операторы регистратур новых gTLD обязаны поддерживать в своих TLD. По мнению авторов комментариев, при регистрации O.COM Verisign должна иметь те же обязанности, что и операторы регистратур новых gTLD, то есть провести 90-дневный период ранней регистрации. Хотя Правление признает обеспокоенность некоторых членов сообщества в связи с предложенным Verisign планом регистрации O.COM в отсутствие RPM, в Соглашении об администрировании домена верхнего уровня .COM не предусмотрено требование проводить период ранней регистрации перед отменой резервирования любых имен. Кроме того, поданные для внесения поправок в соглашения об администрировании домена верхнего уровня и впоследствии одобренные Правлением запросы RSEP о выдаче разрешения на регистрацию односимвольных и двухсимвольных зарезервированных имен .BIZ (2008 год), .INFO (2010 год) и .ORG (2011 год) не предусматривали проведение периода ранней регистрации. Для урегулирования споров, возникающих по причине выделения какого-либо имени в пространстве имен .COM, включая O.COM, есть Единая политика разрешения споров о доменных именах (UDRP).

      Ожидаются ли положительные или отрицательные последствия для сообщества?

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

      Имеются ли финансовые последствия для корпорации ICANN (стратегический план, план операционной деятельности, бюджет), сообщества и/или общественности?

      При отмене резервирования и регистрации O.COM не должно возникнуть никаких существенных финансовых последствий для корпорации ICANN.

      Существуют ли какие-либо проблемы безопасности, стабильности или отказоустойчивости, относящиеся к DNS?

      Как указано выше, вопрос о том, может ли регистрация имени O.COM создать угрозу безопасности или стабильности, поднимался в период общественного обсуждения. В частности, высказывались опасения, что при регистрации односимвольного доменного имени O.COM на латинице может возникнуть «путаница из-за внешнего сходства строк на разных алфавитах», так как варианты O.COM на греческом и кириллице уже есть в пространстве имен .COM. Также утверждалось, что регистрация O.COM, возможно, противоречит проекту документа «Руководство по IDN-доменам, версия 4». Корпорация ICANN подтвердила Правлению, что в проекте четвертой версии Руководства по IDN-доменам «регистратурам TLD рекомендуется вводить дополнительные ограничения регистрации, снижающие вероятность путаницы из-за внешнего совпадения строк на разных алфавитах…», но не предлагаются конкретные обязательные меры по смягчению ситуации. Так что регистрация O.COM не противоречила бы документу «Руководство по IDN-доменам, версия 4». Кроме того, документ «Руководство по IDN-доменам, версия 4» еще не одобрен Правлением, поскольку корпорация ICANN продолжает составлять план реализации, чтобы обеспечить плавный переход к использованию новых руководящих принципов. В документе «Руководство по IDN-доменам, версия 4» признается необходимость считать такие домены исключениями: «Когда уже существующее доменное имя требует, чтобы регистратура внесла исключение в эти принципы на переходный период, необходимо опубликовать в интернете легкодоступные условия принятых мер, в том числе срок решения таких вопросов переходного периода». Следует ожидать, что Verisign в установленном порядке выполнит данное требование.

    3. Перенос срока соблюдения положений политики в области расширенного варианта записи данных WHOIS

      Принимая во внимание, что Политика перехода к использованию расширенного варианта записи данных WHOIS требует, чтобы Verisign начала принимать «расширенные» регистрационные данные от регистраторов доменных имен .COM и .NET с 30 ноября 2019 года, расширенный вариант регистрационных данных всех новых доменных имен начал передаваться в регистратуру не позднее 31 мая 2020 года, а все соответствующие регистрационные данные существующих доменных имен были переведены с минимального варианта на расширенный до 30 ноября 2020 года.

      Принимая во внимание, что при подготовке к окончательному внедрению системы приема расширенного варианта записи данных WHOIS компания Verisign, Inc. предложила внести поправки в соглашения между регистратурами и регистраторами для доменов .COM и .NET.

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

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

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

      Принимая во внимание, что благодаря отсрочке начала контроля за соблюдением требований у сообщества ICANN и Правления появится время для обсуждения итогового отчета группы по Ускоренному процессу формирования политики (EPDP) по Временной спецификации для регистрационных данных в gTLD.

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

      Принята резолюция (2019.3.14.03): президент и генеральный директор или назначенные им лица наделяются полномочиями отложить начало контроля за соблюдением политики перехода к использованию расширенного варианта записи данных WHOIS на 6 месяцев до 30 ноября 2019 года, 31 мая 2020 года и 30 ноября 2020 года, соответственно.

      Обоснование резолюции 2019.03.14.03

      Политика перехода к использованию расширенного варианта записи данных WHOIS определяет поэтапный подход к переводу регистратур .COM и .NET с минимального варианта записи данных WHOIS на расширенный. Предусмотрено три этапа:

      1. оператор регистратуры (RO) начинает принимать от регистраторов расширенный вариант записи данных WHOIS,
      2. при регистрации доменных имен .COM и .NET в регистратуру должен передаваться расширенный вариант записи данных и
      3. полный переход от минимального варианта записи данных WHOIS к расширенному для всех существующих регистрационных данных доменных имен через год после начала приема RO от регистраторов расширенного варианта записи данных WHOIS.

      Политика перехода к использованию расширенного варианта записи данных WHOIS требует, чтобы регистратор Verisign начал принимать «расширенные» регистрационные данные от регистраторов с 31 мая 2019 года, регистраторы предоставляли расширенные регистрационные данные для всех новых доменных имен Verisign с 30 ноября 2019 года, а все уже зарегистрированные доменные имена были переведены с минимального варианта на расширенный до 31 мая 2020 года. В процессе подготовки к внедрению расширенного варианта записи данных WHOIS от компании Verisign, оператора регистратуры доменов .COM и .NET, поступило предложение внести поправки в соглашения между регистратурами и регистраторами для доменов .COM и .NET, чтобы создать необходимую правовую основу для приема данных. Хотя согласованная политика в отношении расширенного варианта записи данных WHOIS распространяет действие на TLD .JOBS, оператору регистратуры .JOBS, компании Employ Media, не нужно вносить изменения в свое соглашение между регистратурой и регистраторами, чтобы начать прием расширенного варианта регистрационных данных, и регистраторы уже начали отправлять в Employ Media расширенный вариант регистрационных данных для .JOBS согласно этой политике.

      После завершения процедуры внесения поправок в соглашения между регистратурами и регистраторами корпорация ICANN организовала переговоры между Verisign и группой заинтересованных сторон-регистраторов для согласования предлагаемых поправок к соглашениям между регистратурами и регистраторами, но стороны пока не достигли договоренности. Кроме того, сообщество в рамках EPDP GNSO занимается формированием постоянной согласованной политики, которая должна заменить или подтвердить Временную спецификацию для регистрационных данных в gTLD.

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

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

      При обсуждении этого вопроса Правление, помимо прочего, опиралось на несколько важных материалов, которые перечислены ниже:

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

      Данное решение принято в рамках выполнения организационно-административной функции и не требует общественного обсуждения.

    4. Назначение независимых аудиторов на 2019 ФГ

      Принимая во внимание, что раздел 22.2 Устава ICANN (http://www.icann.org/general/bylaws.htm) требует по окончании финансового года обязательно провести аудиторскую проверку финансовых документов ICANN с привлечением лицензированных общественных бухгалтеров, назначаемых Правлением.

      Принимая во внимание, что Аудиторский комитет Правления обсудил вопрос использования услуг независимого аудитора по проверке материалов за финансовый год, заканчивающийся 30 июня 2019 года, и рекомендовал Правлению уполномочить президента и генерального директора или назначенных им лиц принять все необходимые меры для привлечения аудиторской фирмы BDO LLP и фирм-членов группы BDO.

      Принята резолюция (2019.03.14.04): Правление уполномочивает президента и генерального директора или назначенных им лиц выполнить все необходимые действия, чтобы привлечь компанию BDO LLP и фирмы, входящие в состав группы BDO, в качестве аудиторов для проверки финансовых отчетов за финансовый год, заканчивающийся 30 июня 2018 года.

      Обоснование резолюции 2019.03.14.04

      Аудиторская фирма BDO LLP и фирмы-члены группы BDO привлекаются в качестве независимых аудиторов ICANN, начиная с 2014 финансового года. Исходя из отчета корпорации, а также из оценки выполненной работы аудиторским комитетом, комитет принял решение рекомендовать Правлению уполномочить президента и генерального директора или назначенных им лиц предпринять все меры, необходимые для привлечения компании BDO LLP и фирм-членов группы BDO в качестве независимого аудитора для проведения ежегодной проверки материалов ICANN за 2019 финансовый год, с учетом всех требований к проведению ежегодных независимых аудиторских проверок в разных юрисдикциях.

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

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

      Это организационно-административная функция, не требующая общественного обсуждения.

    5. Одобрение поправок к уставу Комитета Правления по организационной эффективности

      Принимая во внимание, что в настоящее время на Комитет Правления по организационной эффективности возложена задача надзора за организационными проверками, предусмотренными в Уставе ICANN. В соответствии со статьей 18 Устава ICANN, вступившего в силу после передачи координирующей роли в исполнении функций IANA, ICANN также отвечает за организацию периодических и особых проверок исполнения функций IANA в отношении имен, которые направлены на анализ показателей работы PTI согласно контракту на исполнение функций IANA в отношении имен и описанию работ по исполнению функций IANA в отношении имен. В настоящий момент в Правлении нет комитета, которому поручен надзор за процессами проверки исполнения функций IANA в отношении имен (IFR).

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

      Принимая во внимание, что Комитет Правления по управлению, которому поручено рассматривать уставы комитетов, принимает предложение OEC и рекомендует Правлению утвердить пересмотренный устав OEC.

      Принята резолюция (2019.03.14.05): Правление утверждает предлагаемые поправки к уставу своего Комитета по организационной эффективности.

      Обоснование резолюции 2019.03.14.05

      Почему Правление занимается решением этого вопроса?

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

      Какое предложение рассматривается?

      Комитет Правления по организационной эффективности (OEC) предлагает возложить на него обязанность надзора за процессами проверки исполнения функций IANA в отношении имен (IFR). OEC готов взять на себя такую обязанность надзора за IFR, учитывая свои текущие обязанности в связи с проведением особых и организационных проверок.

      Какие важные материалы были рассмотрены Правлением?

      Правление рассмотрело предложенные поправки к уставу OEC в редакции 2017 года. См. справочные материалы, Приложение A (версия с изменениями) и Приложение B (чистая версия).

      Ожидаются ли положительные или отрицательные последствия для сообщества?

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

      Имеются ли финансовые последствия для ICANN (для стратегического плана, операционного плана, бюджета), сообщества и/или общественности?

      Предлагаемые изменения не приведут к финансовым последствиям для стратегического плана или операционного плана ICANN.

      Существуют ли какие-либо проблемы безопасности, стабильности или отказоустойчивости, относящиеся к DNS?

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

      Почему это решение находится в пределах миссии ICANN и каким общественным интересам оно служит?

      Это решение Правления согласуется с обязательством ICANN, закрепленным в статье 18 Устава: обеспечить исполнение организацией PTI функций IANA в отношении имен в соответствии с контрактными требованиями, которые сформулированы в контракте на исполнение функций IANA в отношении имен и описании работ по исполнению функций IANA в отношении имен. Это решение послужит общественным интересам, так как обеспечит надзор со стороны Правления ICANN соблюдением корпорацией ICANN и PTI обязательства обеспечивать исполнение функций IANA в отношении имен в соответствии с ожиданиями клиентов и всего сообщества ICANN.

      Необходимо ли перед принятием Правлением решения провести общественное обсуждение?

      Общественное обсуждение не требуется.

    6. Назначение представителя оператора корневого сервера в RSSAC

      Принимая во внимание, что Устав ICANN предусматривает необходимость создания Консультативного комитета системы корневых серверов (RSSAC), функция которого состоит в состоит в предоставлении сообществу и Правлению ICANN рекомендаций в отношении работы, безопасности и целостности системы корневых серверов интернета и управления ею.

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

      Принимая во внимание, что в феврале 2019 года, организация Réseaux IP Européens Network Coordination Centre (RIPE NCC) попросила сменить своего представителя до конца срока действия полномочий, истекающего 31 декабря 2020 года.

      Принимая во внимание, что сопредседатели RSSAC рекомендовали Правлению ICANN назначить представителя RIPE NCC в состав RSSAC.

      Принята резолюция (2019.03.14.06): Правление ICANN назначает Каве Ранджбара членом RSSAC по 31 декабря 2020 года включительно.

      Обоснование резолюции 2019.03.14.06

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

      В феврале 2019 года RIPE NCC попросила сменить своего представителя до конца срока действия полномочий, истекающего 31 декабря 2020 года.

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

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

    7. Утверждение поправки к контракту на исполнение функций IANA в отношении имен

      Принимая во внимание, что Устав ICANN (раздел 16.3) обязывает ICANN и PTI сохранять Контракт на исполнение функций IANA в отношении имен, в соответствии с которым эти функции выполняет PTI. Первый Контракт на исполнение функций IANA в отношении имен был одобрен Правлением ICANN и Правлением PTI в 2016 году при передаче координирующей роли в исполнении функций IANA.

      Принимая во внимание, что в настоящее время Контракт на исполнение функций IANA в отношении имен содержит таблицу с подробным описанием рабочих соглашений об уровне обслуживания («Таблица SLA»), согласованных с сообществом многих заинтересованных сторон в процессе передачи координирующей роли в исполнении функций IANA.

      Принимая во внимание, что корпорация ICANN, PTI и Постоянный комитет потребителей (CSC) признали, что менять Контракт на исполнение функций IANA в отношении имен всякий раз, когда возникнет необходимость изменения, добавления или удаления того или иного SLA, нецелесообразно и это не отвечает потребностям ICANN, PTI или клиентов, использующих функции IANA. По этой причине было предложено внести однократное изменение в Контракт на исполнение функций IANA в отношении имен, чтобы исключить из его состава Таблицу SLA, а также ввести требование соблюдать одобренный сообществом и опубликованный «Процесс внесения поправок в соглашения об уровне обслуживания при исполнении функций IANA в отношении имен» для любого изменения SLA.

      Принимая во внимание, что корпорация ICANN, PTI и CSC участвовали в разработке Процесса внесения поправок в соглашения об уровне обслуживания при исполнении функций IANA в отношении имен, и CSC проинформировал об этом процессе потребителей функций IANA, относящихся к именам.

      Принимая во внимание, что ICANN провела общественное обсуждение предлагаемой поправки к Контракту на исполнение функций IANA в отношении имен с 7 января по 18 февраля 2019 года.

      Принимая во внимание, что форум общественного обсуждения предлагаемой поправки к Контракту на исполнение функций IANA в отношении имен закрылся 18 февраля 2018 года и ICANN получила всего один комментарий от Группы заинтересованных сторон-регистратур в поддержку предложенной поправки. Сводный анализ результатов общественного обсуждения был опубликован 25 февраля 2019 года и передан Правлению.

      Принята резолюция (2019.03.14.07): утвердить Поправку № 1 к Контракту на исполнение функций IANA в отношении имен IANA и уполномочить президента и генерального директора или назначенных им лиц принять надлежащие меры для доработки и заключения этого соглашения.

      Обоснование резолюции 2019.03.14.07

      Постоянный комитет потребителей (CSC), в сотрудничестве с корпорацией ICANN и PTI рекомендовал внести изменения на основании накопленных в процессе работы данных. Было признано, что для переноса SLA из договора в Таблицу SLA на странице PTI необходимо определить порядок внесения изменений в SLA, предусматривающий необходимые консультации с потребителями функций IANA в отношении имен и всем сообществом ICANN.

      На своем заседании, состоявшемся 17 декабря 2018 года, CSC одобрил два процесса изменения SLA: «Процесс внесения поправок в соглашения об уровне обслуживания при исполнении функций IANA в отношении имен» и «Процедуру изменения процесса внесения поправок в соглашения об уровне обслуживания при исполнении функций IANA в отношении имен». Корпорация ICANN и руководство PTI приняли участие в обсуждении и тоже одобрили эти процессы. Эти процессы вступят в силу только тогда, когда возникнет необходимость изменить контракт на исполнение функций IANA.

      Правление утверждает поправку к Контракту на исполнение функций IANA в отношении имен сейчас, потому что переход от соглашений об уровне обслуживания, входящих в состав Контракта на исполнение функций IANA, к таблице SLA на веб-странице повышает эффективность процедуры изменения SLA, что отвечает потребностям клиентов. При этом соблюдение нового «Процесса внесения поправок в соглашения об уровне обслуживания при исполнении функций IANA в отношении имен» обеспечивает использование для всех таких изменений строгой процедуры, гарантирующей проведение консультаций с сообществом в необходимом объеме и достижение согласия между CSC и ICANN/PTI.

      Это решение Правления принимается с учетом комментариев сообщества, поддержавшего внесение поправки через CSC, а также комментария RySG во время общественного обсуждения, который гласит: «Эта поправка к Контракту на исполнение функций IANA в отношении имен обеспечивает установление порядка внесения изменений в SLA, который был совместно определен и согласован CSC, PTI и корпорацией ICANN. Порядок внесения изменений в SLA позволит CSC и PTI а) изменять соглашения об уровне обслуживания по мере необходимости, б) добавлять новые SLA при внедрении новых услуг и в) удалять SLA, которые больше не гарантируются. RySG поддерживает поправку и просит Правление ICANN одобрить ее, чтобы можно было в кратчайшие сроки изменить, добавить или удалить те SLA, в отношении которых назрела необходимость в таких операциях».

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

    8. Выражение благодарности местному организатору 64-й конференции ICANN

      Правление благодарит г-жу Юкари Сато (Yukari Sato), министра внутренних дел и коммуникаций, г-на Кидзо Хисамото (Kizō Hisamoto), мэра города Кобе, проф. Юна Мураи (Jun Murai), председателя и членов Комитета принимающей стороны ICANN64, GMO Internet Inc., Japan Registry Services Co. Ltd., Internet Initiative Japan Inc., Интернет-ассоциацию Японии, Internet Multifeed Co., Interlink Co. Ltd., NTT Docomo Inc., Ассоциацию поставщиков телекоммуникационных услуг, Сетевой информационный центр Японии, BusinessRalliart Inc., Киотский колледж последипломного образования по информатике, Com Laude Corporation (представительство в Японии), Taka Enterprise Ltd., Ассоциацию интернет-провайдеров Японии, WIDE Project, NTT Communications Corporation, KDDI Corporation, Nippon Telegraph and Telephone West Corporation. Правление также благодарит Министерство внутренних дел и коммуникаций, Kobe Convention Bureau и Tsutomu Nakauchi Foundation за огромную поддержку.

    9. Выражение благодарности спонсорам 64-й конференции ICANN

      Правление хочет поблагодарить следующих спонсоров: Verisign, Регистратура доменов общественного характера, Afilias plc и CentralNic.

    10. Выражение благодарности переводчикам, персоналу, группе поддержки мероприятий и сотрудникам гостиницы, обеспечившим возможность проведения 64-й конференции ICANN

      Правление выражает свою глубочайшую благодарность секретарям, переводчикам, группе аудиовизуальной поддержки, техническому персоналу, а также всему персоналу ICANN за их усилия по обеспечению бесперебойной работы конференции. Правление также хочет поблагодарить руководство и персонал гостиницы Kobe Portopia и Международного конференц-центра Кобе, предоставивших замечательное место для проведения этого мероприятия. Особую благодарность заслужили: сотрудники Международного конференц-центра Кобе, Омура Масатоси (Omura Masatoshi), Рикако Наканиси (Rikako Nakanishi), Айя Фукуда (Aya Fukuda), Эйджи Макасуджи (Eiji Makatsuj), Юко Сикумару (Yuko Zikumaru), Тесуя Шори (Tetsuya Shori) и Ланс Фергюсон (Lance Ferguson) и персонал гостиницы Kobe Portopia из отдела по организации мероприятий и ИТ-отдела, Хитоси Накаучи (Hitoshi Nakauchi), Сюоси Ито (Tsuyoshi Ito), Такахико Кисимото (Takahiko Kishimoto), Кенджи Кино (Kenji Kino), Синго Мураками (Shingo Murakami), Такуми Нисихара (Takumi Nishihara), Томоко Нисио (Tomoko Nishio), Томоя Такеда (Tomoya Takeda), Макото Сакаи (Makoto Sakai), Сохей Инои (Shohei Inoue), Йосуке Танигучи (Yosuke Taniguchi), Росе Танасугарн (Rose Tanasugarn) и Гилберт Йео (Gilbert Yeo), директор Pryde Productions.

    Все присутствующие члены Правления проголосовали за принятие резолюций 2019.03.14.01, 2019.03.14.02, 2019.03.14.03, 2019.03.14.04, 2019.03.14.05, 2019.03.14.06 и 2019.03.14.07. Резолюции были приняты.

  2. Основная повестка дня:

    Председатель открыл рассмотрение основной повестки дня.

    1. Рекомендации в отношении управления вариантами IDN-доменов верхнего уровня

      Акинори Маемура вынес на рассмотрение этот пункт повестки дня. Зачитав предлагаемую резолюцию для занесения в протокол, Акинори сообщил, что эта предлагаемая резолюция — результат работы, в которой сообщество приняло огромное участие. Теперь Правлению предлагается одобрить подготовленные рекомендации и предложить ccNSO и GNSO учитывать их при разработке своей политики в области определения и управления вариантами IDN-доменов верхнего уровня для действующих TLD, а также для будущих заявок.

      Акинори выдвинул, а Данко Йевтович поддержал резолюцию. После этого председатель предложил проголосовать и Правление приняло следующее решение:

      Принимая во внимание, что интернационализированные доменные имена (IDN) позволяют интернет-пользователям получать доступ к доменным именам на их языке и остаются ключевым компонентом работы ICANN.

      Принимая во внимание, что Правление признает, что варианты IDN-доменов верхнего уровня являются важным компонентом некоторых строк IDN-доменов верхнего уровня (TLD) и что внедрение вариантов меток в корневую зону должно состояться таким образом, чтобы сохранить безопасность и стабильность DNS.

      Принимая во внимание, что в 2010 году Правление приняло резолюцию о том, что варианты IDN-доменов верхнего уровня не будут делегироваться до завершения соответствующей работы и поручило корпорации ICANN составить отчет с указанием действий, необходимых для оценки, возможного выделения и эксплуатации доменов общего пользования (верхнего уровня), содержащих IDN с вариантными символами, чтобы содействовать разработке осуществимых подходов к развертыванию gTLD, содержащих IDN с вариантными символами.

      Принимая во внимание, что на основе шести примеров из практики, вошедших в исследование проблем, связанных с управлением вариантами IDN-доменов верхнего уровня, 2012 года, корпорация ICANN и сообщество выявили две проблемы, которые нуждались в решении: первая — отсутствие определения варианта IDN-домена верхнего уровня; вторая — отсутствие механизма управления вариантами IDN-доменов верхнего уровня.

      Принимая во внимание, что Процедура разработки и поддержки правил генерирования меток корневой зоны с учетом меток IDNA (Процедура (RZ-LGR) была разработана сообществом с целью дать определение вариантам IDN-доменов верхнего уровня, а также в результате принятой в 2013 году резолюции, которая утвердила реализацию процедуры RZ-LGR по постепенной разработке правил генерирования меток корневой зоны для устранения первой проблемы.

      Принимая во внимание, что корпорация ICANN разработала рекомендации в отношении управления вариантами IDN-доменов верхнего уровня (Рекомендации в отношении вариантных доменов верхнего уровня), после внедрения комментариев, оставленных в период общественного обсуждения, было окончательно подготовлено и опубликовано шесть документов в качестве механизмов решения второй проблемы, выявленной сообществом в процессе реализации вариантов IDN-доменов верхнего уровня.

      Принята резолюция (2019.03.14.08): Правление утверждает рекомендации в отношении вариантных доменов верхнего уровня и просит ccNSO и GNSO принять во внимание эти рекомендации при разработке своей политики в области определения и управления вариантами IDN-доменов верхнего уровня для действующих TLD, а также для будущих заявок.

      Принята резолюция (2019.03.14.09): Правление просит ccNSO и GNSO информировать друг друга о прогрессе в разработке соответствующих деталей их политики и процедур, чтобы обеспечить выработку единого решения в отношении вариантов национальных интернационализированных IDN-доменов верхнего уровня и вариантов IDN-доменов общего пользования верхнего уровня.

      Принята резолюция (2019.03.14.10): Правление также отдает должное масштабной работе, проделанной сообществом, и его вкладу с начала проекта по решению вопросов, связанных с вариантами IDN-доменов, в 2011 году, которые позволили разработать рекомендации в отношении вариантных доменов верхнего уровня.

      Все присутствующие члены Правления проголосовали за принятие резолюций 2019.03.14.08, 2019.03.14.09 и 2019.03.14.10. Резолюции были приняты.

      Обоснование резолюций 2019.03.14.08 – 2019.03.14.10

      Интернационализированные доменные имена (IDN-домены) дают людям всего мира возможность использовать доменные имена на местных языках и алфавитах. Некоторые сообщества, использующие один и тот же набор символов, выяснили, что разные с технической точки зрения метки доменов могут оказаться неотличимыми от меток других доменов. Такие «одинаковые» метки называются вариантными. Стандарт для IDN-доменов в приложениях (IDNA) 2008 года, хотя и оговаривал порядок использования доменных имен на нескольких алфавитах, также предлагал в RFC 58941, чтобы «регистратуры определили и применяли по мере необходимости дополнительные ограничения, снижающие вероятность возникновения путаницы и смягчающие другие проблемы … В случае многих алфавитов применение методов работы с вариантами … может способствовать сокращению количества проблем с точки зрения пользователей. … Как правило, пользователи выигрывают, если регистратуры разрешают использовать символы только из тех наборов, которые понятны регистратуре или ее консультантам».

      Согласно стандарту IDNA2008, необходимо как минимум идентифицировать вариантные метки и управлять ими, чтобы защитить конечных пользователей от угроз безопасности. Несколько обнаруженных вариантных меток можно даже активировать, чтобы повысить удобство использования IDN-доменов, поскольку разные языковые сообщества использующие набор символов могут использовать разные вариантные метки. В ряде случаев в приложениях для IDN ccTLD и новых gTLD идентифицированы дополнительные метки, считающиеся вариантными, что позволяет сообществу считать такие разные метки взаимозаменяемыми вариантами. Однако из-за отсутствия четкого определения и решения по их реализации Правление ICANN 25 сентября 2010 года постановило следующее: «пока не будет выработан надлежащий порядок управления вариантами, никакие варианты gTLD не будут делегироваться в рамках Программы New gTLD». Далее в этой резолюции персоналу ICANN дается распоряжение подготовить «отчет о неразрешенных проблемах с указанием объема работ по оценке, возможному делегированию, выделению и эксплуатации gTLD, содержащих IDN-домены с вариантными символами в рамках Программы New gTLD, чтобы облегчить поиск осуществимых подходов к внедрению таких gTLD».

      Достижение указанных целей в области безопасности и удобства в использовании при сохранении стабильности — ключевая задача. Чтобы справиться с этими сложными лингвистическими и техническими проблемами, корпорация ICANN под руководством Правления ICANN запустила Проект по решению вопросов, связанных с вариантами IDN-доменов. В качестве первого шага было налажено сотрудничество с экспертами из шести сообществ, использующих один и тот же набор символов, которые занялись анализом проблем с идентификацией вариантных меток для каждого из этих наборов символов. Результаты этого анализа, выполненного в 2011 году для арабского, китайского, кириллицы, деванагари, греческого и латинского алфавитов, объединенные в Комплексный отчет о проблемах (IIR) (2012 год) позволили обнаружить две трудности:

      1. «в современной среде DNS отсутствует общепринятое определение вариантной взаимосвязи между метками верхнего уровня,
      2. аналогичным образом отсутствует механизм управления вариантами для верхнего уровня, хотя он часто рекомендуется в качестве способа решения конкретной проблемы».

      1. Определение вариантных доменов верхнего уровня

      IIR содержал описание дополнительной работы, которую можно было бы выполнить. Для решения первой указанной в IIR проблемы сообществом была разработана Процедура определения и поддержки правил генерирования меток для корневой зоны в отношении меток IDNA («Процедура RZ-LGR»). На основании указания Правления ICANN от 11 апреля 2013 года, ICANN ввела двухэтапную Процедуру RZ-LGR, когда каждое сообщество должно определить индивидуальные Правила генерирования меток (LGR) для конкретного набора символов, а затем комиссия экспертов рассматривает эти предложения и включает каждое из них в состав LGR корневой зоны (RZ-LGR). Ряд сообществ, использующих один и тот же набор символов, уже подготовил свои предложения, при этом предложения для арабского, эфиопского, грузинского, кхмерского, лаосского и тайского алфавитов включены в состав второй версии RZ-LGR-2. Многие другие сообщества тоже активно работают над определением своих правил. Кроме того, в IETF разработана и выпущена спецификация для преобразования этой лингвистической информации в формальный, пригодный для машинного считывания формат. Это RFC 7940: Использование XML для представления наборов правил генерирования меток. Также разработан инструмент LGR, позволяющий создавать, использовать и управлять LGR. Он доступен сообществу онлайн и для скачивания как программное обеспечение с открытым исходным кодом.

      2. Анализ механизмов управления вариантными доменами верхнего уровня

      Правила генерирования меток для корневой зоны, подготовленные в соответствии с вышеописанным процессом, позволяют получить список меток TLD, являющихся кандидатами на выделение. Для удовлетворения второй половины потребностей, указанных в Комплексном отчете о проблемах, — создания механизма управления вариантами для верхнего уровня, сообществу ICANN нужно определить политику и процедуры, регулирующие выделение таких вариантных имен. В подготовленном после общественного обсуждения и опубликованном комплекте документов предлагаются рекомендации для рассмотрения в ccNSO и GNSO на этапе определения соответствующей политики и процедур в соответствии с их собственными процессами разработки политики (PDP). В указанных документах также анализируются рекомендации и их воздействие на процесс подачи и рассмотрения заявок на gTLD, описанный в Руководстве кандидата Программы New gTLD, и процесс подачи и рассмотрения заявок на IDN ccTLD, который определен в окончательном плане реализации Ускоренной процедуры рассмотрения заявок на регистрацию национальных IDN-доменов верхнего уровня. Основополагающими предпосылками представленных рекомендаций и анализа служат главным образом наблюдения сообщества, нашедшие отражение в Комплексном отчете о проблемах и рекомендациях, которые Консультативный комитет по безопасности и стабильности (SSAC) дал в отчете SAC 60.

      При выполнении анализа сотрудники корпорации ICANN неоднократно взаимодействовали с Рабочей группой Правления ICANN по IDN-доменам (BIWG), начиная с 2014 года, и BIWG координировал эту работу. Была поставлена цель дать осторожные рекомендации, с учетом того, что вариантные IDN-домены верхнего уровня создаются впервые, а для доработки решения с течением времени можно будет воспользоваться накопленным опытом.

      Правление ICANN отмечает, что работа над RZ-LGR идет полным ходом. Правление ICANN также отмечает, что первоначальный набор рекомендаций по осторожной и единообразной реализации вариантных IDN-доменов верхнего уровня ccNSO и GNSO смогут дополнительно рассмотреть в процессе своей работы по формированию соответствующей политики и процедур. Поскольку предварительные требования уже определены сообществом в Комплексном отчете о проблемах, организации поддержки (SO) теперь могут предпринять дальнейшие шаги.

      Это принесет пользу сообществу, хотя и сопряжено с некоторыми рисками. Как минимум, идентифицированные вариантные IDN-домены верхнего уровня не регистрируются, что повышает безопасность конечных пользователей до того времени, когда организациям поддержки возможно удастся определить жизнеспособный механизм управления. Кроме того, если ccNSO и GNSO удастся согласовать унифицированные механизмы управления вариантами, чтобы делегировать несколько вариантных меток, это может способствовать повышению удобства использования доменных имен разными сообществами, которым нужны такие вариантные IDN-домены верхнего уровня. Продолжение этой работы сопряжено с риском, особенно в том случае, если сообществу не удастся достигнуть договоренности о применении единого подхода ко всем TLD, поскольку это может стать источником путаницы для пользователей или даже угрожать их безопасности. Управление вариантными IDN-доменами верхнего уровня также может стать дополнительным бременем для владельцев доменов, как указал SSAC в своем отчете SAC060. После принятия резолюции ccNSO и GNSO должны будут определить собственные процедуры и политику реализации вариантных IDN-доменов верхнего уровня, с учетом подготовленных рекомендаций. Однако эта резолюция не содержит указаний ccNSO или GNSO сформировать политику по данному вопросу. Если и когда итоговые отчеты с рекомендациями по политике, разработанной с использованием соответствующих PDP, будут переданы Правлению ICANN для утверждения, Правление обсудит, насколько эти процедуры и политика соответствуют рекомендациям по вариантным доменам верхнего уровня, оценит последствия и соответствующие риски. На указанном этапе Правление решит, следует ли принять эти рекомендации по политике и перейти к реализации вариантных IDN-доменов верхнего уровня.

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

      Эти рекомендации способствуют безопасной и стабильной работе системы уникальных идентификаторов, удовлетворяют потребность в создании вариантных IDN-доменов верхнего уровня, о которой сообщило сообщество, и признают роль сообщества в выработке политики. Кроме того, работа над вариантными IDN-доменами верхнего уровня отвечает общественным интересам, расширяя доступ к системе доменных имен (DNS) на различных алфавитах и языках.

    2. Подготовка к реализации последующих процедур для новых gTLD

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

      После дискуссии председатель объявил об исключении этого пункта из повестки дня.

    3. Передача домена верхнего уровня .VU (Вануату) организации Telecommunications Radiocommunications and Broadcasting Regulator (TRBR).

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

      Найджел Робертс выдвинул, а Крис поддержал резолюцию. После этого председатель предложил проголосовать и Правление приняло следующее решение:

      Принята резолюция (2019.03.14.11): в рамках своих обязанностей по контракту с ICANN на исполнение функций IANA, PTI проанализировала и оценила запрос о передаче национального домена верхнего уровня .VU организации Telecommunications Radiocommunications and Broadcasting Regulator (TRBR). Согласно документам, при оценке данного запроса были соблюдены надлежащие процедуры.

      Все присутствующие члены Правления проголосовали за принятие резолюции 2019.03.14.11. Резолюция была принята.

      Обоснование резолюции 2019.03.14.11

      Почему Правление решает этот вопрос сейчас?

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

      Какое предложение рассматривается?

      Предлагается утвердить просьбу о передаче национального домена верхнего уровня .VU и назначении в качестве управляющей организации Telecommunications Radiocommunications and Broadcasting Regulator (TRBR).

      С какими заинтересованными сторонами или иными лицами были проведены консультации?

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

      Какие вызывающие озабоченность вопросы или проблемы были подняты сообществом?

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

      Какие важные материалы были рассмотрены Правлением?

      [ИНФОРМАЦИЯ СКРЫТА – КОНФИДЕНЦИАЛЬНАЯ ИНФОРМАЦИЯ, КАСАЮЩАЯСЯ ДЕЛЕГИРОВАНИЯ]

      Какие факторы Правление считает значимыми?

      Правление не выявило каких-либо конкретных факторов, вызывающих озабоченность в связи с данным запросом.

      Ожидаются ли положительные или отрицательные последствия для сообщества?

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

      Имеются ли финансовые последствия для ICANN (стратегический план, план операционной деятельности, бюджет), сообщества и/или общественности?

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

      Существуют ли какие-либо проблемы безопасности, стабильности или отказоустойчивости, относящиеся к DNS?

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

    4. Рассмотрение апелляции 16-5: DotMusic Limited

      Леон Санчес, председатель Комитета по осуществлению механизмов подотчетности Правления (BAMC), вынес этот пункт повестки дня на рассмотрение. Леон сообщил, что BAMC тщательно рассмотрел основания для Апелляции 16-5 и все соответствующие материалы и рекомендовал отклонить Апелляцию 16-5, поскольку провайдер Оценки приоритетности заявок от сообществ (CPE) не нарушал установленные процедуры или политику при выполнении CPE, равно как и корпорация ICANN, принимая отчет провайдера CPE, соблюдала установленную политику, Устав и учредительный договор. BAMC также рекомендовал Правлению отклонить Апелляцию 16-5 на том основании, что Податели апелляции не обнаружили неправильного использования политики или процедуры провайдером CPE, которое оказало на них существенное или негативное влияние. Таким образом, резолюция состоит в том, чтобы Правление приняло рекомендацию BAMC в отношении апелляции 16-5. При обсуждении этого вопроса Правлению были предоставлены все важные материалы по Апелляции 16-5.

      Бекки Берр сообщила, что не участвовала в рассмотрении этого вопроса из-за возможности возникновения конфликта интересов.

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

      Принимая во внимание, что компания DotMusic Limited (DotMusic) подала заявку от сообщества на домен .MUSIC («Заявка»), которая была включена в спорную группу вместе с другими заявками на домен .MUSIC.

      Принимая во внимание, что DotMusic участвовала в оценке приоритетности заявок от сообществ (CPE), но не получила преимущество.

      Принимая во внимание, что DotMusic, Международная федерация музыкантов, Международная федерация художественных советов и культурных агентств, Worldwide Independent Network, Merlin Network, Independent Music Companies Association, American Association of Independent Music, Association of Independent Music, Content Creators Coalition, Nashville Songwriters Association International и ReverbNation (в совкупности «Податели апелляции») подали Апелляцию 16-5, требуя пересмотреть отчет CPE по своей заявке и решение корпорации ICANN принять данный отчет.

      Принимая во внимание, что в тот период, когда Апелляция 16-5 находилась на рассмотрении, Правление поручило корпорации ICANN провести проверку процесса CPE («Проверка процесса CPE»). Комитет Правления по управлению (BGC) решил до завершения Проверки процесса CPE приостановить оценку рассматриваемых апелляций, относящихся к процессу CPE, в том числе Апелляции 16-5.2

      Принимая во внимание, что 13 декабря 2017 года корпорация ICANN опубликовала три отчета о проверке процесса CPE («Отчеты о проверке процесса CPE»).

      Принимая во внимание, что 15 марта 2018 года Правление приняло резолюции 2018.03.15.08 – 2018.03.15.11, в которых одобрило и приняло выводы, сформулированные в Отчетах о проверке процесса CPE; объявило о завершении Проверки процесса CPE; на основании результатов, изложенных в Отчетах о проверке процесса CPE, пришло к выводу, что в текущем раунде Программы New gTLD процесс CPE не будет пересматриваться или меняться; дало указание Комитету по осуществлению механизмов подотчетности Правления (BAMC) продолжить рассмотрение оставшихся апелляций, относящихся к процессу CPE, которое было приостановлено до завершения Проверки процесса CPE.

      Принимая во внимание, что в соответствии с резолюциями 2018.03.15.08 – 2018.03.15.11 BAMC предложил Подателям апелляции представить дополнительные материалы и выступить перед BAMC с докладом в обоснование Апелляции 16-5. Податели апелляции отклонили оба предложения BAMC.

      Принимается во внимание, что BAMC тщательно рассмотрел основания для Апелляции 16-5 и все соответствующие материалы и рекомендовал отклонить Апелляцию 16-5, поскольку провайдер CPE не нарушал установленные процедуры или политику при выполнении CPE, равно как и корпорация ICANN, принимая отчет провайдера CPE, соблюдала установленную политику, Устав и учредительный договор. BAMC также рекомендовал Правлению отклонить Апелляцию 16-5 на том основании, что Податели апелляции не обнаружили неправильного использования политики или процедуры провайдером CPE, которое оказало на них существенное или негативное влияние.

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

      Принята резолюция (2019.03.14.12): Правление принимает рекомендацию BAMC по Апелляции 16-5.

      Пятнадцать членов Правления проголосовали за резолюцию 2019.03.14.12. Бекки Берр воздержалась. Резолюция была принята.

      Обоснование резолюции 2019.03.14.12

      1. Краткое резюме и рекомендации

        Обстоятельства дела полностью изложены в Рекомендации BAMC по Апелляции 16-5 («Рекомендация BAMC»), которую Правление рассмотрело и обсудило и которая включается в состав настоящего документа.

        25 января 2018 года BAMC рассмотрел Апелляции 16-5 и все соответствующие материалы и рекомендовал Правлению отклонить Апелляцию 16-5, поскольку провайдер CPE не нарушал установленные процедуры или политику при выполнении CPE, равно как и корпорация ICANN, принимая отчет провайдера CPE, соблюдала установленную политику, Устав и учредительный договор. BAMC также рекомендовал Правлению отклонить Апелляцию 16-5 на том основании, что Податели апелляции не обнаружили неправильного использования политики или процедуры провайдером CPE, которое оказало на них существенное или негативное влияние.

        Правление тщательно изучило Рекомендацию BAMC и все соответствующие материалы, относящиеся к Апелляции 16-5, и принимает Рекомендацию BAMC.

        12 февраль 2019 года Податели апелляции направили возражение против Рекомендации BAMC («Возражение»). Правление указывает на то, что подача Возражения не предусмотрена в Уставе, под действие которого подпадает Апелляция 16-5.3 Тем не менее, Правление рассмотрело доводы, представленные в возражении Подателей апелляции, и считает, что они не являются основанием для пересмотра по указанным ниже причинам.

      2. Проблема

        Проблемы следующие:

        • Содержится ли в заключении Независимой контрольной комиссии (IRP) по делу Little Birch LLC et al. против ICANN и Despegar Online SRL et al. против ICANN («IRP по делу Despegar») требование к Правлению вновь рассмотреть Отчет CPE;
        • Должен ли был провайдер CPE отдать приоритет заявке от сообщества, поскольку Правление приняло рекомендации Правительственного консультативного комитета (GAC) ICANN для строк Категорий 1 и 2;
        • Был ли у провайдера CPE конфликт интересов применительно к заявке;
        • Внесла ли корпорация ICANN какие-либо исправления в отчет CPE, и если да, соблюдались ли при внесении таких изменений установленные процедуры и политика;
        • Придерживался ли провайдер CPE действующих процедур и политики, применяя критерий 1: Существование сообщества;
        • Придерживался ли провайдер CPE действующих процедур и политики, применяя подчиненный критерий 2-A-Связь; и
        • Придерживался ли провайдер CPE действующих процедур и политики, применяя подчиненный критерий 4-A-Поддержка.

        Эти вопросы рассматриваются в соответствии с нормами, действовавшими для апелляций на момент подачи Апелляции 16-5. Указанные нормы подробно описаны в Рекомендации BAMC и включаются в состав настоящего документа.

      3. Анализ и обоснование

        1. Критерии и процедуры CPE

          CPE — это механизм разрешения споров, который доступен кандидатам, подающим заявки от сообщества.4 Нормы CPE и процедура CPE определены в разделе 4.2 модуля 4 Руководства кандидата («Руководство»). Заявки от сообществ, рассматриваются во время CPE с использованием следующих критериев: Критерий 1: Существование сообщества; Критерий 2: Связь между предлагаемой строкой и сообществом; Критерий 3: Регистрационная политика; и Критерий 4: Одобрение сообщества.5 В соответствии с Руководством, последовательность критериев отражает порядок, в котором провайдер CPE должен оценивать заявки на соответствие указанным критериям. Чтобы получить преимущество в рамках CPE, заявка должна набрать не менее 14 из 16 баллов по четырем критериям, при этом максимальная оценка по каждому критерию составляет четыре балла. Заявке, которая получает преимущество в рамках CPE, «отдается предпочтение перед всеми непосредственно конкурирующими с ней обычными заявками, независимо от их степени соответствия требованиям».6 CPE выполняется независимой комиссией из двух экспертов по оценке, назначаемых провайдером CPE.7 Роль провайдера CPE состоит в том, чтобы определить, удовлетворяет ли заявка от сообщества четырем критериям получения приоритета, сформулированным в модуле 4.2.3 Руководства.8

          Во время CPE не определяется существование, адекватность или значимость сообщества. Просто проверяется соответствие заявки от сообщества критериям оценки приоритетности заявок от сообществ. Как отмечается в Руководстве, «вывод [провайдера CPE], что заявке не удалось набрать проходной балл для получения преимущества в рамках оценки приоритетности заявок от сообществ, не обязательно свидетельствует о неподходящем характере или отсутствии самого сообщества».9

        2. Содержание заключения IRP по делу Despegar не дает оснований для пересмотра

          Податели апелляции утверждают, что для пересмотра решения есть основание, поскольку процесс CPE предположительно является принципиально ущербным. В обоснование своего утверждения Податели апелляции ссылаются на заключение IRP по делу Despegar, которое, по мнению Подателей апелляции, указывает на трудности, которые Комиссия IRP испытывала в процессе CPE.10 Податели апелляции утверждают, что поднятые Комиссией IRP по делу Despegar проблемные вопросы свидетельствуют о нарушении провайдером CPE и корпорацией ICANN установленных процедур и политики, имеющих отношение к оценке заявки.11 Комиссия IRP по делу Despegar рекомендовала, помимо прочего, внедрить для будущих раундов создания новых gTLD систему, которая обеспечит при оценке приоритетности заявок от сообществ «согласованность их проведения и предсказуемую основу для различных экспертов», чтобы основные ценности корпорации ICANN «доводились до сведения . . . таких организаций, как [провайдер CPE]».12 Податели апелляции видимо утверждают, что заключение IRP по делу Despegar обязывает Правление либо провести проверку процесса CPE в целом, — что Правление уже сделало во время Проверки процесса CPE, — либо отклонить отчет CPE на основании его мнимой ущербности.13

          Однако BAMC пришел к выводу, с которым Правление согласно, что ни содержание заключения IRP по делу Despegar, ни принятие отчета корпорацией ICANN не доказывает правильность этого утверждения. Принимая заключение комиссии IRP по делу Despegar (Резолюция 2016 года),14 Правление «приняло к сведению предложения комиссии [IRP]» и поручило корпорации ICANN «обеспечить, чтобы во время анализа результатов Программы New gTLD были приняты во внимание поднятые комиссией вопросы, так как они затрагивают согласованность и предсказуемость процесса CPE, а также выполнение оценки третьими сторонами».15 Помимо этого, проверка процесса CPE обеспечила дополнительный всесторонний анализ оценки приоритетности заявок от сообществ с особым акцентом на взаимоотношениях корпорации ICANN с провайдером CPE.16

          Ни один из аспектов заключения IRP по делу Despegar или принятия этого заключения Правлением не подтверждает необходимость изменения процесса CPE для заявки17 или изменения комитетом BAMC своих норм рассмотрения апелляций, в которых оспариваются отчеты CPE. Соответственно, ни один из аспектов заключения IRP по делу Despegar или Резолюции 2016 года не требует, чтобы Правление приняло какие-либо меры в отношении отчета CPE, кроме проверки того, что корпорация ICANN и провайдер CPE соблюдали установленные процедуры и политику применительно к данному отчету. Как подробнее рассматривается ниже, Податели апелляции не обнаружили никаких нарушений установленных процедур или политики в том, что касается отчета CPE.

          Более того, в той степени, в какой Податели апелляции утверждают, что заключение IRP по делу Despegar доказывает необходимость проверки Правлением процесса CPE в целом, как описано выше, Правление на самом деле уже провело такую проверку — это проверка процесса CPE. DotMusic опротестовала результаты проверки процесса CPE в Апелляции 18-5,18 которую Правление отклонило.19 Податели апелляции не представили никакой существенной информации, которую Правление упустило из виду, и не нашли никакой недостоверной или неточной информации, на которую опиралось Правление, когда отказалось признать недействительным отчет CPE в свете заключения IRP по делу Despegar или реакции на него.

        3. Принятие Правлением рекомендаций GAC для строк Категории 1 и Категории 2 не имеет ничего общего с требованием компании DotMusic отдать приоритет ее заявке от сообщества.

          Податели апелляции утверждают, что корпорация ICANN должна была «отдать приоритет» заявке в соответствии с рекомендациями GAC касательно строк Категорий 1 и 2.20 GAC рекомендовал для определенных видов строк, отнесенных к Категории 1, предусмотреть дополнительные меры защиты. Это следующие виды строк: (а) строки, относящиеся к регулируемым секторам; (б) строки, вызывающие опасения с точки зрения защиты прав потребителей; (в) другие строки, требующие особого внимания. Домен .MUSIC вошел в число новых gTLD, на которые распространяют свое действие рекомендации GAC для строк Категории 1, поскольку эта строка поднимает вопросы защиты прав потребителей – а именно, вопросы защиты интеллектуальной собственности.21 Что касается рекомендаций GAC для строк Категории 2, помимо прочего, предлагалось при использовании строк, которые представляют собой общие понятия («Строки общего пользования»), разрешать создание регистратур с эксклюзивным доступом к регистрации только в том случае, если это «послужит общественным интересам».22 Домен .MUSIC также был признан Строкой общего пользования согласно определению в рекомендациях GAC для строк Категории 2.

          BAMC установил, и Правление согласно, что ни один из аспектов принятия Правлением рекомендаций GAC для строк Категорий 1 и 2 или реагирования на эти рекомендации не обязывает корпорацию ICANN «отдать приоритет» заявкам на .MUSIC, поданным от сообщества.23 В рекомендациях GAC для строк Категорий 1 и 2 даже не проводится различие между заявками от сообществ и стандартными заявками. Более того, в противоположность утверждению Подателей апелляции, действие рекомендаций для строк Категории 1 распространялось на .MUSIC потому, что эта строка поднимала вопросы защиты интеллектуальной собственности, а не потому, что она относилась к регулируемому сектору.24 В связи с этим, ни один из аспектов рекомендаций GAC для строк Категории 1 не подразумевает, что у .MUSIC «сплоченное» сообщество, как считают Податели апелляции.25 Что касается рекомендаций для строк Категории 2, GAC заявил, что Строки общего пользования, такие как .MUSIC, представляют собой общие понятия, для которых недопустимо ограничивать доступ к регистратурам. Рекомендации GAC для строк Категории 2 и их принятие корпорацией ICANN не имеют ничего общего с приоритетом заявок от сообщества. Поэтому Правление согласно с заключением BAMC, что этот довод Подателей апелляции не дает оснований для пересмотра.

        4. Ни одна из рекомендаций Организации поддержки доменов общего пользования (GNSO) не требовала «принимать на веру» заявления о приоритете сообщества.

          Податели апелляции утверждают, что CPE была вообще не нужна, поскольку GNSO ICANN рекомендовала «принимать на веру» заверения, что заявка представляет сообщество.26 Податели апелляции неправильно понимают текст руководства GNSO по реализации, которое не является рекомендациями GNSO по политике, и в котором предлагается CPE. В частности, GNSO указывает на следующее:

          При любом заявлении кандидата о том, что TLD предназначен для поддержки определенного сообщества (например, спонсорский TLD или любой другой TLD, предназначенный для указанного сообщества), такое заявление будет принято на веру, кроме следующих случаев:

          (i) заявление относится к строке, которая также используется в другой заявке, заявление о поддержке сообщества используется для получения заявкой приоритета; и

          (ii) инициирован официальный процесс опротестования.27

          Соответственно, в Руководстве предусмотрено следующее: «Оценка справедливости обозначения заявки кандидатом как заявки от сообщества производится только в случае разногласий, которые приводят к оценке приоритетности заявок от сообществ».28 Кандидатам, подавшим заявку от сообщества, приходится проходить CPE, хоть это и не является обязательным требованием. Кандидаты выбирают этот вариант, потому что только через CPE могут получить преимущество перед конкурирующими заявками на ту же строку.29 По этой причине отсутствует политика или процедура, обязывающая корпорацию ICANN «принять на веру» утверждение DotMusic о первенстве ее заявки от сообщества. В связи с этим, ICANN не нарушила никакую процедуру или политику, отказываясь удовлетворить требование DotMusic «принять на веру» заявления этой компании о приоритете ее заявке от сообщества.

        5. Податели апелляции не продемонстрировали наличие конфликта интересов у провайдера CPE.

          Податели апелляции утверждают, что у провайдера CPE был конфликт интересов применительно к их заявке, потому что Эрик Шмидт (Eric Schmidt), исполнительный директор Google с 2001 по 2017 год, являлся членом Совета директоров Economist Group, материнской компании провайдера CPE, с ноября 2013 года по декабрь 2015 года включительно,30 Винт Серф (Vint Cerf), вице-президент Google с 2003 года, «в 2013 году (в период оценки заявок) занимал должность председателя Комиссии по стратегии ICANN», а Google тоже подала заявку на домен .MUSIC.31 Правление согласно с BAMC, что этот аргумент не может служить основанием для пересмотра по следующим причинам.

          Во-первых, Податели апелляции не представили доказательств того, что провайдер CPE не убедился — согласно требованиям Руководства кандидата, Документа с описанием процедур комиссии по CPE и Руководства по CPE — в том, что ни у одного из членов группы оценки или основной группы нет конфликта интересов, препятствующего рассмотрению заявок от сообществ.32 Податели апелляции не утверждают, что Эрик Шмидт — руководитель высокого ранга — был экспертом по оценке или членом основной группы (он им и не был) или что он оказал влияние на подготовку отчета CPE, знал о нем (или даже каким-то образом участвовал в работе провайдера CPE, который представляет собой отдельное подразделение в Economist Group). Фактически, отчет CPE был оформлен через два месяца после ухода г-на Шмидта с поста члена правления Economist Group.33 Аналогичным образом, DotMusic не разъяснила, как должность, которую занимал Винт Серф в Комиссии по стратегии ICANN, занимавшейся вопросами экосистемы управления интернетом34 в 2013 году, за три года до оформления отчета CPE, оказала влияние на заявку.

          Во-вторых, единственным основанием для этого предвзятого утверждения Подателей апелляции является их точка зрения (на основе выборки из 22 отчетов CPE), что заявки от сообществ, входившие в одну спорную группу с заявками Google, чаще всего проигрывали во время CPE.35 Тот факт, что многие заявки не получали преимущество при проведении CPE, вовсе не свидетельствует о несоблюдении процедуры. Любая заявка, которая побеждает в процессе CPE, получает приоритет над всеми остальными заявками из своей группы. Для процесса CPE умышленно установлена высокая планка получения заявкой преимущества.36 Поэтому неудача многих заявок на этапе CPE никоим образом не демонстрирует, что провайдер CPE не соблюдал установленные процедуры и политику в контексте предотвращения конфликта интересов у своих сотрудников применительно к рассматриваемой заявке.37 Более того, в отчете CoE, на который опирается DotMusic, сделан следующий вывод: «нет доказательств влияния Google на решения, принятые во время CPE».38

        6. Корпорация ICANN не участвовала в начислении баллов по критериям CPE.

          Податели апелляции утверждают, что некоторые контакты между корпорацией ICANN и провайдером CPE, факт которых был установлен во время IRP по делу Dot Registry против ICANN («Обмен информацией с CPE») демонстрирует, что корпорация ICANN «существенно» пересматривала отчеты CPE в нарушение установленных процедур и политики.39 BAMC пришел к выводу, и Правление согласно, что ни один из аспектов Обмена информацией с CPE не подтверждает мнение Подателей апелляции, будто корпорация ICANN изменила количество баллов, присвоенное заявке DotMusic провайдером CPE. Отчет о выполнении задачи № 1 по проверке процесса CPE подтверждает «отсутствие свидетельств того, что корпорация ICANN оказывала какое-либо незаконное давление на провайдера CPE в отношении отчетов CPE, выпущенных провайдером CPE, или участвовала каким-либо неподобающим образом в процессе CPE», в том числе при рассмотрении заявки DotMusic.40 Участие корпорации ICANN в работе провайдера CPE не заключалось в опротестовании выводов провайдера CPE (включая количество начисленных заявке баллов) и на самом деле было направлено на то, чтобы обеспечить ясность отчетов CPE, и на то, чтобы «провайдер CPE убедительно обосновал в отчете CPE свои оценки по каждому критерию».41 FTI сделала следующий вывод: «корпорация ICANN не предлагала провайдеру CPE вносить изменения в окончательные результаты оценки или корректировать текст обоснования в отчетах CPE».42

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

        7. Отчет CPE не дает право на надлежащую правовую процедуру.

          Правление согласно с заключением BAMC, что утверждение Подателей апелляции, будто провайдер CPE и корпорация ICANN не «соблюдали надлежащую правовую процедуру», не может служить основанием для пересмотра.43 Податели апелляции не продемонстрировали несоблюдение провайдером CPE процедур или политики, установленных для CPE в Руководстве.

          BAMC обратил внимание на то, что надлежащая правовая процедура не упоминается в применимых положениях Устава.44 По сути, Податели апелляции считают, что должна существовать официальная процедура опротестования решений сторонних провайдеров услуг корпорации ICANN, в том числе провайдера CPE, Комиссий по рассмотрению возражений на основании факта нарушения законных прав и Комиссий по оценке совпадения строк. Методы опротестования решений при урегулировании разногласий в отношении строк gTLD определены в Руководстве, подготовленном после нескольких лет широкого обсуждения, в котором приняли участие представители самых разных заинтересованных сторон: государственных органов, физических лиц, гражданского общества, группы интересов деловых пользователей и группы интересов по вопросам интеллектуальной собственности, а также технического сообщества.45 Многочисленные проекты Руководства выносились на общественное обсуждение и пересматривались в свете поступивших комментариев сообщества.46 Срок, в течение которого можно было оспорить Руководство, давно истек.47

          Более того, в Руководстве предусмотрен способ опротестования результатов CPE: В модуле 6 Руководства указано, что кандидаты, в том числе DotMusic, «могут воспользоваться любым механизмом подотчетности, закрепленным в Уставе ICANN для опротестования окончательного решения ICANN в отношении заявки».48 Податели апелляции воспользовались этим правом, постоянно подавая апелляции,49 к которым относится и Апелляция 16-5.

          Поскольку при рассмотрении заявки провайдер CPE применял критерии оценки приоритетности заявок от сообществ в соответствии с требованиями Руководства, принятие корпорацией ICANN отчета CPE также соответствовало применимыми процедурам и политике и не привело к несоблюдению «надлежащей правовой процедуры». Аналогичным образом, невозможность оспорить результаты оценки по существу нельзя считать несоблюдением права на надлежащую правовую процедуру.

        8. Заявление Подателей апелляции о доходах от аукционов не может служить основанием для пересмотра.

          Правление согласно с заключением BAMC, что Податели апелляции не представили доказательств (поскольку их не существует) в обоснование своего заявления, что побудительной причиной принятия корпорацией ICANN отчета CPE было стремление получить доход от проведения аукциона. Более того, Податели апелляции не указали, какая политика или процедура ICANN была нарушена. Таким образом, этот довод не является основанием для пересмотра.

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

          Податели апелляции возражают против решения провайдера CPE начислить их заявке только 10 баллов из 16 возможных. По причинам, изложенным в разделе VI.I Приложения 1 к Рекомендации BAMC, которая включается в состав настоящего документа посредством ссылки, Правление согласно с выводами BAMC, что для пересмотра решения нет оснований, поскольку Податели апелляции не сумели доказать, что провайдер CPE, когда рассматривал заявку, при определении количества баллов нарушил установленную политику или процедуру. Более того, Правление согласно с BAMC, что этот довод Подателей апелляции свидетельствует о существенном несогласии с выводами провайдера CPE, а это не является достаточным основанием для пересмотра решения.

        10. Претензии Подателей апелляции к проверке процесса CPE не являются основанием для пересмотра.

          BAMC установил, и Правление согласно, что претензии Подателей апелляции к проверке процесса CPE не являются основанием для пересмотра по всем причинам, подробно раскрытым в разделе VI.K Приложения 1 к рекомендации BAMC, которая включается в состав настоящего документа посредством ссылки. В частности, Правление считает, что критика Подателями апелляции вывода, сделанного по результатам проверки процесса CPE, не может служить основанием для пересмотра. Правление дополнительно отмечает, что оно рассмотрело многие из поднятых Подателями апелляции проблем в своем документе Решение по Апелляции 18-5, который включается в состав настоящего документа посредством ссылки.

          Правление также согласно с заключением BAMC, что требование DotMusic50 к корпорации ICANN раскрыть все документы, относящиеся к проверке процесса CPE, не предусмотрено в установленных процедурах или политике. Правление дополнительно отмечает, что оно рассмотрело требование DotMusic предоставить те же самые документы в Решении по Апелляции 18-1, которое включается в состав настоящего документа посредством ссылки. Кроме того, Правление соглашается с выводом BAMC, что нет политики или процедуры, в соответствии с которой корпорация ICANN должна возмещать расходы DotMusic на изучение любых документов, подготовленных корпорацией ICANN, и на подготовку в связи с этими документами дополнительных материалов для передачи BAMC. Правление также соглашается BAMC, что нет политики или процедуры, в соответствии с которой корпорация ICANN должна передать DotMusic список конкретных проблем с Апелляцией 16-5 после получения от DotMusic дополнительных материалов и планировать личную встречу для обсуждения этих проблем (после выполнения вышеуказанных условий).51

        11. Возражение не дает никаких доводов или фактов в пользу пересмотра.

          Прежде всего, Апелляция 16-5 подавалась в соответствии с Уставом от 11 февраля 2016 года, см. выше, в котором не предусмотрена возможность возражения против рекомендации BAMC.52 Тем не менее, Правление рассмотрело возражение Подателей апелляции и пришло к выводу, что они не представили никаких дополнительных аргументов или фактов в пользу пересмотра.

          1. Доводы Подателей апелляции относительно определения сообщества не могут служить основанием для пересмотра.

            Податели апелляции утверждают, что провайдер CPE ошибся при оценке по критерию существования сообщества (Критерий 1), потому что опирался на определение сообщества в заявке DotMusic в ответ на вопрос 20D. Податели апелляции утверждают, что Руководство обязывало провайдера CPE опираться исключительно на определение сообщества, которое DotMusic представила в ответ на вопрос 20A.53 В обоснование своего утверждения Податели апелляции цитируют таблицу в Приложении 2 к Модулю 2 Руководства, в которой разъясняются вопросы, критерии, количество баллов и методика оценки заявок на новые gTLD.54 Пояснение в столбце «Вопрос» таблицы для вопроса 20A гласит:

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

            Податели апелляции утверждают, что это пояснение обязывает провайдера CPE использовать определение сообщества, которое DotMusic дала в ответ на вопрос 20A. По мнению Правления, этот довод не учитывает пояснение в столбце «Критерий» для вопроса 20A:

            Ответы на вопрос 20 будут рассматриваться как твердая приверженность определенному сообществу и отражены в Соглашении об администрировании домена верхнего уровня, если заявка будет удовлетворена. При первоначальной оценке баллы за ответы не начисляются. Баллы за ответы могут начисляться в процессе оценки приоритетности заявок от сообществ (если применимо). Критерии и методика подсчета при оценке приоритетности заявок от сообществ описаны в Модуле 4 Руководства.56

            Ни одно из положений модуля 4 Руководства не заставляет провайдера CPE учитывать только ответ DotMusic на вопрос 20A, не принимая во внимание остальную часть заявки при оценке по Критерию 1.57 В связи с этим Правление считает, что этот довод не является основанием для пересмотра, поскольку Податели апелляции не продемонстрировали, что оценка заявки провайдером CPE по Критерию 1 противоречила Руководству или другим установленным процедурам или политике.

            Во-вторых, DotMusic утверждает, что провайдер CPE использовал неправильное определение сообщества, потому что «не упомянул явным образом определение сообщества Подателя апелляции в отчете CPE», а вместо этого «составил собственное "общее определение" сообщества на основе ответа на вопрос 20D».58 В ответ на вопрос 20A («наименование и полное описание сообщества, которое представляет кандидат»), DotMusic написала, что сообщество называется «Music Community» («Музыкальное сообщество»), а затем описала это сообщество. Описывая сообщество, DotMusic сообщила, что, «Музыкальное сообщество строго очерчено с использованием официальных кодов NAICS . . . организовано в соответствии с этими границами». Затем были перечислены коды NAICS, которые провайдер CPE включил в отчет CPE.59 Соответственно, даже если бы провайдер CPE был обязан принять во внимание только ответ DotMusic на вопрос 20A, — а это не так, — использование провайдером CPE кодов NAICS было бы оправданным.

            В-третьих, Податели апелляции утверждают, что формулировка, включенная в ответ DotMusic на вопрос 20D, относилась к «критерию правомочности», а не к определению сообщества. Следовательно, провайдеру CPE не следовало учитывать ее при оценке по Критерию 1.60 Как указано выше, Руководство не требует использовать такую степень разграничения. Кроме того, Правление отмечает, что в вопросе 20D не упоминается правомочность; в вопросе 20D DotMusic предлагалось «объяснить характер связей между указанной в заявке строкой gTLD и сообществом, идентифицированным в ответе на [вопрос 20A]».61

            В ответ на вопрос 20D компания DotMusic написала, помимо прочего, следующее: «связь .MUSIC с сообществом определяется тем, что этот домен представляет все группы, которые создают и распространяют музыку, включая государственные культурные учреждения, художественные советы и другие дополняющие [так в оригинале] организации, которые занимаются вспомогательной деятельностью, согласующейся с миссией .MUSIC».62 DotMusic не указывает никаких критериев, предусмотренных в Руководстве, применимой политике или процедуре, которые запрещали бы провайдеру CPE при оценке по критерию существования сообщества учитывать «группы», «представленные» в сообществе, на основе определения в заявке на доменное имя. В силу этой дополнительной причины рассматриваемый довод не является основанием для пересмотра.

            В-четвертых, компания DotMusic утверждает, что благодаря тому, что она определила Музыкальное сообщество как «организованное сообщество физических лиц, организаций и коммерческих компаний, закономерный альянс сообществ, имеющих одинаковую природу («СООБЩЕСТВО») и имеющих отношение к музыке», провайдеру CPE пришлось «признать, что [DotMusic] удовлетворяет точному определению "закономерного альянса", узнаваемого и признаваемого его членами».63 BAMC рассмотрел этот довод в своей рекомендации 64 и Правление включает аргументы BAMC в полном объеме в состав настоящего документа. BAMC установил, что в Руководстве указано: «закономерный альянс сообществ» — «жизнеспособное» определение сообщества, «при соблюдении обязательных условий узнаваемости и признаваемости сообщества его членами».65 Поскольку провайдер CPE не обнаружил признаков узнаваемости и признаваемости среди членов этого сообщества в целом, провайдер CPE выполнил директиву Руководства и присвоил заявке ноль баллов по Критерию 1.66

          2. Остальные доводы Подателей апелляции уже рассматривались ранее и не могут служить основанием для пересмотра.

            Податели апелляции постоянно критикуют отчеты о проверке процесса CPE, в том числе в Апелляции 18-5.67 Правление рассмотрело эти доводы 18 июля 2018 года и включает их в состав настоящего документа посредством ссылки.68 Остальные доводы в возражении Подателей апелляции дублируют доводы из Апелляции 16-5 и материалы, представленные в ее обоснование. Все это BAMC рассмотрел при подготовке своей рекомендации.

          3. Ответ Подателей апелляции на предложение предоставить дополнительные информационные материалы.

            В конце Правлению придется рассмотреть заявление Подателей апелляции, что они никогда не «отказывались» от предложений BAMC предоставить дополнительные материалы в обоснование Апелляции 16-5. В возражении Податели апелляции утверждают, что «некорректно» считать их ответ на приглашение BAMC отказом.69 Однако именно это слово точнее всего характеризует реакцию Подателей апелляции на приглашение. 5 апреля 2018 года, в ответ на приглашение BAMC представить дополнительные документы, Податели апелляции написали следующее «DotMusic считает неприемлемой попытку ICANN ввести искусственные ограничения на предоставление дополнительных документов по Апелляции 16-5» и поэтому больше не ничего не отправит.70 Ошибочно было бы считать, что такой ответ DotMusic BAMC на самом деле был просьбой «дать возможность предоставления неограниченного количества документов и выступлений с докладами».71

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

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

            Данное решение принято в рамках выполнения организационно-административной работы и не требует общественного обсуждения.

    5. Рассмотрение заявки на домен .AMAZON

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

      Резолюций принято не было.

    6. Одобрение результатов второй организационной проверки NomCom – итоговый отчет и рекомендации

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

      Аври выдвинула, а Трипти Синха поддержала предлагаемую резолюцию. После этого председатель предложил проголосовать и Правление приняло следующее решение:

      Принимая во внимание, что вторая организационная проверка Номинационного комитета (NomCom) началась в июне 2017 года в соответствии с разделом 4.4 статьи 4 Устава ICANN.

      Принимая во внимание, что независимая аудиторская компания, проводившая вторую проверку NomCom, подготовила отчет о результатах проверки, который был опубликован для общественного обсуждения 10 января 2018 года, проект итогового отчета, который был опубликован для общественного обсуждения 27 марта 2018 года, а затем и итоговый отчет, содержащий 27 (двадцать семь) рекомендаций, который был опубликован 5 июня 2018 года.

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

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

      Принимая во внимание, что регулярно консультируясь с сообществом, а также с Номинационными комитетами в 2018 и 2019 годах, Группа планирования реализации при полном консенсусе утвердила итоговый FAIIP 14 декабря 2018 года.

      Принимая во внимание, что Правление отмечает, что процесс утверждения FAIIP не в полной мере отражал процедуру, описанную в организационной блок-схеме, где указано, что FAIIP утверждают проверяемые организации поддержки и консультативные комитеты (SO/AC). Причина такого расхождения в существенном отличии роли и структуры членства NomCom от советов и руководства тех SO и AC, которые проходят организационные проверки.72 Единогласная поддержка Группой планирования реализации FAIIP, репрезентативность ее членского состава, транспарентность ее работы и подотчетность ее мероприятий по информированию в ходе проведения работы, в том числе на конференции ICANN63 — все это компенсирует отсутствие официального утверждения консультативным комитетом или советом, которое имеет место в ходе организационной проверки SO или AC.

      Принимая во внимание, что Группа планирования реализации рекомендаций, полученных по результатам проверки NomCom, поддержала все 27 рекомендаций независимой аудиторской компании и внесла небольшие изменения в четыре из 27 рекомендаций, как подробно указано в FAIIP.

      Принимая во внимание, что Комитет Правления ICANN по организационной эффективности (OEC) на своем собрании 8 января 2019 года получил от независимой аудиторской компании информацию о ее итоговом отчете, а от Группы планирования реализации — информацию о FAIIP.

      Принимая во внимание, что OEC принял во внимание итоговый отчет, FAIIP и комментарии, полученные в ходе общественного обсуждения, с целью выработать рекомендацию Правлению в отношении дальнейших действий в том, что касается второй организационной проверки NomCom. OEC рекомендовал Правлению принять итоговый отчет независимой аудиторской компании о результатах проверки NomCom и FAIIP Группы планирования реализации. Кроме того, OEC рекомендует Правлению поручить Группе планирования реализации рекомендаций, полученных по результатам проверки NomCom, сформировать рабочую группу по реализации рекомендаций для разработки подробного плана реализации рекомендаций, как подробно указано в FAIIP, в течение шести месяцев с момента принятия данной резолюции, группа по реализации рекомендации будет контролировать реализацию этих рекомендаций после утверждения Правлением указанного подробного плана реализации.73

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

      Принята резолюция (2019.03.14.14): Правление выражает признательность за проделанную работу и поддержку в ходе проведения проверки Рабочей группе проверки NomCom и Группе планирования реализации рекомендаций, полученных по результатам проверки NomCom. Правление выражает благодарность Группе планирования реализации рекомендаций, полученных по результатам проверки NomCom, за усердную и обстоятельную работу при подготовке анализа выполнимости и первоначального плана реализации рекомендаций, который был утвержден при полном консенсусе Группой планирования реализации рекомендаций, полученных по результатам проверки NomCom, 14 декабря 2018 года..

      Принята резолюция (2019.03.14.15): Правление принимает итоговый отчет независимой аудиторской компании.

      Принята резолюция (2019.03.14.16): Правление принимает анализ выполнимости и первоначальный план реализации рекомендаций от Группы планирования реализации рекомендаций, полученных по результатам проверки NomCom, с учетом необходимости определения затрат на реализацию. Правление поручает президенту и генеральному директору ICANN или назначенным им лицам оказать поддержку Группе планирования реализации рекомендаций, полученных по результатам проверки NomCom, в разработке и передаче на рассмотрение Правления через OEC плана реализации принятых рекомендаций. Президенту и генеральному директору ICANN или назначенным им лицам поручено сообщать Правлению информацию о плане и любых комментариях сообщества.

      Принята резолюция (2019.03.14.17): в поддержку этих мер Правление просит Группу планирования реализации рекомендаций, полученных по результатам проверки NomCom, сформировать рабочую группу для разработки проекта подробного плана реализации рекомендации, как подробно указано в FAIIP. Подробный план реализации должен быть представлен Правлению как можно раньше, однако не позже чем через шесть месяцев после принятия этой резолюции. План реализации должен содержать реалистичный график реализации рекомендаций, определение необходимых результатов, описание подходов к решению основных проблем, указанных в итоговом отчете, и способ измерения текущего состояния, а также прогресса в достижении требуемого результата. Кроме того, рабочая группа будет сотрудничать с корпорацией ICANN, чтобы включить в подробный план реализации ожидаемые бюджетные последствия каждого этапа реализации. План реализации должен включать в себя поэтапный подход, который позволял бы в первую очередь выполнять простые в реализации и наименее затратные усовершенствования, чтобы пункты, подразумевающие более серьезные последствия с точки зрения бюджета, выполнялись на более поздних этапах процесса реализации.

      Принята резолюция (2019.03.14.18): Правление поручает рабочей группе NomCom по реализации рекомендаций контролировать процесс реализации, после того как Правление примет подробный план реализации. Все бюджетные заявки, связанные с реализацией рекомендаций, должны подаваться в соответствии с ежегодной процедурой корпорации ICANN по формированию бюджета.

      Принята резолюция (2019.03.14.19): Правление поручает рабочей группе по реализации рекомендаций, полученных по результатам проверки NomCom, раз в шесть месяцев подавать в OEC отчеты о ходе реализации в сравнении с планом реализации, в том числе о прогрессе в работе над показателями, подробно описанными в плане реализации, а также об использовании выделенных средств.

      Все присутствующие члены Правления проголосовали за принятие резолюций 2019.03.14.13, 2019.03.14.14, 2019.03.14.15, 2019.03.14.16, 2019.03.14.17, 2019.03.14.18 и 2019.03.14.19. Резолюции были приняты.

      Обоснование резолюций 2019.03.14.13 - 2019.03.14.19

      Почему Правление рассматривает этот вопрос?

      Чтобы обеспечить сохранение транспарентности и подотчетности модели ICANN с участием многих заинтересованных сторон, а также улучшить ее характеристики, ICANN проводит организационные проверки своих организаций поддержки (SO), консультативных комитетов (AC) (кроме Правительственного консультативного комитета) и Номинационного комитета в соответствии с разделом 4.4 статьи 4 Устава ICANN. Вторая проверка NomCom началась в июне 2017 года. Независимая аудиторская компания, проводившая эту проверку, подготовила итоговый отчет, который был опубликован в июне 2018 года. После тщательного изучения итогового отчета независимой аудиторской компании Группа планирования реализации рекомендаций, полученных по результатам проверки NomCom, подготовила анализ выполнимости и первоначальный план реализации рекомендаций (FAIIP), единодушно одобренный 14 декабря 2018 года.

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

      Какое предложение рассматривается?

      Правлению предлагается принять итоговый отчет, а также анализ выполнимости и первоначальный план реализации рекомендаций (FAIIP) и поручить Группе планирования реализации рекомендаций, полученных по результатам проверки NomCom, сформировать Рабочую группу по реализации рекомендаций, полученных по результатам проверки NomCom, которая будет контролировать выполнение рекомендаций в соответствии с подробным описанием в FAIIP.

      С какими заинтересованными сторонами или иными лицами были проведены консультации?

      В ходе проверки NomCom независимая аудиторская компания провела более 60 собеседований с действующими и бывшими членами NomCom, сообщества, Правления и корпорации ICANN, а также получила ответы от 85 участников онлайн-опроса. Независимая аудиторская компания в течение всей проверки регулярно встречалась с Рабочей группой проверки NomCom, в том числе на открытых конференциях ICANN61 и ICANN62, и с группами сообщества на ICANN63, провела консультации с общественностью по поводу отчета о результатах проверки, и вебинар, посвященный проекту итогового отчета.

      Независимая аудиторская компания опубликовала свой отчет о результатах проверки для проведения консультаций с общественностью и проект итогового отчета для общественного обсуждения. Через форум общественного обсуждение поступило десять комментариев – один от физического лица и девять от имени организаций. (См. Сводный отчет о результатах общественного обсуждения). Рабочая группа проверки NomCom2 также напрямую передала независимой аудиторской компании свои комментарии к первоначальными проектам отчета о результатах проверки, проекту итогового отчета и итоговому отчету.

      OEC на своем собрании 8 января 2019 года получил от независимой аудиторской компании информацию о ее итоговом отчете, а от Группы планирования реализации — информацию о FAIIP. OEC также рассмотрел комментарии сообщества к отчету независимой аудиторской компании о результатах проверки и проекту итогового отчета.

      Какие вызывающие озабоченность вопросы или проблемы были подняты сообществом?

      Несмотря на то, что Группа планирования реализации рекомендаций, полученных по результатам проверки NomCom признала справедливыми цели всех рекомендаций независимой аудиторской компании, она выразила озабоченность по поводу формулировки четырех рекомендаций. Группа планирования реализации рекомендаций, полученных по результатам проверки NomCom, устранила эту озабоченность, внеся в текст четырех рекомендаций изменения семантического характера.

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

      Кроме того, сообщество также поддержало проект анализа выполнимости и первоначального плана реализации рекомендаций, с которым Группа планирования реализации ознакомила заинтересованные группа сообщества на ICANN 63.

      Какие важные материалы были рассмотрены Правлением?

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

      Какие факторы Правление посчитало значимыми?

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

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

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

      Ожидаются ли положительные или отрицательные последствия для сообщества?

      Ожидается, что данное действие Правления окажет положительное влияние на сообщество, поскольку способствует сохранению закрепленного в Уставе процесса периодических проверок организаций поддержки (SO) и консультативных комитетов (AC) ICANN. Более того, выполнение рекомендаций приведет к повышению транспарентности, подотчетности и эффективности работы NomCom.

      Имеются ли финансовые последствия для ICANN (стратегический план, план операционной деятельности, бюджет), сообщества и/или общественности?

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

      Существуют ли какие-либо проблемы безопасности, стабильности или отказоустойчивости, относящиеся к DNS?

      Не ожидается, что это решение Правления окажет какое-либо непосредственное влияние на безопасность, стабильность или отказоустойчивость DNS.

      Почему это решение находится в пределах миссии ICANN и каким общественным интересам оно служит?

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

      Это решение послужит общественным интересам, способствуя выполнению обязательства ICANN сохранять и улучшать транспарентность и подотчетность.

      Необходимо ли перед принятием Правлением решения провести общественное обсуждение?

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

    7. Дальнейшие действия по определению состава группы по проверке исполнения функций IANA

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

      Аври Дориа еще раз напомнила, что этот вопрос следует как можно раньше вынести на рассмотрение Правления, в соответствии с требованиями Устава ICANN, относящимися к процессу проверки исполнения функций IANA в отношении имен.

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

      Резолюция не принята.

    8. Утвержденные резолюции Правления (AOB)

      1. Проект анализа доменных коллизий – первое исследование

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

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

        Акинори выдвинул, а Лито Ибарра поддержал резолюцию. После этого председатель предложил проголосовать и Правление приняло следующее решение:

        Принимая во внимание, что 2 ноября 2017 года Правление предложило Консультативному комитету по безопасности и стабильности ICANN (SSAC) составить и передать для утверждения Правлением подробный план исследований в области доменных коллизий. См. https://www.icann.org/resources/board-material/resolutions-2017-11-02-en#2.a.

        Принимая во внимание, что SSAC в сентябре 2018 года предложил Проект анализа доменных коллизий (NCAP) с подробным описанием трех исследований, удовлетворяющих требованиям резолюции Правления 2017 года.

        Принимая во внимание, что в октябре 2018 года, Технический комитет Правления (BTC) попросил корпорацию ICANN, через офис технического директора (OCTO), оценить предложение NCAP. Впоследствии OCTO и SSAC провели обсуждение, в ходе которого OCTO получил дополнительную информацию и пояснения относительно деталей этого проекта.

        Принимая во внимание, что после выполнения оценки OCTO сообщил, что проведение опроса и обобщение результатов предыдущих исследований в области доменных коллизий могли бы принести пользу, однако хранилище данных и соответствующая политика использования этого хранилища могут оказаться ненужными, если позже будет принято решение не продолжать Исследование № 2 и Исследование № 3. В результате, OCTO скорректировал рамки предложенного SSAC Исследования № 1 «Осмысление текущей ситуации с доменными коллизиями», чтобы отложить реализацию хранилища данных и разработку соответствующей политики.

        Принимая во внимание, что OCTO передал BTC описание предлагаемого исследования «Осмысление текущей ситуации с доменными коллизиями», которое будет преследовать три цели: 1) изучение предыдущей работы в области доменных коллизий и подготовка сводного отчета, содержащего важную для этого исследования информацию о предыдущей работе, которую можно будет использовать для ознакомления с этой областью знаний; 2) создание списка результатов с данными, которые использовались во время предыдущих исследований, анализ несоответствий, если они есть, и создание списка дополнительных данных, которые могли бы понадобиться для успешного выполнения двух указанных дополнительных исследований; 3) предоставление информации, которая поможет принять решение о целесообразности продолжения реализации проекта NCAP и выполнения исследований № 2 и № 3 с учетом результатов опроса, посвященного предыдущей работе, и доступности данных.

        Принимая во внимание, что BTC рассмотрел предложение OCTO о проведении исследования «Осмысление текущей ситуации с доменными коллизиями», в том числе финансовые последствия этого и всех трех исследований, и 4 марта 2019 года рекомендовал Правлению поручить корпорации ICANN приступить к проведению Исследования № 1.

        Принята резолюция (2019.03.14.20): Правление ICANN выражает SSAC благодарность за проделанную работу, заключавшуюся в ответе на ноябрьскую резолюцию 2017 года и разработке первоначального предложения по проекту анализа доменных коллизий (NCAP) и последующих поправок к предложению.

        Принята резолюция (2019.03.14.21): Правление поручает президенту и генеральному директору ICANN или назначенным им лицам начать Исследование № 1, посвященное пониманию текущей ситуации с доменными коллизиями с учетом уточнений, внесенных корпорацией ICANN.

        Принята резолюция (2019.03.14.22): Правление поручает президенту и генеральному директору ICANN или назначенным им лицам определить сумму и выделить финансирование в пределах собственных ограничений, предусмотренных бюджетом и материально-техническим обеспечением, а расходы, связанные с предложенным исследованием, не должны превышать [УДАЛЕНО ДЛЯ ПРОВЕДЕНИЯ ПЕРЕГОВОРОВ].

        Принята резолюция (2019.03.14.23): в соответствии с разделами 3.5 (b) и (d) статьи 3 Устава ICANN отдельные части данной резолюции должны быть сохранены в тайне для проведения переговоров до тех пор, пока президент и генеральный директор не сочтет возможным раскрыть эту информацию.

        Все присутствующие члены Правления проголосовали за принятие резолюций 2019.03.14.20, 2019.03.14.21, 2019.03.14.22 и 2019.03.14.23. Резолюции были приняты.

        Обоснование резолюций 2019.03.14.20 – 2019.03.14.23

        Доменная коллизия приводит к конфликтам, когда при попытке разрешения имени, используемого в частном пространстве имен (например, в случае неделегированного домена верхнего уровня или короткого, неопределенного имени), запрос отправляется публичной системе доменных имен (DNS). При пересечении административных границ закрытых и открытых пространств имен система разрешения имен может выдавать нежелательные или опасные результаты. Такой класс еще не делегированных строк называется «совпадающими строками». В некоторых случаях нежелательные или опасные результаты делегирования совпадающих строк могут считаться связанными с высокой степенью риска. В качестве параметров, позволяющих отнести совпадающие строки к строкам, связанным с высокой степенью риска, можно привести следующие примеры: высокая частотность упоминания в запросах к корневым серверам, тяжесть последствий совпадающих строк, тип запросов DNS, тип пользователя, вызывающего совпадение (например, аварийные или авиадиспетчерские службы и т. п.), разнообразие источников запросов и отображение во внутренних сертификатах имен.

        Правление уже принимало решение по вопросу доменных коллизий, в частности, предложило Консультативному комитету по безопасности и стабильности (SSAC) составить список исследований, позволяющих ответить на ряд вопросов, которые, как считает Правление, помогут понять, каким образом ICANN будет решать проблему доменных коллизий во время будущего расширения пространства доменных имен. В ответ на резолюцию Правления от 2 ноября 2017 года, SSAC передал в сентябре 2018 предложение по Проекту анализа доменных коллизий (NCAP). В предложении были подробно описаны три поочередных исследования, которые согласно ожиданиям позволили бы решить задачи, поставленные в той резолюции.

        Технический комитет Правления (BTC) попросил корпорацию ICANN, через офис технического директора (OCTO), оценить предложение NCAP. После получения этой просьбы OCTO и SSAC провели обсуждение, в ходе которого OCTO получил дополнительную информацию и пояснения относительно деталей этого проекта.

        В конечном итоге, OCTO передал BTC результаты оценки и сообщил, что проведение опроса и обобщение результатов предыдущих исследований в области доменных коллизий могли бы принести пользу, однако хранилище данных и соответствующая политика использования этого хранилища могут оказаться ненужными, если позже будет принято решение не продолжать Исследование № 2 и Исследование № 3. В результате, OCTO скорректировал рамки предложенного SSAC Исследования № 1 «Осмысление текущей ситуации с доменными коллизиями», чтобы отложить реализацию хранилища данных и разработку политики до завершения будущих исследований. У уточненного Исследования № 1 три задачи: 1) изучение предыдущей работы в области доменных коллизий и подготовка сводного отчета, содержащего важную для этого исследования информацию о предыдущей работе, которую можно будет использовать для ознакомления с этой областью знаний; 2) создание списка результатов с данными, которые использовались во время предыдущих исследований, анализ несоответствий, если они есть, и создание списка дополнительных данных, которые могли бы понадобиться для успешного выполнения двух указанных дополнительных исследований; 3) предоставление информации, которая нужна для принятия решения о целесообразности продолжения реализации проекта NCAP и выполнения дальнейших исследований с учетом результатов опроса, посвященного предыдущей работе, и доступности данных.

        Правление принимает сегодняшнее решение по двум причинам. Во-первых, работа OCTO над проекта NCAP достигла этапа, когда рамки исследования уже достаточно хорошо определены и можно его начать. Во-вторых, может существовать взаимозависимость между результатами исследования доменных коллизий и следующим раундом Программы New gTLD, особенно в контексте получения дополнительной информации о возможности делегировать строки, которые пересекаются в публичном и внутреннем пространствах имен.

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

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

        Это организационно-административная функция, не требующая общественного обсуждения.

      Затем председатель объявил о закрытии заседания.


1 Интернационализированные доменные имена в приложениях (IDNA): история вопроса, пояснение и обоснование

2 https://www.icann.org/en/system/files/correspondence/disspain-letter-review-new-gtld-cpe-process-26apr17-en.pdf.

3 См. Устав ICANN, 11 февраля 2016 года, ст. 4, § 2 (https://www.icann.org/resources/pages/bylaws-2016-02-16-en#IV).

4 См. Руководство, модуль 4, § 4.2 стр. 4-7 (https://newgtlds.icann.org/en/applicants/agb/string-contention-procedures-04jun12-en.pdf). См. также https://newgtlds.icann.org/en/applicants/cpe.

5 Там же, модуль 4, § 4.2, стр. 4-7 (https://newgtlds.icann.org/en/applicants/agb/string-contention-procedures-04jun12-en.pdf).

6 Там же, модуль 4, § 4.2.3, стр. 4-9.

7 Там же. модуль 4, § 4.2.2.

8 Там же, модуль 4, §§ 4.2.2 и 4.2.3, стр. 4-8 и 4-9 (https://newgtlds.icann.org/en/applicants/agb/string-contention-procedures-04jun12-en.pdf).

9 Руководство, модуль 4, § 4.2.3, стр. 4-9.

10 Апелляция 16-5, § 6, стр. 19; заключение IRP по делу Despegar ¶¶ 66-67 (https://www.icann.org/en/system/files/files/irp-despegar-online-et-al-final-declaration-12feb16-en.pdf).

11 Апелляция 16-5, § 6, стр. 19.

12 Там же. ¶¶ 147, 150 (выделение добавлено).

13 Апелляция 16-5, § 6, стр. 19.

14 Резолюции Правления 2016.03.10.10-11 (https://www.icann.org/resources/board-material/resolutions-2016-03-10-en#2.a).

15 Там же.

16 См. https://newgtlds.icann.org/en/applicants/cpe#process-review.

17 Апелляция 16-5, § 8, стр. 17, 18.

18 Апелляция 18-5, https://www.icann.org/en/system/files/files/reconsideration-18-5-dotmusic-request-redacted-14apr18-en.pdf.

19 Решение Правления по Апелляции 18-5, https://www.icann.org/resources/board-material/resolutions-2018-07-18-en#2.f.

20 Апелляция 16-5, § 8, стр. 5.

21 См. Коммюнике по результатам заседаний GAC в Пекине, Приложение I, стр. 9 https://www.icann.org/en/system/files/correspondence/gac-to-board-18apr13-en.pdf; см. также https://newgtlds.icann.org/en/applicants/gac-advice/cat2-safeguards.

22 См. там же, стр. 11.

23 См. https://www.icann.org/en/system/files/files/resolutions-new-gtld-annex-2-05feb14-en.pdf. См. также http://www.icann.org/en/groups/board/documents/resolutions-new-gtld- 25jun13-en.htm; см. также ICANN NGPC, Док. № 2013-06-25-2b: Рекомендации из Коммюнике по результатам заседаний GAC в Пекине, относящиеся к мерам защиты строк категории 2, справочные материалы 1, стр. 25-31 (http://www.icann.org/en/groups/board/documents/briefing-materials-1- 25jun13-en.pdf); http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-02jul13-en.htm#1.d; см. также http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-annex-1-item-1d- 02jul13-en.pdf, Приложение I, Соглашение об администрировании нового gTLD).

24 Апелляция 16-5, § 8, стр. 5.

25 Там же; см. также Мнение Бломквиста, ¶ 52, стр. 41.

26 Там же., § 6, стр. 3, 6.

27 Итоговый отчет GNSO о создании новых доменов общего пользования верхнего уровня, Руководство по реализации IG H (выделение добавлено) (http://gnso.icann.org/en/issues/new-gtlds/pdp-dec05-fr-parta-08aug07.htm).

28 Руководство, модуль § 1.2.3.2, стр. 1-27.

29 Там же.

30 Апелляция 16-5, § 6, стр. 20. См. также Письмо DotMusic на тему проверки процесса CPE, ¶¶ 26(c), 67b, стр. 28, 47 (также утверждается, что г-н Робин Джейкоб (Robin Jacob), эксперт, выбранный ICC во время разбирательства по возражению от сообщества (домены .MUSIC и .BAND), был представителем Samsung, «одного из партнеров Google с многомиллиардным капиталом», при рассмотрении судебного иска (дополнительные сведения см. в Апелляции 16-7, § 8, стр. 18 (пункт 17) n.68, https://www.icann.org/en/system/files/files/reconsideration-16-7-dotmusic-request-redacted-30may16-en.pdf).

31 Письмо DotMusic на тему проверки процесса CPE, ¶ 26(c), стр. 28.

32 Руководство § 2.4.3.1, стр. 2-33; Документ по процессу комиссии CPE, стр. 2, https://newgtlds.icann.org/en/applicants/cpe; Руководство по CPE, стр. 22, https://newgtlds.icann.org/en/applicants/cpe.

33 г-н Шмидт ушел с этой должности примерно в декабре 2015 года (https://www.theguardian.com/media/2015/dec/10/economist-appoints-tessa-jowell-to-board-as-googles-eric-schmidt-departs). Отчет CPE был представлен 10 февраля 2016 года. (https://newgtlds.icann.org/sites/default/files/tlds/music/music-cpe-1-1115-14110-en.pdf.)

34 См. Комиссия по стратегии: Роль ICANN в экосистеме управления интернетом (https://www.icann.org/en/system/files/files/report-23feb14-en.pdf).

35 Апелляция 16-5, § 6, стр. 20.

36 См. Руководство кандидата, модуль 4, § 4.2.3, стр. 4-9 («заявке от сообщества, которая удовлетворяет критериям, отдается предпочтение перед всеми непосредственно конкурирующими с ней обычными заявками, независимо от их степени соответствия требованиям. Это основная причина введения очень строгих квалификационных требований для заявки от сообщества».).

37 Податели апелляции ссылаются на обмен мнениями с Фади Шехади (Fadi Chehadé) во время публичного форума. См. https://singapore52.icann.org/en/schedule/thu-public-forum/transcript-public-forum-12feb15-en.pdf, стр. 61-62. Во время этого обмена мнениями г-н Шехади поблагодарил DotMusic за комментарии и предложил отправить ICANN письмо, изложив в нем причины своей озабоченности. DotMusic этого не сделала. Ни одно из высказываний во время этого диалога не содержит «признание» наличия конфликта интересов, на который намекают Податели апелляции. См. Апелляцию 16-5, § 6, стр. 20.

38 Отчет CoE, стр. 47, цитируется в письме DotMusic на тему проверки процесса CPE, ¶ 26(c), стр. 28.

39 Апелляция 16-5, § 6, стр. 18.

40 Отчет FTI о выполнении задачи № 1, стр. 3 https://www.icann.org/en/system/files/files/cpe-process-review-scope-1-communications-between-icann-cpe-provider-13dec17-en.pdf.

41 Там же, стр. 12.

42 Там же

43 Апелляция 16-5, § 8, стр. 16 (пронумерована как стр. 15).

44 См. Устав ICANN, 11 февраля 2016 года.

45 Руководство, Преамбула.

46 Там же.

47 См. https://newgtlds.icann.org/en/applicants/agb, указано, что действующая редакция руководства датирована 4 июня 2012 года. Согласно редакции Устава, которая действовала в июне 2012 года, Апелляцию необходимо было подавать в течение тридцати дней после опубликования информации об действиях Правления или в течение тридцати дней после того, как Заявитель узнал или должен был узнать, исходя из разумных оснований, об оспариваемом действии персонала. Устав ICANN, 16 марта 2012 года, ст. IV, § 2.5 (https://www.icann.org/resources/pages/bylaws-2012-12-21-en#IV).

48 Руководство, модуль 6, § 6, стр. 6-4.

49 См. Апелляцию 14-28, https://www.icann.org/en/system/files/files/request-dotmusic-07jun14-en.pdf; Апелляцию 16-7, https://www.icann.org/en/system/files/files/reconsideration-16-7-dotmusic-request-redacted-30may16-en.pdf; Апелляцию 17-2, https://www.icann.org/en/system/files/files/reconsideration-17-2-dotmusic-request-redacted-18jun17-en.pdf; Апелляцию 17-4, https://www.icann.org/en/system/files/files/reconsideration-17-4-dotmusic-dotgay-request-redacted-25jul17-en.pdf; Апелляцию 18-1, https://www.icann.org/en/system/files/files/reconsideration-18-1-dotmusic-request-redacted-10mar18-en.pdf; Апелляцию 18-5, https://www.icann.org/en/system/files/files/reconsideration-18-5-dotmusic-request-redacted-14apr18-en.pdf.

50 Правление обращает внимание на то, что это утверждает только DotMusic, но не остальные Податели апелляции, в дополнительных материалах, представленных в обоснование Апелляции 16-5. См. https://www.icann.org/en/system/files/files/reconsideration-16-3-et-al-dotgay-dechert-to-icann-board-bamc-redacted-23mar18-en.pdf.

51 https://www.icann.org/en/system/files/files/reconsideration-18-5-dotmusic-bamc-recommendation-attachment-2-14jun18-en.pdf.

52 См. Устав ICANN, 11 февраля 2016 года, ст. 4, § 2 (https://www.icann.org/resources/pages/bylaws-2016-02-16-en#IV).

53 Возражение, стр. 3-5 (https://www.icann.org/en/system/files/files/reconsideration-16-5-dotmusic-requestors-rebuttal-to-bamc-recommendation-request-12feb19-en.pdf).

54 Там же; см. также Руководство, модуль 2, Приложение 2 (https://newgtlds.icann.org/en/applicants/agb/evaluation-questions-criteria-04jun12-en.pdf).

55 Руководство, модуль 2, Приложение 2, стр. A-14 (https://newgtlds.icann.org/en/applicants/agb/evaluation-questions-criteria-04jun12-en.pdf) (выделение добавлено).

56 Там же (выделение добавлено)

57 См. Руководство, модуль 4, § 4.2.3, стр. 4-10 – 4-12.

58 Возражение, стр. 6.

59 Заявка, вопрос 20A (https://gtldresult.icann.org/applicationstatus/applicationdetails/1392).

60 Возражение, стр. 4 (внутренние кавычки опущены).

61 Руководство, Приложение 2 к модулю 2, стр. A-14.

62 Заявка, вопрос 20D, (https://gtldresult.icann.org/applicationstatus/applicationdetails/1392).

63 Возражение, стр. 4-5.

64 См. Приложение 1 к Рекомендации BAMC, стр. 29 (https://www.icann.org/en/system/files/files/reconsideration-16-5-dotmusic-bamc-recommendation-attachment-1-25jan19-en.pdf).

65 Руководство, модуль 4, § 4.2.3, стр. 4-12 (выделение добавлено).

66 Там же

67 См. https://www.icann.org/en/system/files/files/reconsideration-18-5-dotmusic-request-redacted-14apr18-en.pdf.

68 См. https://www.icann.org/resources/board-material/resolutions-2018-07-18-en#2.f.

69 Возражение, стр. 1.

70 https://www.icann.org/en/system/files/files/reconsideration-18-5-dotmusic-bamc-recommendation-attachment-2-14jun18-en.pdf (выделение добавлено).

71 Возражение, стр. 1.

72 Блок-схема будет обновлена для уточнения данного момента в соответствии с нормами рассмотрения и обновления документации по процессам ICANN

73 Принятие Правлением подробного плана реализации является отклонением от блок-схемы процесса проведения организационной проверки, но этот этап соответствует стандартной практике организационных проверок, поскольку у Правления есть фидуциарная обязанность рассматривать и одобрять указанный подробный план реализации Блок-схема будет обновлена в соответствии с нормами рассмотрения и обновления документации по процессам ICANN

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."