Skip to main content
Resources

Mecanismos de Responsabilidad

Esta página está disponible en:

La ICANN ha demostrado su compromiso con la responsabilidad y la transparencia en todas sus prácticas. Considera que estos principios son medidas de protección fundamentales para garantizar que el modelo de múltiples partes interesadas ascendentes continúe siendo efectivo. Los mecanismos mediante los cuales la ICANN logra que la responsabilidad y la transparencia están incorporados en todos los niveles de la organización y su mandato, comenzando con los Estatutos, detallados en sus Principios y Marcos para la Responsabilidad y Transparencia (adoptados por la Junta Directiva de la ICANN en 2008), y anualmente reforzados en su Plan Estratégico y Operativo. Para reforzar su transparencia y responsabilidad, la ICANN ha establecido mecanismos de responsabilidad para revisar sus acciones. Si bien el texto completo de los mecanismos de responsabilidad se establece en los Artículos IV y V de los Estatutos de la ICANN, a continuación se brinda un panorama resumido e ilustrativo de dichos mecanismos.

Proceso de reconsideración

La reconsideración es un mecanismo estipulado en el Artículo IV, Sección 2 de los Estatutos mediante el cual cualquier persona u organismo afectados considerablemente por una acción (u omisión de una acción) de la ICANN puede solicitar la revisión o reconsideración de la Junta Directiva de esta acción.

Toda persona o entidad puede presentar una solicitud de reconsideración o revisión de una acción o inacción de la ICANN ("Solicitud de Reconsideración") en la medida en se hubiese visto afectado por:

  1. una o más acciones u omisiones del personal que contradigan lo establecido por las políticas de ICANN; o
  2. una o varias acciones o inacciones de la Junta Directiva de la ICANN que se hubiesen tomado o denegado sin la consideración de información significativa, relevante excepto cuando la parte que presenta la solicitud hubiese podido presentar la información para la consideración de la Junta Directiva en el momento de la acción o denegación y no lo hubiese hecho; o
  3. una o más acciones o inacciones de la Junta Directiva de la ICANN llevadas a cabo como consecuencia de que la Junta Directiva se basó en información significativa relevante falsa o inexacta.

Ante la falta de observación de estos estándares, el proceso de reconsideración no es un mecanismo para la reconsideración de una acción (u omisión de la misma) simplemente porque la persona o entidad no está de acuerdo con dicha acción (o inacción).

Todas las Solicitudes de Reconsideración se deben presentar dentro de los 15 días con posterioridad a:

  1. En el caso de las solicitudes que cuestionen las acciones de la Junta Directiva, la fecha de la primera publicación en una resolución de la información sobre la acción de la Junta que esté siendo impugnada, a menos que la publicación de la resolución no esté acompañada de los fundamentos. En dicha instancia, la solicitud debe ser presentada dentro de los 15 días a partir de la publicación inicial de los fundamentos; o
  2. En caso de impugnación a una acción del personal, la fecha en que la parte que presenta la solicitud tomó conocimiento ?o razonablemente debería haber tomado conocimiento ? de la acción del personal que esté siendo impugnada; o
  3. En caso de impugnación de una inacción ya sea de la Junta Directiva o del personal, la fecha en que la persona afectada concluyó razonablemente ?o razonablemente debería haber concluido?, que la acción no se tomaría en el momento oportuno.

Las solicitudes de reconsideración son evaluadas y consideradas por el Comité de Gobernanza de la Junta Directiva (BGC). Para todas las solicitudes de reconsideración presentadas en relación a una acción u omisión por parte del personal, el BGC deberá delegar la autoridad a la Junta Directiva para que tome una decisión definitiva y realice recomendaciones al respecto. No se requiere la consideración por parte de la Junta Directiva de la recomendación. Conforme el BGC lo considere necesario, puede efectuar recomendaciones a la Junta Directiva para que las considere y tome acción.

El BGC deberá tomar una decisión final o efectuar una recomendación a la Junta Directiva dentro de un plazo de 30 días posteriores a la recepción de la solicitud de reconsideración, a menos que sea impracticable. En caso de que la reconsideración sea realizada por el BGC a la Junta Directiva, la Junta Directiva deberá emitir su decisión sobre la recomendación del BGC dentro de los 60 días de haber recibido en la Solicitud de Reconsideración o tan pronto como sea posible, una vez recibida dicha solicitud.

La ICANN ha determinado que el proceso de reconsideración puede ser adecuadamente invocado para impugnar las determinaciones de los expertos emitidas por paneles formados por proveedores de servicios de resolución de disputas contratados en el marco del Programa de los Nuevos gTLD, en caso de que el reclamo sea que el panel no cumplió con los procesos o políticas establecidos para llegar a la determinación del experto, o que el personal no cumplió con las políticas o procesos al momento de aceptar la determinación.

Para más información sobre el proceso de reconsideración de la ICANN, véase el Artículo IV de los Estatutos en http://www.icann.org/en/about/governance/bylaws#IV, o la Página de Reconsideraciones.

