Skip to main content
Resources

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

Esta página está disponible en:

Este documento ha sido traducido a varios idiomas como información únicamente. El texto original y válido (en inglés) se puede obtener en: https://www.icann.org/resources/board-material/resolutions-2014-09-09-en

 

  1. Orden del día principal
    1. Designación del Presidente y Presidente Electo del Comité de Nominaciones para el año 2015
  2. Orden del Día Convenido:
    1. Aprobación de las Actas de las Reuniones de la Junta Directiva
    2. Nombramiento de Benedict Addis como integrante del Comité Asesor de Seguridad y Estabilidad (SSAC)
    3. Agradecimiento del Comité Asesor de Seguridad y Estabilidad (SSAC) a David Conrad
  3. Orden del día principal:
    1. Informe del Panel de Evaluación Técnica Sobre Servicios de Registros (RSTEP) en relación a la Solicitud del Registro de Interés Público para Implementar una Vinculación Técnica en .NGO y .ONG
    2. Planificación para Futuras Rondas de Solicitudes de gTLD
    3. Presupuesto y Plan Operativo del Año Fiscal 2015 (FY15)
    4. Borrador Final del Plan Estratégico de Cinco Años de la ICANN para los Años Fiscales 2016 – 2020 (FY16-FY20)
    5. Reconocimiento de la Declaración de la Segunda Cumbre de At-Large
    6. Otros temas a tratar

 

  1. Orden del día principal

    1. Designación del Presidente y Presidente Electo del Comité de Nominaciones para el año 2015

      Visto y considerando que, el BCG analizó las Expresiones de Interés de los candidatos para Presidente y Presidente Electo del Comité de Nominaciones 2014 ("NomCom"), consideró los resultados de la evaluación de 360 grados del liderazgo del NomCom 2014 y evaluó la respuesta a las preguntas planteadas por el BGC para cada candidato.

      Visto y considerando que, el BGC ha recomendado a Stephane Van Gelder para que sea designado como Presidente del NomCom para el año 2015.

      Resuélvase (2014.0909.01), la Junta Directiva, por la presente, designa a Stephane Van Gelder como Presidente del Comité de Nominaciones para el año 2015.

      Fundamento de la Resolución 2014.09.09.01

      De acuerdo con los Estatutos de la ICANN, la Junta Directiva debe designar al Presidente y al Presidente Electo del Comité de Nominaciones (NomCom). Consultar el Artículo VII, secciones 2.1 y 2.2 en http://www.icann.org/en/general/bylaws.htm#VII. La Junta Directiva ha delegado en el BGC la responsabilidad de recomendar al presidente y al presidente electo del Comité de Nominaciones para la aprobación de la Junta Directiva. Véase el estatuto del BGC http://www.icann.org/en/committees/board-governance/charter.htm. El BCG publicó en dos oportunidades una convocatoria para expresiones de interés (EOI) (véase (https://www.icann.org/news/announcement-2-2014-07-01-en), recibió y analizó las EOI enviadas, supervisó una evaluación de 360 grados del liderazgo del NomCom 2014 y planifica llevar a cabo entrevistas con algunos de los candidatos antes de realizar su recomendación en relación al Presidente Electo del NomCom para el año 2015. La Junta Directiva ha considerado la recomendación del BGC y concuerda con ella en relación al Presidente del NomCom para el año 2015 y espera la próxima recomendación del BGC para el Presidente Electo del NomCom del año 2015. Asimismo, la Junta Directiva desea agradecer a todos los que manifestaron su interés en formar parte del liderazgo de NomCom.

      La designación del Presidente y el Presidente- Electo del NomCom identificados a través de un proceso público de EOI tiene un impacto positivo en la transparencia y la responsabilidad de la ICANN y avala el interés público. La adopción de la recomendación del BGC no tiene un impacto económico en la ICANN que no haya sido anticipado y no impactará de manera negativa en la seguridad, estabilidad y flexibilidad del sistema de nombres de dominio.

  2. Orden del Día Convenido:

    1. Aprobación de las Actas de las Reuniones de la Junta Directiva

      Resuélvase (2014.09.09.02): La Junta Directiva aprueba el acta de la reunión de la Junta Directiva de la ICANN celebrada el 30 de julio de 2014.

    2. Nombramiento de Benedict Addis como integrante del Comité Asesor de Seguridad y Estabilidad (SSAC)

      Visto y considerando que, el Comité Asesor de Seguridad y Estabilidad (SSAC) realiza, en forma periódica, una revisión y cambios en su membresía.

      Visto y considerando que, el Comité de Membresía del SSAC, en representación del SSAC, solicita que la Junta Directiva designe a Benedict Addis para integrar dicho comité.

      Resuélvase (2014.09.09.03): La Junta Directiva designa a Benedict Addis como integrante del SSAC.

      Fundamento de la Resolución 2014.09.09.03

      El SSAC es un grupo diverso de personas cuyos conocimientos sobre temas específicos permiten que el comité cumpla con su carta orgánica y ejecute su misión. Desde su creación, el SSAC ha invitado a personas con amplios conocimientos y gran experiencia en áreas técnicas y de seguridad que son fundamentales para la seguridad y la estabilidad del sistema de nombres de dominio de Internet.

      Las operaciones continuas del SSAC como organismo competente dependen del aporte y el talento de expertos que han aceptado contribuir voluntariamente con su tiempo y energía para llevar a cabo la misión del comité. Benedict Addis es un funcionario con conocimientos técnicos que se desempeña en el departamento encargado de Delitos Cibernéticos y Ciencia Forense de la Agencia contra el Crimen Organizado (SOCA), un organismo de cumplimiento de la ley del Reino Unido. Posee amplia experiencia en informática y seguridad de redes, lo que constituye una parte integral de su responsabilidad en materia de cumplimiento de la ley. Ha trabajado de forma activa en relación al uso indebido de Internet y actividades delictivas durante varios años. El Sr. Addis aporta una perspectiva valiosa para el SSAC en cuanto a la interpretación de la política gubernamental y el cumplimiento de la ley.

    3. Agradecimiento del Comité Asesor de Seguridad y Estabilidad (SSAC) a David Conrad

      Visto y considerando que, la Junta Directiva designó a David Conrad para el SSAC en 18 de marzo de 2011.

      Visto y considerando que el Sr. Conrad renunció al SSAC el día 1 de agosto de 2014.

      Visto y considerando que la ICANN desea expresar su reconocimiento y agradecimiento al Sr. Conrad por su servicio a la comunidad mediante su participación en el SSAC.

      Resuélvase (2014.09.09.04): David Conrad se ha ganado el profundo agradecimiento de la Junta Directiva por su servicio a la ICANN mediante su participación en el SSAC, y la Junta Directiva le desea lo mejor en todos sus emprendimientos futuros dentro de la comunidad de la ICANN y fuera de la misma.

      Fundamento de la Resolución 2014.09.09.04

      Es práctica habitual del SSAC promover el reconocimiento de la Junta Directiva al servicio de los miembros del Comité en el momento de su retiro.

  3. Orden del día principal:

    1. Informe del Panel de Evaluación Técnica Sobre Servicios de Registros (RSTEP) en relación a la Solicitud del Registro de Interés Público para Implementar una Vinculación Técnica en .NGO y .ONG

      Visto y considerando que, el 12 de marzo de 2014, en el Registro de Interés Público (PIR) presentó una solicitud [PDF, 24 KB] de Política de Evaluación de Servicios de Registro (RSEP) para ofrecer vinculación técnica obligatoria de los nombres de segundo nivel para .NGO y .ONG , según lo establecido en el Anexo A de cada Acuerdo de Registro respectivo.

      Visto y considerando que, el 21 de mayo de 2014, el personal de la ICANN publicó la solicitud de RSEP para información pública y llevó a cabo la revisión de la solicitud según el RSEP.

      Visto y considerando que, el 4 de junio de 2014, la decisión preliminar del personal de la ICANN no identificó ninguna cuestión de competencia significativa. De forma separada, el personal de la ICANN determinó que el servicio de registro propuesto podría presentar cuestiones significativas de estabilidad o seguridad e informó [PDF, 320 KB] al PIR respecto de la necesidad de derivar la propuesta al Panel de Evaluación Técnica para Servicios de Registro (RSTEP) para una posterior evaluación.

      Visto y considerando que, el 6 de junio de 2014, la ICANN derivó la solicitud de RSEP del PIR [PDF, 952 KB] al RSTEP para su posterior evaluación.

      Visto y considerando que, el 10 de junio de 2014 la ICANN publicó la solicitud de RSEP del PRI para comentario público. El periodo de comentarios públicos finalizó el 30 de julio de 2014 y no se recibieron comentarios.

      Visto y considerando que, el 29 de julio de 2014 el informe del RSTEP se publicó para comentarios públicos. El periodo de comentarios públicos finalizó el 13 de agosto de 2014 y no se recibieron comentarios.

      Visto y considerando que, el informe del RSTEP concluyó que, desde una perspectiva de evaluación técnica, la propuesta no crea "un riesgo razonable de que exista un efecto adverso significativo sobre la estabilidad o la seguridad" como se define en la Política RSEP relacionada con la introducción del servicio de registro para admitir la vinculación técnica obligatoria de los nombres de dominio de segundo nivel para .NGO y .ONG. El informe del RSTEP y el personal también identificaron varias posibles cuestiones técnicas y de implementación asociadas con la introducción del nuevo servicio de registro propuesto al DNS, que incluye: consecuencias de la desvinculación de .NGO y .ONG; posible confusión del registratario y / o el usuario final; cuestiones de equivalencia que se discuten en el contexto de las variantes de IDN; y otros problemas operacionales.

      Resuélvase (2014.09.09.05), La Junta Directiva adopta los hallazgos en el informe del RSTEP en cuanto a que la propuesta no crea "un riesgo razonable de que exista un efecto adverso significativo sobre la estabilidad o la seguridad" y aprueba la solicitud del PIR en relación a la introducción del servicio de registro para admitir la vinculación técnica obligatoria de los nombres de dominio de segundo nivel para .NGO y .ONG.

      Resuélvase (2014.09.09.06), la Junta Directiva autoriza al Presidente y Director Ejecutivo, o a quien este designe, para desarrollar una enmienda con el fin implementar el nuevo servicio de registro que tenga en cuenta y aborde de forma adecuada las cuestiones técnicas y de implementación pendientes relacionadas.

      Fundamentos de las resoluciones 2014.09.09.05 – 2014.09.09.06

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

      El 12 de marzo de 2014, el Registro de Interés Público (PIR), operador del registro de los TLD .NGO y .ONG, presentó una solicitud para brindar un nuevo servicio de registro con el fin de proporcionar el soporte correspondiente a la vinculación técnica obligatoria para los dominios de segundo nivel de .NGO y .ONG. La propuesta da una explicación de la vinculación técnica propuesta, la implementación de los comandos EPP, el manejo del DNSSEC, el manejo de las variantes de IDN en el segundo nivel y el servicio del WHOIS. La propuesta, que fue presentada a través de la Política de Evaluación de Servicios de Registro, fue derivada al Panel de Evaluación Técnica de Servicios de Registro (RSTEP) y tanto la propuesta de RSEP como el informe del RSTEP fueron respectivamente presentados para comentarios públicos, tal como lo requiere el RSEP.

      Según lo dispuesto en la Sección 2.7 de la Política de Evaluación de Servicios de Registro (RSEP), la Junta Directiva tenía 30 días calendario, luego de la recepción del informe del Panel de Evaluación Técnica de Servicios de Registros el 24 de julio de 2014, para tomar una decisión. La Junta Directiva podía decidir 1 ) aprobar la solicitud, 2) declinar la solicitud, o 3) demorar la solicitud para obtener más información.

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

      La acción de la Junta Directiva, en la actualidad, es tomar medidas en relación al informe del RSTEP, el cual evalúa cuestiones de seguridad y estabilidad que pueden estar asociadas con la solicitud de RSEP presentada por el PIR para implementar un nuevo servicio de registro que permita la "vinculación técnica" de los nombres de dominio de segundo nivel. La solicitud del PIR establece que: "[a] la Vinculación Técnica es un conjunto de dos nombres de dominio en diferentes TLD con etiquetas idénticas en el segundo nivel que comparten los siguientes parámetros:

      • Propiedad del Registrador
      • Registraciones y Fechas de Vencimiento
      • Registratario, Admin, Facturación y Contactos Técnicos
      • Asociación de Servidor de Nombres
      • Estatus del dominio
      • Periodos de Gracia Aplicables (Periodo de Gracia Adicional, Período de Gracia de Renovación, Período de Gracia de Auto Renovación, Periodo de Gracia de Transferencia o Periodo de Gracia de Redención).
      • Y para los cuales, al menos, los siguientes parámetros son únicos: "Registros DS, tal como se requiere según la RFC 5910".

      ¿A qué partes interesadas u otras partes se consultó?

      El personal de la ICANN inició un foro de comentarios públicos desde el 10 de junio de 2014 hasta el 8 de julio de 2014, en el que invitaba a la comunidad a brindar aportes respecto de la propuesta del PIR sobre RSEP. Durante el período de comentarios públicos, no se recibieron comentarios. El informe final con los comentarios públicos pueden consultarse en: https://www.icann.org/public-comments/tech-bundling-2014-06-10-en.

      Además, se consultó al equipo de revisión del RSTEP para llevar a cabo una evaluación técnica sobre el servicio de registro propuesto con respecto a la probabilidad y materialidad de los efectos en cuanto a la seguridad y estabilidad, que incluye si el servicio de registro propuesto crearía un riesgo razonable de un efecto adverso significativo sobre la seguridad o estabilidad. El 24 de julio de 2014, se presentó el Informe del RSTEP  [PDF, 1.02 MB] a la comunidad de la ICANN. La ICANN inició un foro de comentarios públicos desde el 29 de julio de 2014 hasta el 5 de agosto de 2014, en el que invitaba a la comunidad a brindar aportes respecto del informe del RSTEP. Durante el período de comentarios públicos, no se recibieron comentarios. El informe final con los comentarios públicos pueden consultarse en: https://www.icann.org/public-comments/rstep-technical-bundling-2014-07-29-en.

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

      No se recibieron comentarios durante el periodo de comentarios públicos para la propuesta del RSEP y el periodo de comentarios públicos para el informe RSTEP. Sin embargo, las siguientes cuestiones técnicas y de implementación fueron identificadas en el informe del RSTEP y por el personal de la ICANN, las cuales deberán ser abordadas por el PIR [y/o la comunidad] como parte del desarrollo de una enmienda a los acuerdos del registro de .NGO y .ONG a fin de implementar el nuevo servicio de registro:

      • Análisis de las consecuencias de "desvincular", es decir, en algún momento futuro, el PIR (o un registro sucesor) toma la decisión de eliminar la asociación explícita entre .NGO y .ONG.
      • En la propuesta del PIR está implícita una aseveración de que los contenidos de los dominios .NGO y .ONG son "lo mismo" (por lo tanto, están vinculados), sin embargo no existe un mecanismo mediante el cual esta similitud se pueda implementar en todos los niveles dentro del DNS, ni tampoco las solicitudes, como por ejemplo de servidores web, servidores de correo electrónico etcétera, comprenderán que los dominios .NGO y .ONG deben tratarse de forma idéntica sin una configuración explícita. Esto puede llevar a una confusión tanto del cliente como del usuario final (por ejemplo, "¿por qué EXAMPLE.SOMETHING.ONG se resuelve y EXAMPLE.SOMETHING.NGO no lo hace?") y, por parte, de los registratarios ("¿por qué tengo que configurar mi servidor web para comprender cada dominio de tercer nivel para mis dos dominios de segundo nivel en .NGO y .ONG?"). Se requiere información para abordar la posible confusión dentro de la propuesta del PIR.
      • La cuestión de la similitud de etiquetas, específicamente dos etiquetas que se interpretan como "iguales" aunque las cadenas de caracteres que la componen sean diferentes, que está implícita en la propuesta del PIR para la cual la vinculación es una posible resolución, puede probablemente verse como funcionalmente equivalente a un componente de la cuestión de las "variantes de IDN". La comunidad ha estado trabajando en soluciones para las distintas cuestiones durante varios años, pero aún no se ha alcanzado una resolución total. Es posible que la comunidad que trabaja en diferentes cuestiones vea la aceptación de la vinculación técnica de .NGO y .ONG como una "evasión" inapropiada de las políticas y procesos que se establecen para el manejo de las variantes; y
      • La vinculación técnica se considera una posible solución para abordar las variantes de IDN, no obstante, la comunidad no ha desarrollado un marco para su uso, ni ha aprobado este enfoque para la implementación. La aceptación de la propuesta del PIR y el avance sin más aportes de la comunidad respecto de la vinculación técnica, puede dar lugar a inquietudes por parte de los solicitantes de variantes de IDN y otros miembros interesados de la comunidad que quisieran debatir esta cuestión para la implementación de los TLD con variantes IDN.

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

      La Junta Directiva analizó varios materiales para llevar a cabo su acción. La Junta Directiva también consideró varios factores significativos durante sus deliberaciones en torno a la aprobación o no de la solicitud. Los materiales y factores importantes que la Junta Directiva tomó en cuenta como parte de sus deliberaciones incluyeron, aunque no taxativamente, los siguientes:

      ¿Se observan impactos positivos o negativos en la comunidad? ¿Se observan impactos fiscales o ramificaciones en la ICANN (plan estratégico, plan operativo, presupuesto), la comunidad o el público? ¿Se observan cuestiones sobre seguridad, estabilidad o flexibilidad relacionadas con el DNS?

      El PIR identificó que los beneficios de introducir la vinculación técnica obligatoria sería dobles: (1) elimina la probabilidad de confusión pública que puede surgir razonablemente en caso de que distintas entidades de gTLD pudieran registrar el mismo dominio de segundo nivel y (2) brinda al registratario una registración preventiva a fin de garantizar que pueda centrarse en su misión y difusión de forma transparente y efectiva. No obstante, se requiere información adicional para comprender otros posibles impactos sobre la comunidad asociadas con las consecuencias generales de este servicio cuando se introduzca en el DNS.

      La eventual implementación de este servicio de registro puede tener un impacto fiscal en la ICANN, la comunidad o el público, ya que puede haber costos adicionales asociados con las consecuencias generales de este servicio de registro.

      El informe del RSTEP identificó la evaluación técnica de este servicio de registro propuesto con respecto a la probabilidad y materialidad de los efectos en cuanto a la seguridad y estabilidad y concluye que el servicio de registro propuesto no crea un riesgo razonable de un efecto adverso significativo sobre la seguridad o estabilidad.

      Varias comunidades, en particular aquellas interesadas en las variantes de los IDN, han trabajado en soluciones durante varios años sobre las cuestiones de similitud de etiquetas, de las cuales la vinculación técnica de .NGO y .ONG es un ejemplo, pero aún no se ha logrado una resolución total. Es posible que estas comunidades aporten ideas para la resolución de las cuestiones de similitud y puede ser adecuado consultar con dichas comunidades. La acción de la Junta Directiva no tiene como objetivo, bajo ningún punto de vista, sentar un precedente o crear un requisito para el tratamiento de las cuestiones de las variantes IDN y, en cada circunstancia, se debe evaluar según el caso.

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

      La Política de Evaluación de Servicios de Registro es una política consensuada de la ICANN, vigente desde el 15 de agosto de 2006. En consonancia con la política del 29 de julio de 2014, el informe del RSTEP se publicó para comentarios públicos. El periodo de comentarios públicos finalizó el 13 de agosto de 2014 y no se recibieron comentarios. Además, el 10 de junio de 2014 la ICANN publicó la solicitud de RSEP de PRI para comentario público. El periodo de comentarios públicos finalizó el 30 de julio de 2014 y no se recibieron comentarios.

    2. Planificación para Futuras Rondas de Solicitudes de gTLD

      No se adoptó ninguna resolución.

    3. Presupuesto y Plan Operativo del Año Fiscal 2015 (FY15)

      Visto y considerando que, el Plan Operativo y Presupuesto para el Año Fiscal 2015 (FY15) fue publicado para comentarios públicos, de conformidad con los Estatutos, el 8 de mayo de 2014, el cual se basó en numerosas consultas a la comunidad, y las consultas al personal de ICANN y el Comité Financiero de la Junta Directiva, durante el pasado año fiscal.

      Visto y considerando que, las actividades llevadas a cabo, y los comentarios recibidos del foro de comentarios públicos resultaron en algunas revisiones significativas al Borrador del Plan Operativo y Presupuesto para el Año Fiscal 2015 (FY15) del 8 de mayo de 2014.

      Visto y considerando que, además del foro de comentarios públicos, la ICANN solicitó, en forma activa, la retroalimentación de la comunidad y la consulta con la comunidad de la ICANN por otros medios, que incluyeron teleconferencias en línea, las reuniones celebradas en Singapur y Londres, y comunicaciones por correo electrónico.

      Visto y considerando que, el Comité Financiero de la Junta Directiva de la ICANN ha discutido y orientado al personal sobre el desarrollo del Plan Operativo y Presupuesto para el Año Fiscal 2015 (FY15) en cada una de sus reuniones recientes, programadas con regularidad.

      Visto y considerando que, el Comité Financiero de la Junta Directiva de la ICANN se reunió el 19 de agosto de 2014 para debatir el borrador final del Plan Operativo y Presupuesto para el Año Fiscal 2014 (FY15) y recomendó su adopción a la Junta Directiva.

      Visto y considerando que, según lo establecido en sección 3.9 de los Acuerdos de Acreditación de Registradores de los años 2001, 2009 y 2013, respectivamente, la Junta Directiva debe establecer la Tarifa de Acreditación Variable para el Registrador que ha de determinarse para desarrollar el presupuesto anual.

      Visto y considerando que, la descripción de las tarifas del Registrador, que incluye la Tarifa de Acreditación Variable para el Registrador, recomendadas para el Año Fiscal 2015 (FY15) han sido incluidas en el Presupuesto y Plan Operativo para el Año Fiscal 2015 (FY15).

      Resuélvase (2014.09.09.07): la Junta Directiva aprueba el Plan Operativo y Presupuesto para el Año Fiscal 2015 (FY15) y, al hacerlo, establece la Tarifa de Acreditación Variable para el Registrado (por registrador y transacción) tal como se determina en el Plan Operativo y Presupuesto para el Año Fiscal 2015 (FY15) [PDF, 621 KB].

      Fundamento de la Resolución 2014.09.09.07

      De conformidad con el Artículo XVI, Sección 4 de los Estatutos de la ICANN, la Junta Directiva deberá aprobar un presupuesto anual y publicarlo en el sitio web de la ICANN. El 8 de mayo de 2014, se publicó el Plan Operativo y Presupuesto para el Año Fiscal 2015 (FY15) para comentarios públicos. Esta versión se basa en los numerosos debates con los miembros del equipo Ejecutivo, y las extensas consultas con las Organizaciones de Apoyo y los Comités Asesores de la ICANN, y otros grupos de partes interesadas durante varios meses previos. Visto y considerando que, las actividades llevadas a cabo, y los comentarios recibidos del foro de comentarios públicos resultaron en algunas revisiones significativas al Borrador del Plan Operativo y Presupuesto para el Año Fiscal 2015 (FY15) del 8 de mayo de 2014.

      Se consideraron todos los comentarios recibidos en todas sus formas para el desarrollo de la versión final del Plan Operativo y Presupuesto para el Año Fiscal 2015 (FY15), y siempre que fue posible y factible han sido adoptados.

      Además de los requisitos operativos diarios, el Plan Operativo y Presupuesto para el Año Fiscal 2015 (FY15) incluye las partidas presupuestarias para los nuevos gTLD para el Año Fiscal 2015 y los importes asignados a las diversas solicitudes de presupuesto para el Año Fiscal 2015 ( FY15) recibidas y provenientes de los líderes de la comunidad. El presupuesto anual también da a conocer los impactos del programa de nuevos gTLD. Además, dado que la Tarifa de Acreditación Variable para el Registrador es clave para el desarrollo del presupuesto, el Plan Operativo y Presupuesto para el Año Fiscal 2015 (FY15) establece y determina dichos honorarios, que están en consonancia con los últimos años, y serán revisados ​​para su aprobación por parte de los Registradores.

      Este Plan Operativo y Presupuesto para el Año Fiscal 2015 (FY15) tendrá un impacto positivo, ya que proporciona un marco adecuado para la administración y operación de la ICANN. También proporciona las bases para que la organización rinda cuentas de manera transparente. Esto tendrá un impacto fiscal sobre la ICANN y la comunidad tal como se espera. Esto no debería tener nada más que un impacto positivo en la seguridad, estabilidad y flexibilidad del sistema de nombres de dominio (DNS) respecto de cualquier otra financiación dedicada a dichos aspectos del DNS.

    4. Borrador Final del Plan Estratégico de Cinco Años de la ICANN para los Años Fiscales 2016 – 2020 (FY16-FY20)

      Punto eliminado del orden del día.

    5. Reconocimiento de la Declaración de la Segunda Cumbre de At-Large

      Visto y considerando que, se celebró la Segunda Cumbre de At-Large (ATLAS II) en la reunión ICANN 50 en Londres, Reino Unido en junio de 2014.

      Visto y considerando que, la reunión de ATLAS II se creó sobre la base de la primera cumbre organizada en marzo de 2009 en la reunión de ICANN 34 celebrada en México.

      Visto y considerando que, la Junta Directiva ha recibido la Declaración Final de ATLAS II, (https://community.icann.org/download/attachments/48338039/ATLAS-II-Declaration-with-appendix-RC9.pdf?version=1&modificationDate=1407420726000&api=v2) [PDF, 204 KB].

      Visto y considerando que, la comunidad de At-Large continúa con el espíritu de compromiso y entusiasmo demostrado en la Cumbre mediante una serie de actividades de implementación posteriores a la reunión de ATLAS II.

      Resuélvase (2014.09.09.08), la Junta Directiva reconoce la declaración final de ATLAS II y hace extensiva sus felicitaciones por la exitosa Cumbre realizada durante la reunión ICANN 50, celebrada en Londres.

      Resuélvase (2014.09 09.09), la Junta Directiva afirma la importancia de la Cumbre ATLAS II y sus resultados como un aporte valioso de la Comunidad At Large de usuarios individuales de Internet para el fortalecimiento de la ICANN.

      Resuélvase (2014.09.09.10), la Junta Directiva expresa su agradecimiento por los inmensos esfuerzos realizados por parte de la Comunidad de At-Large en la realización de la Cumbre de At- Large, la Declaración Final resultante de ATLAS II y las actividades de implementación posteriores a dicha reunión.

      Resuélvase (2014.09.09.11), la Junta Directiva espera realizar un seguimiento junto con el ALAC sobre los aportes proporcionados a partir de la Declaración Final de la reunión ATLAS II.

      Nota: Tres miembros con derecho a voto de la Junta Directiva se abstuvieron de votar estas resoluciones. Señalaron, para los registros, que estaban a favor del trabajo resultante de la reunión ATLAS, pero que deseaban llamar la atención de la Junta Directiva e instarla a que, en el futuro, considere medidas para que ATLAS se transforme en un evento que se realice con regularidad.

      Fundamentos de las resoluciones 2014.09.09.08 – 2014.09.09.11

      La Segunda Cumbre de At-Large (ATLAS II), que fue posible gracias a que la Junta Directiva aprobará un presupuesto especial para dicho evento, resultó en la redacción de una Declaración de ATLAS II. Esta declaración fue enviada por Olivier Crépin-Leblond a Steve Crocker el 7 de agosto de 2014.

      Este documento es el resultado del trabajo de aproximadamente 150 Estructuras de At-Large provenientes de 70 países que se reunieron en forma presencial en Londres durante el mes de Junio de 2014

      La Declaración incluye el trabajo de los 5 Grupos de Trabajo Temáticos de ATLAS II:

      • Grupo temático 1 (TG1): El futuro de los modelos de múltiples partes interesadas.
      • Grupo temático 2 (TG2): La globalización de la ICANN
      • Grupo temático 3 (TG3): Internet Global: La Perspectiva del Usuario
      • Grupo temático 4 (TG4): Responsabilidad y transparencia de la ICANN
      • Grupo temático 5 (TG5): Participación de la comunidad At-Large en la ICANN

      Contiene 43 Recomendaciones para la Junta Directiva de la ICANN, para la ICANN y para el ALC, referidas como R- 1 a R- 43. Además contiene 10 Observaciones para la Comunidad de Internet en general, referidas como O-1 a O-10.

      En la actualidad, la comunidad de At-Large está comenzando a trabajar en la implementación de las Recomendaciones y Observaciones mediante un Grupo de Tareas especial.

      El ALAC espera los aportes de la Comunidad de la ICANN en general sobre la Declaración.

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

    6. Otros temas a tratar

      No se adoptó ninguna resolución.

resolutions-09sep14-es.pdf  [256 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."