Skip to main content
Resources

Утвержденные решения | Заседание Комитета по вопросам программы новых рДВУ

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

Настоящий документ был переведен на несколько языков только для информационных целей. Оригинал и аутентичный текст документа (на английском языке) находится по адресу: http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-10sep13-en.htm

 

  1. Согласованная повестка дня
    1. Утверждение протокола заседания КПНР
  2. Основная повестка дня
    1. Обновленная информация о схожести строк
    2. Рекомендация КУП по запросу на пересмотр 13-5
    3. Коммюнике ПКК, Дурбан – Оценочный лист
    4. Коммюнике ПКК, Пекин – Оценочный лист
    5. Коммюнике ПКК, Пекин – Категория
    6. Заявление РКК о предпочтительном рассмотрении заявок сообществ в случаях разногласий в отношении строк
    7. Заявление РКК в отношении опыта сообществ по оценке приоритета сообществ
    8. Разное

 

  1. Согласованная повестка дня:

    1. Утверждение протокола заседания КПНР

      Принято решение (2013.09.10.NG01): Правление настоящим утверждает протоколы заседаний Комитета по вопросам программы ввода новых рДВУ от 13 июля 2013 г. и 17 июля 2013 г.

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

    1. Обновленная информация о схожести строк

      Никаких решений не принято.

    2. Рекомендация КУП по запросу на пересмотр 13-5

      Принимая во внимание, что Booking.com B.V.'s («Booking.com») представил запрос на пересмотр 13-5, указывающий на необходимость пересмотра решения персонала ICANN от 26 февраля 2013 г., когда были опубликованы результаты Комиссии экспертов по схожести строк для программы ввода новых рДВУ, в результате чего заявки на .hotels и .hoteis были объединены в группу, как конкурирующие по принципу схожести строк.

      Принимая во внимание, что КУП рассмотрел вопросы, поднятые в запросе на пересмотр 13-5.

      Принимая во внимание, что КУП рекомендовал отклонить запрос на пересмотр 13-5, поскольку Booking.com не привел достаточные основания для пересмотра.

      Принято решение (2013.09.10.NG02): Комитет по вопросам программы ввода новых рДВУ настоящим принимает рекомендацию КУП по запросу на пересмотр 13-5, с которой можно ознакомиться по адресу http://www.icann.org/en/groups/board/governance/reconsideration/recommendation-booking-01aug13-en.pdf [PDF, 117 KB].

      Обоснование решения 2013.09.10.NG02

      Устав ICANN содержит положение о том, что Комитет управления Правления должен оценивать требования о пересмотре и формулировать рекомендации Правлению. См. раздел 3 Статьи IV Устава. Комитет по вопросам программы ввода новых рДВУ («КПНР»), которому Правление делегировало полномочия по решению данной проблемы, рассмотрел и тщательно обсудил рекомендацию КУП в отношении требования о пересмотре 13-5, и пришел к выводу о правильности выполненной проверки.

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

      Податель запроса ходатайствует о пересмотре решения Комиссии экспертов по схожести строк («Комиссии») от 26 февраля 2013 г. о помещении заявки Booking.com на .hotels в одну конкурирующую группу с .hoteis. В частности, Booking.com утверждает, что строка .hotels, на которую она подала заявку, может сосуществовать в корневой зоне со строкой hoteis, на которую подана заявка, не вызывая путаницы, и, таким образом, .hotels не следовало помещать в одну конкурирующую группу с .hoteis.

      Для рассмотрения запроса требовалось ответить на следующие вопросы: (1) нарушила ли Комиссия какую-либо политику или процедуру при проведении проверки на визуальную схожесть заявки Booking.com; и (2) обладает ли КПНР полномочиями отменить решение Комиссии в отношении .hotels/.hoteis на основании того, что это решение было представлено в виде «рекомендации для ICANN», и того, что ICANN приняла окончательное решение о том, чтобы принять эту рекомендацию.

      КУП отметил, что подобный запрос на пересмотр подан Booking.com ранее, 28 марта 2013 года, и его рассмотрение было приостановлено до получения ответа на запрос в соответствии с «Политикой раскрытия информации по документам» корпорации ICANN. Таким образом, дата запроса соответствует дате его первоначальной регистрации и он должен рассматриваться в соответствии с Уставом, который действовал с 20 декабря 2012 г. по 10 апреля 2013 г.

      Рассматривая первый вопрос, КУП проанализировал аргументы, изложенные в запросе, включая приложения, и пришел к выводу, что Booking.com не смог адекватно изложить запрос на пересмотр действий персонала, поскольку не смог назвать какую-либо политику или процедуру, которая была нарушена персоналом. КУП отмечает, что Booking.com не выдвигает предположение о том, что не была соблюдена процедура проверки на схожесть строк, прописанная в Руководстве для кандидата, или же что персонал ICANN нарушил какую-либо установленную ICANN политику, утвердив решение Комиссии поместить .hotels и .hoteis в одну конкурирующую группу. Скорее, Booking.com стремится подменить тем, что, по его мнению, должно быть методологией оценки визуальной схожести, методологию, прописанную в Разделе 2.2.1.1.2 Руководства для кандидата, и просит КУП (Правление – через Комитет по вопросам ввода новых рДВУ) пересмотреть решение от 26 февраля 2013 года, основываясь на предлагаемой им методологии. КУП пришел к заключению, что это не является достаточным основанием для пересмотра, поскольку процесс пересмотра не является механизмом для пересмотра решений комиссий по оценке.

      Что касается довода Booking.com о том, что решение от 26 февраля 2013 года было принято без учета существенной информации, такой как мнение эксперта Booking.com по лингвистике или иной «информации, которая опровергала бы ошибочное предположение о вероятности возникновения у потребителей путаницы в отношении ".hotels" и "hoteis"», КУП пришел к заключению, что в проверке на схожесть строк отсутствует процедура, предусматривающая подачу кандидатами дополнительной информации. Как уже поясняла ICANN в ответ на запросы Booking.com в рамках ПРИД на документацию, связанную с проверкой на схожесть строк, эта проверка основана на методологии, прописанной в Руководстве для кандидата и дополненной рабочей документацией Комиссии, сама же процедура не предусматривает использование дополнительных материалов. КУП указывает, что несогласие Booking.com с тем, что применение данной методологии должно было вылиться в выявление визуальной схожести, не означает, что ICANN (включая представляющих третью сторону поставщиков услуг, которые выполняют проверку на схожесть строк) нарушила какую бы то ни было политику, принимая данное решение (равно как и не подтверждает вывод о том, что это решение было на самом деле ошибочным).

      Рассматривая второй вопрос, КУП определил, что предположение Booking.com о том, что Правление (через Комитет по вопросам ввода новых рДВУ) имеет возможность отменить решение Комиссии по .hotels/.hoteis на основании того, что Комиссия просто предоставила «рекомендацию ICANN» и что ICANN приняла окончательное решение по принятию этой рекомендации, основано на неверных представлениях о процедуре проверки на схожесть строк. В результате, КУП пришел к заключению, что Booking.com не привел достаточных оснований для пересмотра. КУП указал, что все строки, на которые поданы заявки, анализируются Комиссией в соответствии со стандартами и методологией анализа визуальной схожести строк, прописанными в Руководстве для кандидата. В Руководстве разъясняется, что сразу после формирования Комиссией экспертов конкурирующих групп ICANN уведомит об этом кандидатов и опубликует результаты на своей сайте. (РДК, Раздел 2.2.1.1.1.) Независимо от того, предоставляются ли результаты в виде «рекомендаций», «итогов» или «отчетов», ICANN всегда подчеркивала, что будет опираться на рекомендации экспертов по оценке на этапе первоначальной оценки программы ввода новых рДВУ при условии соблюдения мер по обеспечению качества. Последующее получение и рассмотрение рекомендации ПКК относительно строк с формами единственного и множественного числа не меняет установленную процедуру формирования конкурирующих групп, основанную на визуальной схожести, поскольку согласно Уставу Правление ICANN должно рассматривать рекомендации ПКК по вопросам общественной политики, таким как строки с формами единственного и множественного числа. КУП пришел к выводу, что Booking.com, указывая, что перед завершением формирования конкурирующих групп ICANN должна выполнить предметную проверку (вместо рабочей проверки) результатов Комиссии по схожести строк, тем самым фактически предлагает новую и отличную от существующей процедуру.

      В добавление к вышесказанному, полный текст рекомендации КУП, который можно посмотреть по адресу: http://www.icann.org/en/groups/board/governance/reconsideration/recommendation-booking-01aug13-en.pdf [PDF, 117 KB] и который прилагается к справочным материалам к представлению Правления, поддерживающему это решение, также должен считаться частью данного Обоснования.

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

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

    3. Коммюнике ПКК, Дурбан – Оценочный лист

      Принимая во внимание, что 18 июля 2013 г., в ходе конференции ICANN-47 в Дурбане, ПКК провел свое заседание и представил коммюнике («Дурбанское коммюнике)».

      Принимая во внимание, что 1 августа 2013 г. ICANN опубликовал Дурбанское коммюнике и официально уведомил кандидатов об этих рекомендациях <http://newgtlds.icann.org/en/announcements-and-media/announcement-01aug13-en>, начав отсчет 21-дневного периода подачи отзывов кандидатов в соответствии с положениями Модуля 3.1 Руководства для кандидата.

      Принимая во внимание, что 12 августа 2013 г. КПНР собрался на заседание, чтобы обсудить план реагирования на рекомендации ПКК в отношении программы ввода новых рДВУ, изложенные Правлению в Дурбанском коммюнике.

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

      Принимая во внимание, что в ответ на рекомендации ПКК, изложенные в Дурбанском коммюнике, КПНР составил оценочный лист, подобный оценочному листу, использованному в ответ на Пекинские рекомендации и в ходе заседаний ПКК и Правления 28 февраля и 1 марта 2011 г. в Брюсселе, отметив пункты, по которым позиция КПНР совпадает с рекомендациями ПКК, как пункты «1А».

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

      Принято решение (2013.09.10.NG03): КПНР принимает «Оценочный лист Комитета по вопросам программы ввода новых рДВУ Правления ICANN в ответ на Дурбанское коммюнике ПКК» (от 10 сентября 2013 г.), прилагаемый в качестве Приложения 1 [PDF, 119 КБ] к данному решению, в ответ на пункты рекомендации ПКК в Дурбанском коммюнике, представленные в оценочном листе.

      Обоснование решения 2013.09.10.NG03

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

      Раздел 2.1 статьи XI Устава ICANN <http://www.icann.org/ru/about/governance/bylaws#XI> разрешает ПКК «ставить вопросы непосредственно перед Правлением – в виде комментария или предварительной рекомендации, либо предложив определенное действие, разработку новой политики или пересмотр существующих политик». ПКК представил Правлению свои рекомендации в отношении программы ввода новых рДВУ в своем Дурбанском коммюнике от 18 июля 2013 года. Устав ICANN требует от Правления учитывать рекомендации ПКК по вопросам общественной политики при разработке и принятии политики. Если Правление решит осуществить действие, которое не отвечает рекомендациям ПКК, оно обязано уведомить ПКК, изложив причины, по которым принято решение не придерживаться данных рекомендаций. После этого Правление и ПКК должны попытаться прийти к взаимоприемлемому решению, сотрудничая в духе добросовестных отношений. Если такое решение найти не удастся, Правление сформулирует в своем окончательном решении причины, по которым рекомендация ПКК не была выполнена.

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

      КПНР предложено рассмотреть возможность принятия Дурбанской рекомендации ПКК, изложенной в прилагаемом «Оценочном листе Комитета по вопросам программы ввода новых рДВУ Правления ICANN в ответ на Дурбанское коммюнике ПКК» (от 10 сентября 2013 г.). Как отмечается в Оценочном листе, большинство пунктов рекомендации получили оценку «1A». Это означает, что позиция КПНР совпадает с рекомендацией ПКК, приведенной в Оценочном листе.

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

      1 августа 2013 г. ICANN опубликовала рекомендации ПКК и официально уведомила кандидатов об этих рекомендациях <http://newgtlds.icann.org/en/announcements-and-media/announcement-01aug13-en>, начав отсчет 21-дневного периода подачи отзывов кандидатов в соответствии с положениями Модуля 3.1 Руководства для кандидата. Полный перечень отзывов кандидатов можно просмотреть по адресу: http://newgtlds.icann.org/en/applicants/gac-advice/durban47. КПНР соответствующим образом учел отзывы кандидатов при подготовке своего ответа на рекомендации ПКК.

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

      В ходе 21-дневного периода подачи отзывов кандидатов несколько кандидатов указали, что вступили в диалог с заинтересованными сторонами и ожидают достижения договоренности по проблемным областям. Некоторые кандидаты, отметившие, что они предложили дополнительные механизмы защиты, призванные решить проблемы, вызывающие беспокойство у правительств, не уверены, что таковая договоренность может быть достигнута. Эти кандидаты попросили Правление ICANN дать разрешение на дальнейшее рассмотрение их заявок даже в том случае, если достичь договоренности между заинтересованными сторонами не удастся. Кроме того, поступали запросы в отношении того, будут ли кандидаты и правительства иметь возможность высказываться по поводу обсуждений, проходящих между ПКК, Правлением ICANN и персоналом ICANN. Были просьбы о том, чтобы ПКК, КПНР и персонал ICANN консультировались с кандидатами перед принятием решений в отношении любых дополнительных механизмов защиты.

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

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

      В ходе обсуждений КПНР рассмотрел следующие материалы и документы:

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

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

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

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

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

      В связи с принятием этого решения не предвидится никаких финансовых последствий.

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

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

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

      ICANN опубликовала рекомендации ПКК и официально уведомила кандидатов о данной рекомендации 1 августа 2013 года. После этого, в соответствии с положениями Модуля 3.1 Руководства кандидата, начался отсчет 21-дневного периода подачи отзывов кандидатов.

    4. Коммюнике ПКК, Пекин – Оценочный лист

      Никаких решений не принято.

    5. Коммюнике ПКК, Пекин – Категория 1

      Никаких решений не принято.

    6. Заявление РКК о предпочтительном рассмотрении заявок сообществ в случаях разногласий в отношении строк

      Никаких решений не принято.

    7. Заявление РКК в отношении опыта сообществ по оценке приоритета сообществ

      Никаких решений не принято.

    8. Разное

      Никаких решений не принято.

resolutions-new-gtld-10sep13-ru.pdf  [284 KB]

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."