Proceso de Revisión Independiente (IRP)

Además del Proceso de reconsideración, la ICANN también ha establecido un proceso para una revisión por parte de un tercero independiente sobre las acciones o inacciones de la Junta Directiva señaladas como incompatibles con respecto a las Actas Constitutivas y los Estatutos de la ICANN por una parte damnificada. Véase Artículo IV, Sección 3 de los Estatutos de la ICANN.

Cualquier persona materialmente afectada por una decisión o una acción de la Junta Directiva que manifieste que la misma incumple con las Actas de Constitución o los Estatutos, puede presentar una solicitud para la revisión independiente de dicha decisión o acción. Para considerarse materialmente afectada, la persona debe sufrir un daño o perjuicio que esté conectado directa y causalmente a la supuesta infracción de los Estatutos o el Acta Constitutiva por parte de la Junta Directiva, y no como resultado de un tercero que actúe en consonancia con las medidas tomadas por la Junta Directiva.

Una solicitud de IRP se debe presentar dentro de los treinta días de la publicación de las actas de la reunión de la Junta Directiva (y los materiales de resumen de la Junta Directiva que acompañen, si se encuentran disponibles) que la parte solicitante reclame para demostrar que la ICANN violó sus Estatutos o Actas Constitutivas. En el caso de las solicitudes de IRP relacionadas con una decisión del BGC sobre una solicitud de reconsideración, dichas solicitudes se deben presentar dentro de un plazo de 30 días de la publicación de las actas de la reunión del BGC en la cual se emitió la determinación en cuestión.

Antes de iniciar un proceso de revisión independiente, se insta a la parte reclamante a celebrar un período de compromiso de cooperación con la ICANN con el fin de resolver o acotar las cuestiones contempladas para presentarse ante el IRP. Véase http://www.icann.org/en/news/irp/cep-11apr13-en.pdf.

Para más información sobre el proceso de revisión independiente de la ICANN, véase el Artículo IV, Sección 3 de los Estatutos en http://www.icann.org/en/about/governance/bylaws#IV, o la Página del Proceso de Revisión Independiente.

Defensor del Pueblo

El Defensor del Pueblo de la ICANN es una figura neutral, imparcial e independiente cuya función es brindar una evaluación interna independiente de los reclamos por parte de los miembros de la comunidad de la ICANN quienes creen que han recibido un trato injusto por parte del personal de la ICANN, la Junta Directiva o una unidad constitutiva de la organización, en relación a cuestiones que no pueden estar sujetas al Proceso de Reconsideración o al Proceso de Revisión Independiente. El Defensor del Pueblo actuará con el objetivo de abogar por la equidad y se esforzará por evaluar —y cuando sea posible resolver— los reclamos sobre el tratamiento injusto o inadecuado por parte del personal, la Junta Directiva o los órganos constitutivos de la ICANN, aclarando los conflictos y utilizando herramientas de resolución de problemas tales como: negociación, facilitación y viajes diplomáticos para lograr estos resultados. Véase Artículo V de los Estatutos de la ICANN.

El Defensor del pueblo no posee la facultad de crear, cambiar o dejar sin efecto una política, decisión, acto u omisión de carácter administrativo o de la Junta Directiva. El Defensor del Pueblo tiene la facultad de investigar estos hechos, y utilizar la técnica de Resolución Alternativa de Disputas para resolverlos. El Defensor del Pueblo está específicamente autorizado para elaborar tales informes para la Junta Directiva que considere adecuados con relación a una cuestión en particular y su resolución, o la incapacidad de resolverlo.

Para más información sobre el Defensor del Pueblo, véase el Artículo V de los Estatutos en http://www.icann.org/en/about/governance/bylaws#V o la Página del Defensor del Pueblo.

¿Qué es la Comunidad Empoderada?

La Comunidad Empoderada es el mecanismo por medio del cual las Organizaciones de Apoyo (SO) y los Comités Asesores (AC) de la ICANN pueden organizarse en virtud de las leyes de California para aplicar legalmente las facultades de la comunidad. Las facultades y las normas de la comunidad que gobiernan a la Comunidad Empoderada se definen en las Actas Constitutivas y los Estatutos de la ICANN.

¿Quiénes pueden participar en la Comunidad Empoderada?

Todas las Organizaciones de Apoyo, el Comité Asesor Gubernamental y el Comité Asesor At-Large de la ICANN pueden participar de la Comunidad Empoderada. Están incluidos:

¿De qué manera utiliza sus facultades la Comunidad Empoderada?

La Comunidad Empoderada tiene un proceso para expresar las inquietudes relacionadas con una acción o inacción de parte de la organización o la Junta Directiva de la ICANN. Este proceso de escalonamiento les brinda oportunidades a las Organizaciones de Apoyo (SO) y a los Comités Asesores (AC) de debatir soluciones con la Junta Directiva de la ICANN.

Para más información, pueden acceder a la página de la Comunidad Empoderada haciendo clic aquí.

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