Skip to main content
Resources

Механизмы подотчетности

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

ICANN продолжает доказывать, что выполняет свои обязательства в отношении подотчетности и транспарентности во всей своей работе. ICANN считает эти принципы фундаментальными мерами защиты обеспечения эффективности своей модели по принципу «снизу-вверх» с участием многих заинтересованных сторон и в будущем. Механизмы, при помощи которых ICANN обеспечивает подотчетность и прозрачность, встроены во все уровни и нормативные документы организации, начиная с Устава, подробно описаны в документе Системы и принципы подотчетности и прозрачности (принятом Правлением ICANN в 2008 году) и ежегодно подтверждаются в стратегическом и операционном плане ICANN. В целях укрепления прозрачности и подотчетности ICANN разработала механизмы подотчетности для анализа деятельности ICANN. Полное описание механизмов подотчетности приведено в статьях IV и V Устава ICANN, а далее приводится краткая сводка и примерное описание этих механизмов.

Процесс пересмотра ранее принятых решений

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

Любое лицо или организация может направить требование о пересмотре действия или бездействия ICANN («требование о пересмотре») в той степени, в которой этому лицу или организации был нанесен ущерб вследствие:

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

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

Все требования о пересмотре должны быть поданы в течение пятнадцати дней с момента:

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

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

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

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

Более подробные сведения о процедуре пересмотра ранее принятых решений ICANN см. в статье IV Устава по адресу http://www.icann.org/en/about/governance/bylaws#IV, или на странице процедуры пересмотра.

Процесс независимых проверок (IRP)

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

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

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

Прежде чем подавать запрос о проведении независимой проверки, истца призывают постараться решить или сузить круг проблем, которые предполагается выносить на рассмотрение в рамках независимой проверки, в рамках процесса ICANN для разрешения споров по обоюдному согласию. См. http://www.icann.org/en/news/irp/cep-11apr13-en.pdf.

Более подробные сведения о процедуре независимых проверок ICANN см. в разделе 3 статьи IV Устава по адресу http://www.icann.org/en/about/governance/bylaws#IV или на странице процесса независимых проверок.

Омбудсмен

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

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

Более подробные сведения о механизме омбудсмена ICANN см. в статье V Устава по адресу http://www.icann.org/en/about/governance/bylaws#V или на странице омбудсмена.

Что такое наделенное полномочиями сообщество?

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

Кто имеет право войти в состав наделенного полномочиями сообщества?

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

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

Наделенное полномочиями сообщество определило порядок выражения обеспокоенности действиями или бездействием Правления или корпорации ICANN. Эта процедура эскалации проблем предоставляет организациям поддержки и консультативным комитетам возможность обсудить способы их разрешения с Правлением 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."