Skip to main content
Resources

Resoluciones Aprobadas | Reunión Ordinaria de la Junta Directiva de la ICANN

Esta página está disponible en:

  1. Orden del día convenido:
    1. Aprobación de las actas de las reuniones de la Junta Directiva
    2. Redelegación del dominio .MK y delegación del dominio .мкд, que representan a la Ex República Yugoslava de Macedonia en la Red Académica y de Investigación Skopje de Macedonia
    3. Delegación del dominio გე ("ge"), que representa a Georgia en georgiano (alfabeto mkhedruli) al Centro de Desarrollo de Tecnologías de la Información
    4. Extensión de la fecha de eliminación del ccTLD .AN (Antillas Holandesas)
    5. Enmiendas a la Carta Orgánica del Grupo de Partes Interesadas de Registradores
    6. Agradecimiento a los Miembros de la Comunidad
    7. Agradecimiento a los patrocinadores de la Reunión N.º 51 de la ICANN
    8. Agradecimiento a los intérpretes, el personal y los equipos del hotel y eventos de la Reunión N.º 51 de la ICANN
  2. Orden del día principal
    1. Agradecimiento al Comité de Nominaciones 2014
    2. Introducción de nombres de dominio de dos caracteres en el espacio de nombres de los nuevos gTLD
    3. Plan Estratégico de la ICANN para los años fiscales 2016 a 2020
    4. Consideración de la Junta Directiva de las Recomendaciones del Grupo de Trabajo de Intercambio de la Comunidad sobre la Mejora de la Responsabilidad de la ICANN
    5. Agradecimiento a Olga Madruga-Forti por los servicios brindados a la Junta Directiva de la ICANN
    6. Agradecimiento a Sébastien Bachollet por los servicios prestados a la Junta Directiva de la ICANN
    7. Agradecimiento a Bill Graham por los servicios prestados a la Junta Directiva de la ICANN
    8. Agradecimiento a Heather Dryden por los servicios prestados a la Junta Directiva de la ICANN

 

  1. Orden del día convenido:

    1. Aprobación de las actas de las reuniones de la Junta Directiva

      Resuélvase (2014.10.16.01): la Junta Directiva aprueba las actas de la reunión ordinaria de la Junta Directiva de la ICANN del día 9 de septiembre de 2014.

    2. Redelegación del dominio .MK y delegación del dominio .мкд, que representan a la Ex República Yugoslava de Macedonia en la Red Académica y de Investigación Skopje de Macedonia

      Resuélvase (2014.10.16.02): como parte del ejercicio de sus responsabilidades conforme al Contrato de Funciones de la IANA, la ICANN ha revisado y evaluado la solicitud de redelegación del dominio de alto nivel con código de país .MK y delegación del dominio de alto nivel con código de país IDN .мкд a la Red Académica y de Investigación Skopje de Macedonia. La documentación demuestra que se siguieron los procedimientos adecuados durante la evaluación de la solicitud.

      Resuélvase (2014.10.16.03): La Junta Directiva dispone que —conforme al Artículo III, Sección 5.2 de los Estatutos de la ICANN— los fragmentos de los fundamentos contenidos en las resoluciones, el informe preliminar o las actas cuya divulgación pública no sea apropiada en este momento debido a obligaciones contractuales sean retenidos hasta tanto se autorice su divulgación pública de acuerdo con dichas obligaciones.

      Fundamentos de las resoluciones 2014.10.16.02 a 2014.10.16.03

      ¿Por qué la Junta aborda el tema ahora?

      De acuerdo con el Contrato de Funciones de la IANA, el personal de la ICANN ha evaluado dos solicitudes de redelegación y delegación de un dominio de alto nivel con código de país (ccTLD) y presenta su informe ante la Junta Directiva para su revisión. La revisión por parte de la Junta Directiva tiene por objetivo verificar que el personal de la ICANN haya seguido los procedimientos adecuados.

      ¿Cuál es la propuesta que está siendo considerada?

      La propuesta consiste en aprobar dos solicitudes dirigidas al Departamento de la IANA para asignar y cambiar la organización patrocinadora (denominada también administradora o custodio) de los dominios de alto nivel con código de país .мкд y .MK a la Red Académica y de Investigación Skopje de Macedonia.

      ¿Cuáles son las partes interesadas u otros participantes consultados?

      Durante la evaluación de las solicitudes de delegación y redelegación, el personal de la ICANN consulta al solicitante y a otras partes interesadas. Como parte del proceso de solicitud, es necesario que el solicitante describa las consultas realizadas en el país en relación con el ccTLD y su aplicabilidad a la comunidad local de Internet.

      ¿Qué inquietudes o cuestiones fueron planteadas por la comunidad?

      El personal no tiene conocimiento de ninguna inquietud o cuestión significativa planteada por la comunidad en relación con esta solicitud.

      ¿Qué materiales significativos analizó la Junta Directiva?

      La Junta Directiva analizó las siguientes evaluaciones del personal del Departamento de IANA:

      • Los dominios pueden delegarse de manera continua, ya que MK es un código alfabético de dos caracteres asignado al país Ex República Yugoslava de Macedonia en la lista de la norma ISO 3166-1, mientras que мкд es la cadena de nombre de dominio internacionalizada aprobada para la Ex República Yugoslava de Macedonia.
      • Las solicitudes están aceptadas por la organización patrocinadora existente, el Ministerio de Relaciones Exteriores.
      • Se ha consultado al gobierno pertinente, el cual no se opone a la solicitud.
      • La organización patrocinadora propuesta y sus contactos aceptan sus responsabilidades para la administración de esto dominios.
      • Las propuestas han demostrado el apoyo y la colaboración pertinentes de la comunidad de Internet local.
      • Las propuestas no infringen ninguna legislación ni normativa conocidas.
      • Las propuestas garantizan que los dominios se administrarán localmente en el país y estarán sujetos a la legislación local.
      • La organización patrocinadora propuesta ha confirmado que administrará los dominios de modo justo y equitativo.
      • La organización patrocinadora propuesta ha demostrado las aptitudes técnicas y operativas adecuadas y planea operar los dominios.
      • La configuración técnica propuesta satisface los diversos requisitos de cumplimiento técnico del Departamento de IANA.
      • No se han identificado riesgos ni preocupaciones en particular en relación con la estabilidad de Internet.
      • El personal ha recomendado que se implementen estas solicitudes en función de los factores considerados.

      Estas evaluaciones responden a los criterios y marcos de trabajo de políticas pertinentes, tales como "Estructura y delegación del Sistema de Nombres de Dominio de Internet" (RFC 1591) y "Principios y Directrices del GAC para la delegación y administración de los dominios de alto nivel con código de país".

      Como parte del proceso establecido por el Contrato de Funciones de la IANA, en http://www.iana.org/reports se publicará el "Informe de Delegación y Redelegación".

      ¿Qué factores la Junta Directiva consideró significativos?

      La Junta Directiva no identificó ningún factor específico importante respecto de estas solicitudes.

      ¿Existen impactos positivos o negativos para la comunidad?

      La aprobación oportuna de administradores de nombres de dominio con código de país que cumplen con los diversos criterios de interés público no sólo tiene un impacto positivo para la misión de la ICANN a nivel general y para las comunidades locales a las que están destinados dichos dominios, sino que además responde a las obligaciones de la ICANN previstas en el Contrato de Funciones de la IANA.

      ¿Se observan impactos financieros o ramificaciones en la ICANN (plan estratégico, plan operativo, presupuesto), la comunidad y/o el público?

      La administración de las delegaciones de dominios con código de país en la zona raíz del DNS forma parte de las funciones de la IANA y, por ello, la acción de delegación no debería causar variaciones de importancia en los gastos ya planificados. No corresponde a la ICANN evaluar el impacto financiero de las operaciones internas de los nombres de dominio con código de país dentro de un país.

      ¿Se observan cuestiones sobre seguridad, estabilidad o flexibilidad relacionadas con el DNS?

      La ICANN considera que estas solicitudes no implican riesgos significativos para la seguridad, la estabilidad ni la flexibilidad.

      Esta decisión forma parte de las funciones administrativas y organizativas que no requieren comentarios públicos.

    3. Delegación del dominio გე ("ge"), que representa a Georgia en georgiano (alfabeto mkhedruli) al Centro de Desarrollo de Tecnologías de la Información

      Resuélvase (2014.10.16.04): como parte del ejercicio de sus responsabilidades conforme al Contrato de Funciones de la IANA, la ICANN ha revisado y evaluado la solicitud de delegación del dominio de alto nivel con código de país გე al Centro de Desarrollo de Tecnologías de la Información (ITDC). La documentación demuestra que se siguieron los procedimientos adecuados durante la evaluación de la solicitud.

      Resuélvase (2014.10.16.05): La Junta Directiva dispone que —conforme al Artículo III, Sección 5.2 de los Estatutos de la ICANN— los fragmentos de los fundamentos contenidos en las resoluciones, el informe preliminar o las actas cuya divulgación pública no sea apropiada en este momento debido a obligaciones contractuales sean retenidos hasta tanto se autorice su divulgación pública de acuerdo con dichas obligaciones.

      Fundamentos de las resoluciones 2014.10.16.04 a 2014.10.16.05

      ¿Por qué la Junta aborda el tema ahora?

      De acuerdo con el Contrato de Funciones de la IANA, el personal de la ICANN ha evaluado una solicitud de delegación de un dominio de alto nivel con código de país (ccTLD) y presenta su informe ante la Junta Directiva para revisión. La revisión por parte de la Junta Directiva tiene por objetivo verificar que el personal de la ICANN haya seguido los procedimientos adecuados.

      ¿Cuál es la propuesta que está siendo considerada?

      La propuesta consiste en aprobar una solicitud dirigida a la IANA para crear el dominio de alto nivel con código de país y asignar la función de organización patrocinadora (denominada también administrador o apoderado) al Centro de Desarrollo de Tecnologías de la Información (ITDC).

      ¿Cuáles son las partes interesadas u otros participantes consultados?

      Durante la evaluación de una solicitud de delegación, el personal de la ICANN consulta al solicitante y a otras partes interesadas. Como parte del proceso de solicitud, es necesario que el solicitante describa las consultas realizadas en el país en relación con el ccTLD y su aplicabilidad a la comunidad local de Internet.

      ¿Qué inquietudes o cuestiones fueron planteadas por la comunidad?

      El personal no tiene conocimiento de ninguna inquietud o cuestión significativa planteada por la comunidad en relación con esta solicitud.

      ¿Qué materiales significativos analizó la Junta Directiva?

      La Junta Directiva analizó las siguientes evaluaciones del personal del Departamento de IANA:

      • El dominio es apto para la delegación, ya que es una cadena aprobada por el proceso de Avance Acelerado de Dominios de Alto Nivel con Código de País de Nombres de Dominio Internacionalizados (IDN ccTLD) y representa un país incluido en el estándar ISO 3166-1.
      • Se ha consultado al gobierno pertinente, el cual no se opone a la solicitud.
      • La organización patrocinadora propuesta y sus contactos aceptan sus responsabilidades para la administración de este dominio;
      • La propuesta ha demostrado el apoyo y la colaboración pertinentes de la comunidad de Internet local;
      • La propuesta no infringe ninguna legislación o normativa conocida;
      • La propuesta garantiza que el dominio se administre localmente en el país y está sujeta a la legislación local;
      • La organización patrocinadora propuesta ha confirmado que administrará el dominio de modo justo y equitativo;
      • La organización patrocinadora propuesta ha demostrado las aptitudes técnicas y operativas adecuadas y planea operar el dominio;
      • La configuración técnica propuesta satisface los diversos requisitos de cumplimiento técnico del Departamento de IANA.
      • No se han identificado riesgos ni preocupaciones en particular en relación con la estabilidad de Internet.
      • El personal ha recomendado que se implemente esta solicitud en función de los factores considerados.

      Estas evaluaciones responden a los criterios y marcos de trabajo de políticas pertinentes, tales como "Estructura y delegación del Sistema de Nombres de Dominio de Internet" (RFC 1591) y "Principios y Directrices del GAC para la delegación y administración de los dominios de alto nivel con código de país".

      Como parte del proceso establecido por el Contrato de Funciones de la IANA, en http://www.iana.org/reports se publicará el "Informe de Delegación y Redelegación".

      ¿Qué factores la Junta Directiva consideró significativos?

      La Junta Directiva no identificó ningún factor específico importante respecto de esta solicitud.

      ¿Existen impactos positivos o negativos para la comunidad?

      La aprobación oportuna de administradores de nombres de dominio con código de país que cumplen con los diversos criterios de interés público no sólo tiene un impacto positivo para la misión de la ICANN a nivel general y para las comunidades locales a las que están destinados dichos dominios, sino que además responde a las obligaciones de la ICANN previstas en el Contrato de Funciones de la IANA.

      ¿Se observan impactos financieros o ramificaciones en la ICANN (plan estratégico, plan operativo, presupuesto), la comunidad y/o el público?

      La administración de las delegaciones de dominios con código de país en la zona raíz del DNS forma parte de las funciones de la IANA y, por ello, la acción de delegación no debería causar variaciones de importancia en los gastos ya planificados. No corresponde a la ICANN evaluar el impacto financiero de las operaciones internas de los nombres de dominio con código de país dentro de un país.

      ¿Se observan cuestiones sobre seguridad, estabilidad o flexibilidad relacionadas con el DNS?

      La ICANN considera que esta solicitud no implica riesgos significativos para la seguridad, estabilidad o flexibilidad.

      Esta decisión forma parte de las funciones administrativas y organizativas que no requieren comentarios públicos.

    4. Extensión de la fecha de eliminación del ccTLD .AN (Antillas Holandesas)

      Visto y considerando que la asignación del dominio de alto nivel .AN queda anulada después de que el código de país de la norma ISO 3166-1 fuera sustituido por los nuevos códigos.

      Visto y considerando que el 11 de octubre de 2011 la Junta Directiva resolvió que el dominio .AN debe retirarse para el 31 de octubre de 2014.

      Visto y considerando que el operador del dominio .AN y el Ministerio de Economía de Holanda solicitaron una prórroga de nueve meses de esta fecha para ofrecer a los registratarios restantes una oportunidad adicional de finalizar la transición para abandonar el dominio .AN.

      Resuélvase (2014.10.16.06): la fecha de vencimiento para la eliminación del dominio .AN de la zona raíz del DNS se posterga hasta el 31 de julio de 2015.

      Justificación de la Resolución 2014.10.16.06

      ¿Por qué la Junta Directiva aborda la cuestión?

      El dominio de alto nivel .AN debe ser eliminado de la zona raíz del DNS para el 31 de octubre de 2014. El operador del dominio .AN y el Ministerio de Economía de Holanda han solicitado una prórroga para la fecha de eliminación.

      ¿Cuál es la propuesta que está siendo considerada?

      Lo que se solicita es una prórroga para la fecha de baja del dominio de alto nivel .AN hasta el 31 de julio de 2015.

      ¿Qué inquietudes o cuestiones fueron planteadas por la comunidad?

      El operador del dominio de alto nivel .AN expresó que, si bien la mayoría de los registratarios de dominios ya migraron a los nuevos dominios, todavía hay una minoría de aproximadamente 30 registratarios que necesitan más tiempo para completar la transición. El operador cree que la fecha de vencimiento actual tal vez no sea suficiente para los registratarios restantes.

      ¿Existen impactos positivos o negativos para la comunidad?

      La aprobación de la prórroga solicitada permite al personal de la ICANN trabajar con el operador actual para finalizar la baja del dominio .AN. Demuestra la diligencia del Departamento de Funciones de la IANA para cumplir con sus obligaciones a la vez que se trabaja con la comunidad para considerar sus necesidades cuando así corresponda.

      ¿Se observan impactos fiscales o ramificaciones en la ICANN (plan estratégico, plan operativo, presupuesto), la comunidad y/o el público?

      La administración de las delegaciones de dominios con código de país en la zona raíz del DNS forma parte de las funciones de la IANA y, por ello, la prórroga de la fecha de baja del dominio .AN no debería causar variaciones de importancia en los gastos ya planificados. No corresponde a la ICANN evaluar el impacto financiero de las operaciones internas de los nombres de dominio con código de país dentro de un país.

      ¿Se observan cuestiones sobre seguridad, estabilidad o flexibilidad relacionadas con el DNS?

      Si se otorga la prórroga solicitada, se ayuda a mantener la seguridad y la estabilidad del nombre de dominio .AN mientras la ICANN trabaja con el operador para eliminar el nombre de dominio de la zona raíz del DNS.

      La presente es una función organizacional y administrativa respecto de la cual no se requiere comentario público.

    5. Enmiendas a la Carta Orgánica del Grupo de Partes Interesadas de Registradores

      Visto y considerando que el Grupo de Partes Interesadas de Registradores (RrSG) de la GNSO ha propuesto una serie de enmiendas a su Carta Orgánica.

      Visto y considerando que el RrSG, el personal de la ICANN y el Comité de Mejoras Estructurales (SIC) han completado todos los requisitos asociados con el Proceso para Enmiendas de las Cartas Orgánicas de Unidades Constitutivas y de Grupos de Partes Interesadas de la GNSO de la Junta Directiva.

      Resuélvase (2014.10.16.07): la Junta Directiva de la ICANN aprueba las Enmiendas a la Carta Orgánica del Grupo de Partes Interesadas de Registradores e indica al personal que proporcione acceso al nuevo documento rector en las páginas web correspondientes para el grupo.

      Justificación de la Resolución 2014.10.16.07

      Los Estatutos de la ICANN (Artículo X, Sección 5.3) establecen que "Cada Grupo de partes interesadas deberá mantener el reconocimiento de la Junta Directiva de la ICANN". La Junta Directiva interpreta que esto significa que la Junta Directiva de la ICANN debe aprobar formalmente toda enmienda que se haga a los documentos rectores de los grupos de partes interesadas (SG) o unidades constitutivas de la Organización de Apoyo para Nombres Genéricos (GNSO).

      En septiembre de 2013, la Junta Directiva estableció un Proceso para Enmiendas de las Cartas Orgánicas de Unidades Constitutivas y de Grupos de Partes Interesadas de la GNSO (el Proceso) para proporcionar una metodología optimizada a fin de cumplir con el requisito de los estatutos.

      El Grupo de Partes Interesadas de Registradores de la GNSO (RrSG), el personal de la ICANN y el Comité de Mejoras Estructurales (SIC) completaron todos los pasos identificados en el Proceso, incluidas la determinación de que las enmiendas propuestas a la carta orgánica no generarán ninguna inquietud fiscal ni de responsabilidades para la organización de la ICANN y la publicación de las enmiendas para recibir el análisis y los comentarios de la comunidad (no se recibieron objeciones).

      No se prevé ningún impacto de esta decisión sobre la seguridad, la estabilidad y la flexibilidad del sistema de nombres de dominio como resultado de esta decisión.

    6. Agradecimiento a los Miembros de la Comunidad

      Visto y considerando que la ICANN desea reconocer la considerable energía y habilidades que los integrantes de la comunidad de partes interesadas proporcionan a los procesos de esta corporación.

      Visto y considerando que, en reconocimiento a estas contribuciones, la ICANN desea reconocer y agradecer a los miembros de la comunidad que finalizan sus períodos de servicio en organizaciones de apoyo y comités asesores.

      Visto y considerando que los siguientes miembros de la comunidad At-Large dejarán de prestar servicio una vez finalizado su período de gestión:

      • Rinalia Abdul Rahim, copresidente del Grupo de Trabajo de At-Large para IDN
      • Fouad Bajwa, vicepresidente de APRALO
      • Olivier Crépin-Leblond, presidente del ALAC
      • Alan Greenberg, coordinador de enlace del ALAC ante la GNSO
      • Philip Johnson, secretaría de la AFRALO
      • Evan Leibovitch, vicepresidente del ALAC (NARALO)
      • Glenn McKnight, secretaría de la NARALO
      • Jean-Jacques Subrenat. miembro del ALAC (EURALO, persona designada por el Comité de Nominaciones)
      • Dev Anand Teelucksingh, miembro del ALAC (LACRALO)

      Resuélvase (2014.10.16.08): Rinalia Abdul Rahim, Fouad Bajwa, Olivier Crépin-Leblond, Alan Greenberg, Philip Johnson, Evan Leibovitch, Glenn McKnight, Jean-Jacques Subrenat y Dev Anand Teelucksingh se han ganado el profundo agradecimiento de la Junta Directiva por los servicios prestados y la Junta Directiva les desea lo mejor en sus emprendimientos futuros dentro y fuera de la comunidad de la ICANN.

      Visto y considerando que el siguiente miembro del Consejo de Direcciones (AC) de la Organización de Apoyo para Direcciones (ASO) concluye su mandato:

      • Naresh Ajawani, miembro del AC de la ASO

      Resuélvase (2014.10.16.09): Naresh Ajawani se ha ganado el profundo agradecimiento de la Junta Directiva por los servicios prestados y la Junta Directiva le desea lo mejor en todos sus emprendimientos futuros dentro y fuera de la comunidad de la ICANN.

      Visto y considerando que los siguientes miembros del Consejo de la Organización de Apoyo para Nombres de Dominio con Código de País (ccNSO) dejarán de prestar servicio una vez finalizado su período de gestión:

      • Keith Davidson, presidente del grupo de trabajo sobre el marco de interpretación
      • Hong Xue, miembro del consejo de la ccNSO

      Resuélvase (2014.10.16.10): Keith Davidson y Hong Xue se han ganado el profundo agradecimiento de la Junta Directiva por los servicios prestados y la Junta Directiva les desea lo mejor en todos sus emprendimientos futuros dentro y fuera de la comunidad de la ICANN.

      Visto y considerando que los siguientes miembros de la Organización de Apoyo para Nombres Genéricos (GNSO) concluirán sus mandatos:

      • John Berard, miembro del Consejo de la GNSO (Unidad Constitutiva Comercial y Empresarial)
      • Ching Chiao, miembro del Consejo de la GNSO (Grupo de Partes Interesadas de Registros)
      • Jeffrey Eckhaus, vicepresidente del Grupo de Partes Interesadas de Registradores
      • Maria Farrell, miembro del Consejo de la GNSO (Unidad Constitutiva de Usuarios No Comerciales)
      • Magaly Pazello, miembro del Consejo de la GNSO (Unidad Constitutiva de Usuarios No Comerciales)
      • Petter Rindforth, miembro del Consejo de la GNSO (Unidad Constitutiva de Intereses de Propiedad Intelectual)
      • Klaus Stoll, miembro del Consejo de la GNSO (Unidad Constitutiva de Preocupaciones Operativas de las Organizaciones Sin Fines de Lucro)
      • Jennifer Wolfe, miembro del Consejo de la GNSO (persona designada por el Comité de Nominaciones)

      Resuélvase (2014.10.16.11): John Berard, Ching Chiao, Jeffrey Eckhaus, Maria Farrell, Magaly Pazello, Petter Rindforth, Klaus Stoll y Jennifer Wolfe se han ganado el profundo agradecimiento de la Junta Directiva por los servicios prestados y la Junta Directiva les desea lo mejor en todos sus emprendimientos futuros dentro y fuera de la comunidad de la ICANN.

      Visto y considerando que los siguientes miembros del Comité de Nominaciones dejarán de prestar servicio una vez finalizado su período de gestión:

      • Ron Andruff, delegado de la Unidad Constitutiva de Usuarios Comerciales y Empresariales
      • Veronica Cretu, delegada del Comité Asesor At-Large
      • William Manning, delegado del RSSAC
      • John McElwaine, delegado de la Unidad Constitutiva de Propiedad Intelectual
      • Russ Mundy, delegado de la IAB para el IETF
      • Vanda Scartezini, delegada del Comité Asesor At-Large

      Resuélvase (2014.10.16.12): Ron Andruff, Veronica Cretu, William Manning, John McElwaine, Russ Mundy y Vanda Scartezini se han ganado el profundo agradecimiento de la Junta Directiva por los servicios prestados y la Junta Directiva les desea lo mejor en todos sus emprendimientos futuros dentro y fuera de la comunidad de la ICANN.

    7. Agradecimiento a los patrocinadores de la Reunión N.º 51 de la ICANN

      La Junta Directiva desea agradecer a los siguientes patrocinadores: Verisign, Inc., Public Interest Registry, Afilias Limited, PDR Solutions FZC, Community.Asia, Neustar, Freenom, China Internet Network Information Center, .GLOBAL, .CLUB Domains, CentralNic, Brandma.Co, NCC Group, Trademark Clearinghouse, Hu Yi Global Information Resources (Holding) Company, HongKong Limited, Uniregistry Corp., ZA Central Registry, Minds + Machines Group, Iron Mountain, Inc., INOC, Radix FZC e ICANNWIKI.

    8. Agradecimiento a los intérpretes, el personal y los equipos del hotel y eventos de la Reunión N.º 51 de la ICANN

      La Junta Directiva expresa su agradecimiento a los escribas (transcriptores), intérpretes, equipo audiovisual, equipos técnicos y todo el personal de la ICANN por los esfuerzos realizados para que la reunión se llevara a cabo en forma correcta y agradable.

      La Junta Directiva también desea agradecer a la gerencia y el personal del Grand Hyatt Century Plaza Hotel por brindar una maravillosa sede para el evento. Se extiende un agradecimiento especial a Kim Aragon, director asociado de planificación de eventos, y Susie Schultz, gerente de ventas internacionales.

  2. Orden del día principal

    1. Agradecimiento al Comité de Nominaciones 2014

      Visto y considerando que la ICANN asignó a Cheryl Langdon-Orr como presidenta del Comité de Nominaciones 2014, Stéphane Van Gelder como presidente electo del Comité de Nominaciones 2014 e Yrjö Länsipuro como presidente asociado.

      Visto y considerando que el Comité de Nominaciones 2014 estaba integrado por delegados de cada unidad constitutiva y cada organismo asesor de la ICANN.

      Resuélvase (2014.10.16.13): la Junta Directiva de la ICANN expresa su profundo agradecimiento a Cheryl Langdon-Orr, Stéphane Van Gelder, Yrjö Länsipuro y todos los miembros del Comité de Nominaciones 2014 (Ron Andruff, Satish Babu, John Berryhill, Alain Bidron, Don Blumenthal, Veronica Cretu, Sarah B. Deutsch, Robert Guerra, Hans Petter Holen, Louis Houle, Juhani Juselius, Brenden Kuerbis, Bill Manning, John McElwaine, Russ Mundy, Vanda Scartezini y Fatimata Seye Sylla) por su dedicación, trabajo arduo y esfuerzos exitosos.

    2. Introducción de nombres de dominio de dos caracteres en el espacio de nombres de los nuevos gTLD

      Visto y considerando que el 4 de diciembre de 2006 el Panel de Evaluación Técnica de los Servicios de Registro (RSTEP) de la ICANN determinó que la liberación propuesta del uso de nombres de dominio de segundo nivel (SLD) de dos caracteres en el gTLD .nombre no creaba un riesgo razonable de que se produjera un efecto adverso para la seguridad y la estabilidad.

      Visto y considerando que en la Especificación 5, sección 2 del Acuerdo de registro sobre nuevos gTLD se indica que las etiquetas de dos caracteres "deben excluirse del registro o se las debe asignar al operador de registro en el segundo nivel. Estas etiquetas no se pueden activar en el DNS, y su registro se puede liberar solamente para el operador de registro, bajo la condición de que dichas cadenas de etiqueta de dos caracteres se puedan liberar en la medida en la que el operador de registro llegue a un acuerdo con el gobierno relacionado y el administrador de códigos de país de la cadena, según se especifica en la norma ISO 3166-1 alfa 2. El operador de registro también puede proponer la liberación de estas reservas en función de la implementación de medidas para evitar confusiones con los códigos de país correspondientes, sujeto a la aprobación de la ICANN".

      Visto y considerando que desde el 18 de enero de 2014 los operadores de registro que representan 207 nuevos gTLD han presentado solicitudes de Política de Evaluación de Servicios de Registro (RSEP) para la implementación de un nuevo servicio de registro que incluye la liberación de diversos conjuntos de etiquetas de dos caracteres.

      Visto y considerando que, para cada solicitud de la RSEP, la ICANN llevó a cabo una determinación preliminar de que el servicio de registro propuesto no generaba ninguna cuestión importante relacionada con la seguridad, la estabilidad ni la competencia (según las definiciones de estos términos en la RSEP).

      Visto y considerando que el Comité Asesor Gubernamental (GAC) indicó que algunos de sus miembros expresaron inquietud en relación con la liberación de nombres de dominio de dos caracteres que sean combinaciones de letra/letra y que, por lo tanto, el GAC planea considerar el tema durante la 51.ª reunión de la ICANN en Los Ángeles.

      Visto y considerando que en su comunicado pronunciado en Los Ángeles [PDF, 127 KB] (15 de octubre de 2014), el GAC observó que "no se encuentra en la posición de ofrecer consejo consensuado acerca del uso de nombres de dominio de segundo nivel de dos caracteres en las nuevas operaciones de gTLD, incluidas las combinaciones de letras que también se encuentran en la lista de la norma ISO 3166-1 alfa 2". El GAC también observó que "al considerar estas solicitudes de la RSEP, y de manera congruente con lo indicado en la Guía para el Solicitante, el GAC considera que el período de comentario público es un mecanismo de transparencia importante y solicita que además la ICANN alerte a los gobiernos pertinentes acerca de estas solicitudes a medida que vayan surgiendo".

      Resuélvase (2014.10.16.14): el servicio de registro propuesto en relación con la liberación de dominios de dos caracteres en el espacio de nombres de gTLD no crea un riesgo razonable de efectos adversos importantes para la seguridad y la estabilidad, por lo que la Junta Directiva autoriza al presidente y director ejecutivo, o las personas que este designe, a desarrollar e implementar un procedimiento eficaz para la liberación de los dominios de dos caracteres que actualmente están reservados en el Acuerdo de Registro de los Nuevos gTLD, teniendo en cuenta los comentarios del GAC en su comunicado pronunciado en Los Ángeles.

      Justificación de la Resolución 2014.10.16.14

      ¿Por qué la Junta Directiva está abordando el tema?

      La sección 2 de la Especificación 5 (Anexo de Nombres Reservados) del Acuerdo de Registro de Nuevos gTLD indica lo siguiente en relación con la reserva de etiquetas de dos caracteres:

      Las etiquetas ASCII de dos caracteres no estarán disponibles para el registro o serán asignadas al operador de registro en el segundo nivel dentro del TLD. Estas etiquetas no se pueden activar en el DNS, y su registro se puede liberar solamente para el operador de registro, bajo la condición de que dichas cadenas de etiqueta de dos caracteres se puedan liberar en la medida en la que el operador de registro llegue a un acuerdo con el gobierno relacionado y el administrador de códigos de país de la cadena, según se especifica en la norma ISO 3166-1 alfa 2. El operador de registro también puede proponer la liberación de estas reservas en función de la implementación de medidas para evitar confusiones con los códigos de país correspondientes, sujeto a la aprobación de la ICANN.

      En enero de 2014, los operadores de registro de nuevos gTLD comenzaron a presentar solicitudes a la ICANN mediante el proceso de la Política de Evaluación de Servicios de Registro (RSEP) en las que se proponía implementar un nuevo servicio de registro que liberara ciertos nombres de dominio de dos caracteres que estaban reservados bajo las condiciones del Acuerdo de Registro de Nuevos gTLD. La implementación de las propuestas requeriría una enmienda al Anexo A de los acuerdos de registro correspondientes. Las enmiendas propuestas para implementar el nuevo servicio de registro fueron sometidas al comentario público durante los últimos meses. En total, la ICANN publicó 28 propuestas y enmiendas de la RSEP, que afectan un total de 203 nuevos gTLD. Cada semana la ICANN continúa recibiendo solicitudes de RSEP adicionales para este servicio de registro.

      Conforme lo estipulado en la Sección 2.4.D de la RSEP y las Notas de Implementación de la RSEP, si la implementación de un servicio propuesto requiere que se haga un cambio sustancial en el acuerdo de registro, la determinación preliminar se derivará a la Junta Directiva de la ICANN para su consideración.

      ¿Cuál es la propuesta que está siendo considerada?

      La Junta Directiva está tomando medidas para indicar al presidente y director ejecutivo que se desarrolle e implemente un proceso eficaz que permita la liberación de los nombres de dominio de dos caracteres en los nuevos gTLD, teniendo en cuenta las sugerencias del GAC en su comunicado pronunciado en Los Ángeles.

      ¿Cuáles son las partes interesadas u otros participantes consultados?

      Al 24 de septiembre de 2014, el personal de la ICANN ha iniciado cinco (5) foros de comentarios públicos para obtener la opinión de la comunidad acerca de las enmiendas para implementar el nuevo servicio de registro propuesto: 12 de junio de 2014 <https://www.icann.org/public-comments/two-char-new-gtld-2014-06-12-en>, 8 de julio de 2014 <https://www.icann.org/public-comments/two-char-new-gtld-2014-07-08-en>, 23 de julio de 2014 <https://www.icann.org/public-comments/two-char-new-gtld-2014-07-23-en>, 19 de agosto de 2014 <https://www.icann.org/public-comments/two-char-new-gtld-2014-08-19-en> y 12 de septiembre de 2014 <https://www.icann.org/public-comments/two-char-new-gtld-2014-09-12-en>. Varios miembros de la comunidad enviaron sus comentarios, incluidos el Comité Asesor At-Large (ALAC) y los operadores de registro.

      Asimismo, la ICANN notificó al GAC al momento de publicación de las solicitudes de los operadores de registro para recibir comentarios.

      ¿Qué inquietudes o cuestiones fueron planteadas por la comunidad?

      Durante el período de comentario público se recibieron varios comentarios en los que se indicaba una serie de argumentos a favor o en contra de la liberación general de ciertos nombres de dos caracteres en el espacio de nombres de los nuevos gTLD. La mayoría de los comentarios recibidos fueron a favor de la liberación de los nombres de dominio de dos caracteres.

      Los argumentos en contra de la liberación de los nombres de dominio de dos caracteres expresaban dos inquietudes generales. La primera inquietud se relaciona con el reconocimiento general y el uso asociado de los nombres de dominio de dos caracteres, lo que podría generar confusión en los usuarios e incluso abuso. La segunda inquietud se relaciona en el método que se utilizaría para proteger específicamente los ccTLD cuando se formen nombres de nuevos países y territorios.

      Los comentarios públicos recibidos hasta ahora están marcadamente a favor de la introducción de nombres de dominio de dos caracteres en el espacio de nombres del nuevo gTLD. Los argumentos a favor de la liberación de los nombres de dominio de dos caracteres fueron los siguientes:

      • La introducción de los nombres de dominio de dos caracteres aumentaría la competencia, dado que las restricciones actuales la limitan, en particular en el caso de los nuevos gTLD que compiten con los TLD heredados (delegados antes de la ronda de aplicación de nuevos gTLD de 2012) que ofrecían este tipo de registro. Las restricciones actuales aplicables a los operadores de registro de nuevos gTLD crean una situación de discriminación que es contraria al Artículo II, sección 3 de los estatutos de la ICANN, en donde se indica el tratamiento no discriminatorio que la ICANN debe tener hacia las partes interesadas.
      • El riesgo de confusión asociado con la introducción de nombres de dominio de dos caracteres es limitado o nulo, como queda demostrado por el uso previo de nombres de dominio de dos caracteres en TLD existentes.
      • La liberación de ciertos tipos de nombres de dominio de dos caracteres para incluir por lo menos un dígito o un número no generaría inquietudes y se podría considerar.
      • La liberación de nombres de dominio de dos caracteres permitiría a las empresas y las marcas tener nombres de dominio segmentados de manera específica para conectarse con el público, además de proporcionar contenido localizado y expandir así las opciones de los consumidores y fomentar el crecimiento económico, en particular, en países en desarrollo.
      • El servicio de registro propuesto no entra en conflicto con lo estipulado en el documento de requisitos Mecanismos de Protección de Derechos (RPM).
      • Hay antecedentes uniformes en relación con la liberación de nombres de dominio de dos caracteres en el historial de solicitudes relevantes de RSEP.
      • La liberación de códigos y nombres de países está permitida en la Guía para el Solicitante.

      El GAC también planteó algunas inquietudes en relación con la liberación de ciertos nombres de dominio de dos caracteres (combinaciones de dos letras). En su comunicado del 27 de marzo de 2014 pronunciado en Singapur, el GAC analizó la propuesta del Grupo de Registros de Marcas para la implementación de un proceso optimizado agregado como adenda al Acuerdo de Registro para la aprobación de nombres de país y códigos de dos letras y caracteres en el segundo nivel. El GAC expresó que "el GAC no tiene inquietudes importantes con respecto a los titulares de las marcas que desean obtener la aprobación para dichos nombres, sino con respecto a que la aprobación debería realizarse directamente en los países pertinentes en lugar de hacerse por medio del proceso operativo en el nivel del GAC". El GAC informó que los miembros individuales del GAC podrían ayudar con las propuestas relevantes para sus países específicos si se lo solicitara. El GAC sugirió que se debería considerar el establecimiento de un registro de países que no requieren que se hagan solicitudes individuales.

      Posteriormente, en su comunicado pronunciado en Los Ángeles, el GAC observó que "no se encuentra en la posición de ofrecer consejo consensuado acerca del uso de nombres de dominio de segundo nivel de dos caracteres en las nuevas operaciones de gTLD, incluidas las combinaciones de letras que también se encuentran en la lista de la norma ISO 3166-1 alfa 2". El GAC también observó que "al considerar estas solicitudes de la RSEP, y de manera congruente con lo indicado en la Guía para el Solicitante, el GAC considera que el período de comentario público es un mecanismo de transparencia importante y solicita que además la ICANN alerte a los gobiernos pertinentes acerca de estas solicitudes a medida que vayan surgiendo". La acción de la Junta Directiva de hoy tiene en cuenta la información proporcionada por el GAC acerca de la liberación de los dominios de dos caracteres.

      ¿Qué materiales significativos analizó la Junta Directiva? ¿Qué factores consideró importantes la Junta Directiva?

      La Junta Directiva analizó varios materiales y consideró además varios factores importantes durante su deliberación para autorizar o no la solicitud. Los materiales y los factores importantes que la Junta Directiva consideró como parte de sus deliberaciones incluyeron los siguientes, entre otros:

      ¿Existen impactos positivos o negativos para la comunidad? ¿Hay algún impacto o ramificación fiscal para la ICANN (plan estratégico, plan operativo, presupuesto), la comunidad y/o el público? ¿Se observan cuestiones sobre seguridad, estabilidad o flexibilidad relacionadas con el DNS?

      Se prevé que el impacto general sobre la comunidad sea positivo, ya que se crearán nuevas oportunidades de diversificación y competencia en el espacio de nombres de gTLD sin que se haya identificado ningún riesgo específico de confusión por parte de los usuarios.

      La eventual implementación de este servicio de registro puede tener impacto fiscal para la ICANN, la comunidad o el público, ya que puede haber costos adicionales asociados con las implicancias más amplias del servicio de registro.

      Según lo determinado por el Panel de Evaluación Técnica de los Servicios de Registro (RSTEP) de la ICANN en un informe emitido el 4 de diciembre de 2006 sobre la liberación propuesta de dominios de dos caracteres en gTLD .nombre, dicho servicio no crea ningún riesgo razonable de efecto adverso para la seguridad y la estabilidad.

      ¿Hay un proceso de políticas definido dentro de la Organización de Apoyo de la ICANN o la decisión de función organizativa y administrativa de la ICANN que requiera comentario público, o que no lo requiera?

      consensuada de la ICANN que entró en vigencia el 15 de agosto de 2006. En congruencia con la política, la ICANN publicó las enmiendas al Acuerdo de Registro para recibir los comentarios del público, ya que la implementación del servicio propuesto requería lo que entonces se consideró un cambio sustancial del Acuerdo de Registro. Después de la resolución del día de la fecha, se considerará que las propuestas futuras dentro del marco de la RSEP en las que se solicite la liberación de nombres de dominio de dos caracteres compuestos por combinaciones de una letra y un número o dos números no representan un cambio sustancial del Acuerdo de Registro.

    3. Plan Estratégico de la ICANN para los años fiscales 2016 a 2020

      Visto y considerando que el Plan Estratégico de la ICANN para los años fiscales 2016 a 2020 es el resultado de un extenso proceso cooperativo, exhaustivo, con múltiples partes interesadas y plurilingüe que comenzó en abril de 2013 tanto en línea como en la reunión que la ICANN celebró en Pekín (y se lo detalla en línea).

      Visto y considerando que el Plan Estratégico proporciona una nueva visión de la ICANN, reitera la misión existente de la ICANN y describe cinco objetivos estratégicos, cada uno con metas estratégicas, factores clave para el éxito y riesgos estratégicos.

      Visto y considerando que para complementar el Plan Estratégico se cuenta con un Plan Operativo Quinquenal que proporciona, para cada objetivo y meta estratégicos, carteras de actividades de la ICANN, factores operativos clave para el éxito, riesgos operativos, indicadores clave de rendimiento, dependencias clave y división en fases para el período de cinco años (en el nivel de las metas) y que estos planes combinados se utilizarán como base para los planes y los presupuestos operativos anuales.

      Resuélvase (2014.10.16.15): que se adopte el Plan Estratégico de la ICANN para los años fiscales 2016 a 2020 y que se indique al presidente y director ejecutivo de la ICANN que tome las medidas necesarias para publicar y ejecutar el Plan.

      Justificación de la Resolución 2014.10.16.15

      El Plan Estratégico proporciona la visión de la ICANN, reitera la misión existente de la ICANN y establece cinco objetivos estratégicos, cada uno con metas estratégicas, factores clave para el éxito (resultados) y riesgos estratégicos. Guiará las actividades de la ICANN en los años fiscales comprendidos entre 2016 y 2020, e informará los presupuestos y los planes operativos de la ICANN.

      Para proporcionar al público información más detallada y promover la responsabilidad y la transparencia de la ICANN, se ampliaron las mediciones (indicadores clave de rendimiento) y la división de alto nivel en fases de cinco años en un Plan Operativo Quinquenal que actúa como complemento del Plan Estratégico. Como nuevo elemento del proceso de planificación de la ICANN, el Plan Operativo Quinquenal detalla, para cada objetivo y meta estratégicos, listas de actividades de la ICANN, factores operativos clave para el éxito (resultados), riesgos, indicadores clave de rendimiento (mediciones), dependencias clave y división en fases para el período de cinco años (en el nivel de las metas).

      Desde el año fiscal 2016, se utilizarán el Plan Estratégico y el Plan Operativo Quinquenal en combinación para proporcionar información acerca de los presupuestos y los planes operativos anuales. Los presupuestos y los planes operativos anuales considerarán los requisitos de recursos para las estrategias, así como el impacto sobre la seguridad, la estabilidad y la flexibilidad del DNS y las acciones que sean necesarias para mitigar los riesgos.

      El avance de los trabajos, los logros hacia las metas y la efectividad de las estrategias se administrarán e informarán a través de los sistemas de gestión de la ICANN e incluirán un conjunto de factores clave para el éxito e indicadores clave de rendimiento. Se los utilizará para proporcionar información para un control anual de planificación destinado a validar que la organización esté encaminada o determinar si se necesita hacer algún ajuste.

      El Plan Estratégico Quinquenal de la ICANN es el resultado de un extenso proceso cooperativo, exhaustivo, con múltiples partes interesadas y plurilingüe que comenzó en abril de 2013 tanto en línea como en la reunión que la ICANN celebró en Pekín. La ICANN solicitó mucha información del público acerca de los desafíos y oportunidades clave y las áreas estratégicas destacadas por la Junta Directiva de la ICANN. Todos los elementos del Plan Estratégico fueron preparados con información obtenida de comentarios del público y debates de la comunidad (según se detalla aquí) en relación con las organizaciones de apoyo, los grupos de partes interesadas, las unidades constitutivas y los comités asesores de la ICANN. Aquí [PDF, 808 KB] y aquí [PDF, 414 KB] se pueden consultar las respuestas a todos los comentarios del público recibidos con respecto a los planes estratégicos preliminares. El Plan Estratégico también refleja el trabajo y los aportes recibidos con respecto a iniciativas relacionadas, por ejemplo, los temas estratégicos del Marco de Seguridad, Estabilidad y Flexibilidad, las Estrategias para la Participación Regional y el Panel de Estrategia.

    4. Consideración de la Junta Directiva de las Recomendaciones del Grupo de Trabajo de Intercambio de la Comunidad sobre la Mejora de la Responsabilidad de la ICANN

      Visto y considerando que la Junta Directiva reconoce que la comunidad está actuando con celeridad para convocar un Grupo de Trabajo de Intercambio de la Comunidad sobre la Mejora de la Responsabilidad de la ICANN.

      Visto y considerando que la opinión de la comunidad para la evolución del Proceso de Mejora de la Responsabilidad de la ICANN ha sido invaluable y que la Junta Directiva espera con ansias recibir las recomendaciones que tengan un amplio apoyo y consenso de la comunidad.

      Visto y considerando que la Junta Directiva comprende que sigue habiendo preguntas en relación con la manera en la que la Junta Directiva considerará las recomendaciones consensuadas desarrolladas mediante el Grupo de Trabajo de Intercambio de la Comunidad sobre la Mejora de la Responsabilidad de la ICANN.

      Resuélvase (2014.10.16.17): la Junta Directiva se compromete a respetar los siguientes principios al considerar las recomendaciones del Grupo de Trabajo de Intercambio de la Comunidad sobre la Mejora de la Responsabilidad y la Gobernanza de la ICANN:

      1. Estos principios se aplican a las recomendaciones basadas en el consenso recibidas del Grupo de Trabajo de Intercambio de la Comunidad sobre la Mejora de la Responsabilidad y la Gobernanza de la ICANN.
      2. Si la Junta Directiva cree que la implementación de una recomendación del Grupo de Trabajo de Intercambio de la Comunidad sobre la Mejora de la Responsabilidad y la Gobernanza de la ICANN (recomendación del CCWG) no es lo mejor para el interés público general, debe iniciar el diálogo con el CCWG. Para determinar que la implementación de una recomendación del CCWG no es lo mejor para el interés público general se necesita el voto por mayoría de 2/3 de la Junta Directiva.
      3. La Junta Directiva debe proporcionar fundamentos detallados junto con el inicio del diálogo. La Junta Directiva acordará con el CCWG el método que se utilizará para llevar a cabo el diálogo (por ejemplo, conferencia telefónica, correo electrónico u otro método). Las conversaciones se llevarán a cabo de buena fe, y de manera oportuna y eficiente, para encontrar una solución que sea aceptable para ambas partes.
      4. El CCWG tendrá la oportunidad de responder todas las inquietudes de la Junta Directiva y ponerse en contacto con la Junta Directiva en una fecha posterior para informar el desarrollo de las deliberaciones relacionadas con las inquietudes de la Junta Directiva. El CCWG analizará las inquietudes de la Junta Directiva dentro de un período de 30 días desde el inicio del diálogo con la Junta Directiva.
      5. Si el CCWG modificara una recomendación, se la debe devolver a la Junta Directiva para la subsiguiente consideración. El CCWG debe proporcionar fundamentos detallados acerca de la manera en la que la modificación soluciona las inquietudes planteadas por la Junta Directiva.
      6. Si, después de una modificación, la Junta Directiva todavía cree que la implementación de la recomendación del CCWG no es lo mejor para el interés público general, la Junta Directiva puede enviarla nuevamente al CCWG para que se la vuelva a considerar, para lo que se necesita también el voto por mayoría de 2/3 de la Junta Directiva. También se debe proporcionar un detalle de los fundamentos que justifican esta nueva acción de la Junta Directiva. Si la Junta Directiva determinara la no aceptación de una modificación, entonces la Junta Directiva no podrá establecer una solución para la cuestión relacionada con la recomendación hasta que el CCWG y la Junta Directiva lleguen a un acuerdo.

      Justificación de la Resolución 2014.10.16.16

      En respuesta al pedido de la comunidad de que se revisara la responsabilidad de la ICANN a la luz del cambio en la relación histórica con el gobierno de los Estados Unidos, la ICANN accedió a llevar a cabo un proceso para la mejora de la responsabilidad de la ICANN. Ahora que se ha llegado a un acuerdo para la realización del proceso mediante un Grupo de Trabajo de Intercambio de la Comunidad, la comunidad solicitó que se defina la manera en la que la Junta Directiva trataría las recomendaciones enviadas por el Grupo de Trabajo de Intercambio de la Comunidad, con interés particular en la capacidad que podría llegar a tener la Junta Directiva para modificar o descartar recomendaciones con las que no estuviera de acuerdo. Dada la adopción por parte de la comunidad de un modelo de Grupo de Trabajo de Intercambio de la Comunidad, que incluye un coordinador de enlace con la Junta Directiva, la Junta Directiva espera con ansias la continuación del diálogo mediante el proceso con todos los participantes para desarrollar las recomendaciones y el consenso amplio subyacentes para cada una de estas recomendaciones.

      La Junta Directiva escuchó las inquietudes de la comunidad y establece estos principios para guiar la manera en la que la Junta Directiva considerará las recomendaciones consensuadas enviadas por el Grupo de Trabajo de Intercambio de la Comunidad sobre la Mejora de la Responsabilidad de la ICANN. Estos están modelados sobre la base de los requisitos aplicables a los procesos de desarrollo de políticas de la GNSO y la ccNSO para reconocer las colaboraciones exhaustivas al trabajo sobre la responsabilidad.

      La adopción de estos principios no tiene ninguna implicancia financiera ni relacionada con recursos para la ICANN que se pueda identificar en este momento. No se espera que haya un impacto sobre la seguridad, la estabilidad ni la flexibilidad del DNS como resultado de esta decisión.

      Se trata de una función organizativa y administrativa que responde a comentarios públicos ya recibidos.

    5. Agradecimiento a Olga Madruga-Forti por los servicios brindados a la Junta Directiva de la ICANN

      Visto y considerando que el 18 de octubre de 2012 Olga Madruga-Forti fue designada por el Comité de Nominaciones para desempeñarse como miembro de la Junta Directiva de la ICANN.

      Visto y considerando que Olga finaliza su mandato en la Junta Directiva de la ICANN el 16 de octubre de 2014.

      Visto y considerando que Olga se ha desempeñado como miembro de los siguientes comités:

      • Comité de Auditoría
      • Comité de Relaciones Globales
      • Comité de Gobernanza de la Junta Directiva
      • Comité del Programa de Nuevos gTLD

      Resuélvase (2014.10.16.17): Olga Madruga-Forti se ha ganado el profundo agradecimiento de la Junta Directiva por los servicios prestados y la Junta Directiva le desea lo mejor en todos sus emprendimientos futuros dentro y fuera de la comunidad de la ICANN.

    6. Agradecimiento a Sébastien Bachollet por los servicios prestados a la Junta Directiva de la ICANN

      Visto y considerando que el 9 de diciembre de 2010 Sébastien Bachollet fue designado por la Comunidad At-Large para desempeñarse como miembro de la Junta Directiva de la ICANN.

      Visto y considerando que Sébastien concluye su término de mandato en la Junta Directiva de la ICANN el 16 de octubre de 2014.

      Visto y considerando que Sébastien se ha desempeñado como miembro de los siguientes comités y grupos de trabajo:

      • Comité de Finanzas
      • Comité de Mejoras Estructurales
      • Comité de Participación Pública y Partes Interesadas
      • Grupo de Trabajo para la Estrategia de Reuniones

      Resuélvase (2014.10.16.18): Sébastien Bachollet se ha ganado el profundo agradecimiento de la Junta Directiva por los servicios prestados y la Junta Directiva le desea lo mejor en todos sus emprendimientos futuros dentro y fuera de la comunidad de la ICANN.

    7. Agradecimiento a Bill Graham por los servicios prestados a la Junta Directiva de la ICANN

      Visto y Considerando que el 23 de junio de 2011 Bill Graham fue designado por la Organización de Apoyo para Nombres Genéricos para desempeñarse como miembro de la Junta Directiva de la ICANN.

      Visto y considerando que Bill concluye su término de mandato en la Junta Directiva de la ICANN el 16 de octubre de 2014.

      Visto y considerando que Bill se ha desempeñado como miembro de los siguientes comités y grupos de trabajo:

      • Comité de Auditoría
      • Comité de Relaciones Globales
      • Comité de Gobernanza de la Junta Directiva
      • Comité de la IANA
      • Comité del Programa de Nuevos gTLD
      • Comité de Riesgo
      • Comité de Mejoras Estructurales
      • Grupo de Trabajo de la Junta Directiva y el GAC para la Implementación de Recomendaciones

      Resuélvase (2014.10.16.19): Bill Graham se ha ganado el profundo agradecimiento de la Junta Directiva por los servicios prestados y la Junta Directiva le desea lo mejor en todos sus emprendimientos futuros dentro y fuera de la comunidad de la ICANN.

    8. Agradecimiento a Heather Dryden por los servicios prestados a la Junta Directiva de la ICANN

      Visto y considerando que el 25 de junio de 2010 Heather Dryden fue designada para desempeñarse como coordinadora de enlace del GAC con la Junta Directiva de la ICANN.

      Visto y considerando que Heather finaliza su mandato en la Junta Directiva de la ICANN el 16 de octubre de 2014.

      Visto y considerando que Heather se ha desempeñado como coordinadora de enlace de los siguientes comités:

      • Comité del Programa de Nuevos gTLD

      Resuélvase (2014.10.16.20): Heather Dryden se ha ganado el profundo agradecimiento de la Junta Directiva por los servicios prestados y la Junta Directiva le desea lo mejor en todos sus emprendimientos futuros dentro y fuera de la comunidad de la ICANN.

resolutions-16oct14-es.pdf  [442 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."