Skip to main content
Resources

Minutas | Reunión Ordinaria de la Junta Directiva de la ICANN

Esta página está disponible en:

El día 12 de febrero de 2015 a las 14:00 (hora local de Singapur), se realizó una Reunión Ordinaria de la Junta Directiva de la Corporación para la Asignación de Números y Nombres en Internet (ICANN) en Singapur.

Steve Crocker, Presidente de la Junta Directiva, declaró abierta la sesión con puntualidad.

Los siguientes Directores participaron en forma total o parcial de la reunión: Rinalia Abdul Rahim, Cherine Chalaby, Fadi Chehadé (Presidente y Director Ejecutivo), Chris Disspain, Asha Hemrajani, Wolfgang Kleinwächter, Markus Kummer, Bruno Lanvin, Erika Mann, Gonzalo Navarro, Ray Plzak, George Sadowsky, Mike Silber, Bruce Tonkin (Vicepresidente) y Kuo-Wei Wu.

Los siguientes coordinadores de enlace de la Junta Directiva participaron de toda o parte de la reunión: Ram Mohan, Coordinador de enlace del Comité Asesor de Seguridad y Estabilidad (SSAC), Jonne Soininen, Coordinador de enlace del Grupo de Trabajo en Ingeniería de Internet (IETF), y Suzanne Woolf, Coordinadora de enlace del Comité Asesor del Sistema de Servidores Raíz (RSSAC).

Secretario: John Jeffrey (Asesor Jurídico General y Secretario).

  1. Orden del día convenido:
    1. Aprobación de las actas de las reuniones de la Junta Directiva
    2. Redelegación del dominio бел ("bel") en representación de la República de Bielorrusia en código de escritura cirílico a Reliable Software Inc.
    3. Eliminación del dominio de alto nivel .TP que representa a Timor Portugués
    4. Recomendaciones de política del Consejo de la GNSO sobre la Política de Transferencia entre Registradores - Parte D
    5. Recomendaciones para la recopilación de indicadores de medición y referencias comparativas para el Programa de Nuevos gTLD en apoyo a la futura Revisión de la AoC sobre Competencia, Confianza y Elección del Consumidor
    6. Redesignación de miembros para el Comité Asesor de Seguridad y Estabilidad (SSAC):
    7. Designación de Geoff Huston como integrante del Comité Asesor de Seguridad y Estabilidad (SSAC)
    8. Agradecimiento a los miembros de la comunidad que dejan de prestar servicio
    9. Agradecimiento a los patrocinadores de la Reunión N.º 52 de la ICANN
  2. Orden del día principal:
    1. Liberación de los códigos de dos caracteres en el segundo nivel en los gTLD

  1. Orden del día convenido:

    El Presidente presentó los puntos del orden del día convenido. El Presidente solicitó proceder a la votación, y la Junta tomó la siguiente medida:

    Resuélvase: se aprueban las siguientes resoluciones del orden del día convenido.

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

      Resuélvase (2012.02.12.01): La Junta Directiva de la Corporación para la Asignación de Nombres y Números en Internet (ICANN) aprueba las actas de sus reuniones de los días 17 de noviembre de 2014 y 3 de diciembre de 2014.

    2. Redelegación del dominio бел ("bel") en representación de la República de Bielorrusia en código de escritura cirílico a Reliable Software Inc.

      Resuélvase (2015.02.12.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 delegación del dominio de alto nivel con código de país бел y delegación del dominio de alto nivel con código de país a Reliable Software Inc. La documentación demuestra que se siguieron los procedimientos adecuados para la evaluación de la solicitud.

      Resuélvase (2015.02.12.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 minutas 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 2015.02.12.02 – 2015.02.12.03

      ¿Por qué la Junta Directiva 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 al Departamento de 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) a Reliable Software Inc.

      ¿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?

      [OMITIDO - Información confidencial sobre la Delegació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.

    3. Eliminación del dominio de alto nivel .TP que representa a Timor Portugués

      Visto y considerando que, el código de dos caracteres "TP" fue eliminado de la norma ISO3166 - 1 y reemplazado por el código "TL" que representa a Timor-Leste. Visto y considerando que, el nombre de dominio .TL fue delegado en el 2005 para reemplazar al nombre de dominio .TP, y que se llevó a cabo una transición de varios años que permitía a los Registratarios de .TP migrar al nuevo dominio de alto nivel con código de país.

      Visto y considerando que, la ICANN recibió la confirmación por parte del Gobierno de Timor Leste quien está a favor de la eliminación definitiva de la delegación de .TP de la Zona Raíz del DNS.

      Resuélvase (2015.02.12.04), se elimina la delegación de .TP de la Zona Raíz del DNS.

      Fundamento de la resolución 2015.02.12.04

      ¿Por qué la Junta Directiva aborda el tema ahora?

      Se planea eliminar el dominio de alto nivel .TP de la Zona Raíz del DNS para el 28 de febrero de 2015. El Gobierno de Timor Oriental como operador de .TP confirmó su consentimiento de eliminar .TP de la Zona Raíz del DNS.

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

      La propuesta es aprobar una solicitud a la IANA para eliminar la delegación del dominio de alto nivel .TP (Timor Portugués) de la Zona Raíz del DNS.

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

      Durante la evaluación de la solicitud de eliminación, el personal de la ICANN consulta al solicitante y a otras partes interesadas. Como parte del proceso de eliminación, el operador actual tiene que describir los pasos seguidos para garantizar que la eliminación del dominio de alto nivel no tenga consecuencias adversas no previstas en la estabilidad 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. El gobierno de Timor -Leste confirmó que el dominio de alto nivel .TP ya no se encuentra en uso.

      ¿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. d. Recomendaciones de política del Consejo de la GNSO sobre la Política de Transferencia entre Registradores - Parte D

      Visto y considerando que, 17 de enero de 2013, el Consejo de la GNSO (Organización de Apoyo para Nombres Genéricos) lanzó un Proceso de Desarrollo de Políticas (PDP) sobre la Parte D de la Política de Transferencia Entre Registradores (Parte D de la IRTP) abordando tres preguntas estatutarias establecidas en: https://community.icann.org/display/ITPIPDWG/3.+WG+Charter.

      Visto y considerando que el PDP siguió los pasos establecidos para dicho proceso, de acuerdo con lo estipulado en los Estatutos, y generó el Informe Final que fue presentado el 25 de septiembre de 2014.

      Visto y considerando que, el Grupo de trabajo sobre la Parte D de la IRTP alcanzó un consenso completo sobre las recomendaciones en relación a cada una de las seis cuestiones delineadas en la carta orgánica.

      Visto y considerando que, el Consejo de la GNSO examinó y debatió las recomendaciones del Grupo de trabajo sobre la Parte D de la IRTP y adoptó las Recomendaciones el día 15 de octubre de 2014 mediante votación unánime (véase: http://gnso.icann.org/en/council/resolutions#20141015-1).

      Visto y considerando que, la votación del Consejo de la GNSO alcanzó y superó el umbral de votación requerido (es decir, la supermayoría) para imponer nuevas obligaciones a las partes contratadas de la ICANN.

      Visto y considerando que, luego de la votación del Consejo de la GNSO hubo un período para la recepción de comentarios públicos sobre las recomendaciones aprobadas, y que los comentarios han sido resumidos y considerados (véase: https://www.icann.org/public-comments/irtp-d-recommendations-2014-10-20-en).

      Resuélvase (2015.02.12.05), la Junta Directiva adopta las Recomendaciones de Política del Consejo de la GNSO que modifican la política de transferencia entre registros establecida en http://www.icann.org/en/transfers/policy-en.htm http://www.icann.org/en/transfers/policy-en.htmy la Política de Resolución de Disputas Relacionadas con Transferencia (TDRP) establecida en https://www.icann.org/resources/pages/tdrp-2012-02-25-en.

      Resuélvase (2015.02.12.06), la Junta Directiva instruye al Presidente y Director Ejecutivo, o quien este designe, a desarrollar y completar un plan de implementación para estas recomendaciones y continuar la comunicación y cooperación con el Equipo para la Revisión de la Implementación de la GNSO y la comunidad en relación al trabajo de implementación.

      Fundamentos de las resoluciones 2015.02.12.05-2015.02.12.06

      ¿Por qué la Junta Directiva aborda el tema ahora?

      La Política de Transferencia entre Registradores (IRTP) es una política de consenso que fue adoptada en 2004, la cual establece un proceso directo para que los registratarios transfieran los nombres de dominio entre registradores. El Consejo de la GNSO estableció cinco grupos de trabajo (Partes A - D) para examinar y considerar diversas revisiones a esta política.

      La Parte D del Proceso de Desarrollo de Políticas para la Política de Transferencia entre Registradores es el cuarto y último proceso de desarrollo de políticas programado para abordar áreas de mejora en la política existente.

      El Informe final de la Parte D del PDP sobre la IRTP recibió el respaldo de un consenso unánime por parte de dicho grupo, así como también por parte del Consejo de la GNSO. Con posterioridad al cierre del período de comentarios públicos, la siguiente etapa, según lo establecido en el Anexo A de los Estatutos de la ICANN, es someter las recomendaciones a consideración de la Junta Directiva de la ICANN.

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

      Se han adoptado las siguientes recomendaciones:

      Recomendación n.º 1: El Grupo de Trabajo (WG) recomienda incorporar el informe de requisitos a la política de TDRP. Los resultados de todas las decisiones de los Proveedores de Resolución de Disputas (DRP)1 deben publicarse en el sitio web de los proveedores, excepto en casos excepcionales, de acuerdo con las prácticas actualmente empleadas en la UDRP. Las excepciones, si el DRP las solicitara, se otorgarán mediante el Departamento de Cumplimiento Contractual de la ICANN de manera específica para cada caso. El Grupo recomienda la publicación de los informes que sigan el ejemplo del Centro Asiático para la Resolución de Disputas de Nombres de Dominio (ADNDRC).2 Estos informes deben incluir como mínimo:

      1. El nombre de dominio en disputa
      2. Información relevante acerca de las partes afectadas por la disputa
      3. La decisión completa del caso
      4. La fecha de implementación de la decisión

      La necesidad de publicación no se aplica a las decisiones relacionadas con la TDRP que hayan tenido lugar antes de la implementación de esta recomendación.

      Recomendación n.º 2 El Grupo de Trabajo (WG) recomienda que se modifique la TDRP para incluir una redacción acorde a la versión revisada del UDRP:

      "El Proveedor de Servicios de Resolución de Disputas pertinente deberá informar sobre cualquier decisión realizada con respecto a una disputa de transferencia iniciada según la TDRP. Todas las decisiones, conforme esta Política, se publicarán en su totalidad en Internet, excepto cuando el Panel, convocado por la Resolución de Disputas, determine, en un caso excepcional, omitir parte de esa decisión. En cualquier caso, se deberá publicar la parte de toda decisión donde se determina que se ha interpuesto un reclamo de mala fe".

      Recomendación n.º 3 El Grupo de Trabajo recomienda que la TDRP se enmiende con la redacción siguiente o una equivalente: "Las transferencias de un Registrador Receptor a un tercer registrador, y todas las subsecuentes transferencias, son nulas e inválidas si el Registrador Receptor adquirió el patrocinio de un Registrador de Registro mediante una transferencia no válida, tal como se determina mediante el proceso de resolución de disputas establecido en la Política de Resolución de Disputas Relacionadas con Transferencias."

      Recomendación n.º 4: El Grupo de Trabajo recomienda devolver directamente el nombre de dominio al registrador de registro y al registratario si se comprueba, mediante un procedimiento de TDRP, que ha ocurrido una transferencia de nombre de dominio que no cumple con la IRTP.

      Recomendación n.º 5: El Grupo de Trabajo recomienda extender el estado de prescripción para iniciar una TDRP de 6 meses a 12 meses a partir de la transferencia inicial.

      Esto es para dar a los registratarios la oportunidad de estar al tanto de transferencias fraudulentas cuando ya no recibirían la notificación de WDRP anual por parte del registrador.

      Recomendación n.º 6: El Grupo de Trabajo recomienda que, si se inicia una solicitud de cumplimiento conforme a la TDRP, se debe "bloquear" el nombre de dominio en cuestión para evitar futuras transferencias mientras esté pendiente dicha solicitud de cumplimiento. De la misma manera, las acciones de TDRP y URS se deben agregar a la segunda viñeta de la lista de razones de denegación de IRTP (Sección 3). La IRTP y TDRP deben modificarse en consecuencia.3

      La TDRP, al igual que las pautas para los registradores, registros y los terceros proveedores de servicios de resolución de disputas, se debe modificar en consecuencia. El Grupo de Trabajo observa que el bloqueo se debe ejecutar según lo estipula la UDRP: después de haberse implementado el proceso de bloqueo de UDRP.

      Recomendación n.º 7: El Grupo de Trabajo recomienda agregar una lista de definiciones (Anexo F del Informe Final) a la TDRP para lograr una política más fácil y clara.

      Recomendación n.º 8: : El Grupo de Trabajo recomienda que no se desarrollen opciones para la resolución de disputas para los registratarios como parte de la actual TDRP.

      Recomendación n.º 9: El Grupo de Trabajo recomienda que el personal, en estrecha colaboración con el equipo de revisión de la aplicación de la Parte C de la IRTP, garantice que las recomendaciones de transferencia entre registratarios de IRTP, Parte C, se implementen y supervisen si los mecanismos de resolución de disputas son necesarios para cubrir los casos de uso del Anexo C del Informe Final. Una vez que se implementa una política de este tipo, su funcionamiento debe ser supervisado minuciosamente y, si es necesario, se elaborará un informe de cuestiones para evaluar la necesidad de una política de disputas de transferencia entre registratarios. Véase también las Recomendaciones n.º 17 y n.º 18 a continuación.

      Recomendación n.º 10: El Grupo de Trabajo recomienda que se modifique la TDRP a fin de eliminar el Primer Nivel (Registro) de la TDRP. La ICANN debería supervisar el uso de las TDRP y, si la discontinuación del registro como proveedor de primer nivel para la resolución de disputas pareciera crear una barrera para este mecanismo de resolución de disputas, se debería iniciar un nuevo trabajo futuro sobre la política para contrarrestar dicho efecto. Véase también la Recomendación n.º 17 a continuación.

      Recomendación n.º 11: El Grupo de Trabajo recomienda que la ICANN tome las medidas necesarias para mostrar información relevante a la disputa de transferencias que no cumplen con las normas de forma destacada en su sitio web y asegurar que la información se presente de manera sencilla y clara, y sea fácilmente accesible para los registratarios.

      Esta recomendación se debe considerar en combinación con la Recomendación n.º 12 (más abajo).

      Recomendación n.º 12: El Grupo de Trabajo recomienda que la ICANN cree y mantenga un único sitio web fácil de usar, que contenga toda la información relevante referida a las transferencias controvertidas y a las posibles soluciones para los registratarios. Se debe poder acceder al sitio web de manera clara desde la página de beneficios y responsabilidades de los registratarios de la ICANN o debe integrarse en esta (https://www.icann.org/resources/pages/benefits-2013-09-16-en) o similar.

      Esta debe incluir:

      • Información para alentar a los registratarios a ponerse en contacto con el registrador para resolver las transferencias en disputa en el nivel del registrador antes de incorporar al Departamento de Cumplimiento de la ICANN u otros terceros mediante el inicio de una TDRP.

      • Mejoras al sitio web de la ICANN en relación con la presentación de la información sobre la Política de Transferencia entre Registradores y la Política de Resolución de Disputas Relacionadas con Transferencias que se actualice regularmente (Sección 5.2.3.3, más arriba).

      • Vínculos que lleven a la información relevante para los registratarios en el sitio web de la ICANN, que estará redactada de manera clara y se presentará de manera prominente en la página inicial del sitio web de la ICANN. Esto contribuirá a mejorar la visibilidad y el contenido del sitio web de la ICANN que está dedicado a ofrecer orientación a los registratarios para cuestiones de transferencias.

      • El Departamento de Cumplimiento de la ICANN indica claramente en la sección de ayuda y preguntas frecuentes cuáles son las circunstancias en las que puede ayudar a los registratarios con disputas por transferencias. Esto debe incluir situaciones en las que los registratarios puedan solicitar al Departamento de Cumplimiento de la ICANN que insista a los registradores que están actuando en representación de dicho registratario.

      • Las mejoras en términos de accesibilidad y facilidad de uso deben implementarse especialmente en estas páginas:

      Además, los enlaces a estos sitios web de ayuda para el registratario deberían figurar de manera destacada en internic.net e iana.org a fin de garantizar, también, un acceso más sencillo a la información por parte de los registratarios.

      Recomendación n.º 13: El Grupo de Trabajo recomienda que, como mejor práctica, los Registradores Acreditados por la ICANN muestren adecuadamente un enlace en sus sitios web a este sitio de ayuda para el registratario de la ICANN. Los registradores también deben fomentar que todos los revendedores muestren prominentemente dichos enlaces. Además, el grupo recomienda que esto se comunique a todos los registradores acreditados por la ICANN.

      Los registradores puede optar por agregar este enlace a esas secciones de sus sitios web que ya contienen información relevante para el registratario, por ejemplo, los Derechos y Responsabilidades de los Registratarios, la información de WHOIS u otros enlaces pertinentes requeridos por la ICANN, tal como se indica en la sección 3.16 del RAA de 2013.

      Recomendación n.º 14: El Grupo de Trabajo recomienda no agregar a la IRTP o TDRP existente otras disposiciones en relación a las sanciones.

      Recomendación n.º 15: Como orientación para futuros procesos de desarrollo de políticas, este Grupo de Trabajo recomienda que se eviten, en lo posible, sanciones específicas de políticas. En cambio, las sanciones deben ser uniformes para todas las políticas y deben estar regidas por disposiciones aplicables incluidas en el RAA.

      Recomendación n.º 16: El Grupo de Trabajo no recomienda la eliminación de las FOA. Sin embargo, a la luz de los problemas respecto de FOA, como las transferencias masivas y las fusiones de registradores o revendedores, el grupo recomienda que la operatividad de FOA no se limite al correo electrónico. Entre las mejoras, se puede incluir la transmisión de FOA mediante SMS o autorización por medio de sitios web interactivos. No obstante, dichas innovaciones se deben poder auditar, ya que esta sigue siendo una de las funciones clave de FOA.

      El Grupo de Trabajo observa que la implementación de esta recomendación no se debería ver afectada por el modo de realización de las transferencias, es decir, por adelantado (para ciertas transferencias masivas) o en tiempo real.

      Recomendación n.º 17: El Grupo de Trabajo recomienda que, una vez que se hayan implementado todas las recomendaciones de IRTP (incluso IRTP-D y el resto de los elementos de IRTP-C), el Consejo de la GNSO, junto con el personal de la ICANN, convoque a un panel para recopilar, debatir y analizar los datos pertinentes a fin de determinar si estas mejoras han mejorado los procesos y los mecanismos de solución de disputas de IRTP, e identificar posibles deficiencias restantes.

      Si, después de un período de 12 meses desde esta revisión, la GNSO (con el personal de la ICANN) determina que la situación relacionada con las transferencias no mejoró, entonces este Grupo de Trabajo recomienda que se realice una re evaluación exhaustiva del proceso de transferencia. El objetivo es crear una política más simple, más rápida y más segura que sea más fácil de comprender y cuyo uso sea más accesible para los registratarios.

      Se recomienda también que en el Grupo de Trabajo de esta siguiente revisión se incluya un experto en seguridad de manera que si, por ejemplo, se requiriera un factor de autenticación real de 2 factores, se lo implemente en función de los estándares de la industria.

      Recomendación n.º 18: El Grupo de Trabajo recomienda que las partes contratadas y la ICANN comiencen a recopilar datos y otra información relevante que ayudarán a informar a un futuro equipo de IRTP en sus esfuerzos, sobre todo, en relación con los aspectos que figuran en las observaciones del Informe Final (4.2.7.1).

      Para facilitar la recopilación de datos relevantes, el Equipo para la Revisión de la Implementación debe trabajar en coordinación estrecha con el personal de la ICANN, de manera de garantizar el acceso rápido a los datos necesarios.

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

      La consulta habitual con las partes interesadas se llevó a cabo durante la vigencia de esta política. Se pueden consultar los detalles en la Lista de Seguimiento de Contribuciones (Anexo A del Informe Final).

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

      La comunidad no planteó ninguna inquietud con respecto al Informe Final y sus recomendaciones.

      ¿Qué materiales significativos analizó la Junta Directiva?

      La Junta directiva revisó el Informe Final, el Informe de Recomendaciones para la Junta Directiva del Consejo de la GNSO, así como el resumen de los comentarios públicos recibidos y la respuesta a esos comentarios.

      ¿Qué factores consideró importantes la Junta Directiva?

      Las recomendaciones fueron formuladas según el proceso de desarrollo de políticas de la GNSO, de conformidad con lo estipulado en el Anexo A de los Estatutos de la ICANN y han recibido el apoyo unánime del Consejo de la GNSO. De conformidad con los Estatutos de la ICANN, el apoyo de la supermayoría del Consejo para aprobar la moción (el Consejo votó a favor de manera unánime) obliga a la Junta Directiva a adoptar esta recomendación, a menos que con más del 66% de los votos, la Junta Directiva establezca que la política no beneficia a la comunidad de la ICANN o a la ICANN propiamente dicha.

      IAsimismo, las cuestiones relacionadas con las transferencias representan el mayor motivo de queja de acuerdo con los datos obtenidos del área de Cumplimiento de la ICANN. Las mejoras introducidas a la IRTP podrán reducir la cantidad de reclamos y al mismo tiempo brindar claridad y previsibilidad tanto a los registratarios como a los registradores.

      ¿Existen impactos positivos o negativos para la comunidad?

      Las mejoras introducidas a la IRTP y TDRP podrán reducir la cantidad de reclamos y al mismo tiempo brindar claridad y previsibilidad tanto a los registratarios como a los registradores. La aprobación de las recomendaciones requerirá cambios significativos en los procesos para los registradores, así como registradores y por lo tanto se espera que la implementación de estas recomendaciones requiera de tiempo y recursos, pero estos se consideran necesarios para abordar las cuestiones que forman parte de este proceso de desarrollo de políticas. Las recomendaciones, si fueran implementadas, serán de utilidad para aclarar y mejorar la IRTP y TDRP en beneficio de todas las partes involucradas.

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

      Además de aquellos cambios que se requieren en el proceso para los registradores, como se indicó anteriormente, es probable que haya impactos fiscales relacionados con la implementación de la política - por ejemplo las actualizaciones al sitio web de la ICANN - , pero se prevé que estos costos estén dentro del presupuesto actual.

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

      No se observan cuestiones sobre seguridad, estabilidad ni flexibilidad relacionadas con el Sistema de Nombres de Dominio (DNS) como consecuencia de la aprobación por parte de la Junta Directiva de las recomendaciones propuestas.

    5. Recomendaciones para la recopilación de indicadores de medición para el Programa de Nuevos gTLD en apoyo a la futura Revisión de la AoC sobre Competencia, Confianza y Elección del Consumidor

      Visto y considerando que, en la Afirmación de Compromisos (AoC), la ICANN se ha comprometido a organizar una revisión para examinar hasta qué punto la introducción de los nuevos gTLD ha promovido la competencia, la confianza y la elección del consumidor, una vez que los nuevos gTLD hayan estado en funcionamiento durante un año.

      Visto y considerando que, el 10 de diciembre de 2010 la Junta Directiva de la ICANN solicitó al Comité Asesor At-Large (ALAC), al Comité Asesor Gubernamental (GAC), a la Organización de Apoyo para Nombres Genéricos (GNSO) y a la Organización de Apoyo para Nombres de Dominio con Código de País (ccNSO) que brindasen aportes sobre el establecimiento de la definición, los criterios de medición y los objetivos trienales a lograr en materia de competencia, confianza y elección del consumidor en el contexto del sistema de nombres de dominio. La Junta Directiva recibió los aportes en 2013 del Consejo de la GNSO [PDF, 352 KB] y el ALAC [PDF, 491 KB], que brindan recomendaciones sobre indicadores de medición específicos.

      Visto y considerando que, la Junta Directiva instruyó (en las resoluciones 2013.07.18.05 – 2013.07.18.07 and 2013.09.28.13 – 2013.09.28.14) al Presidente y Director Ejecutivo convocar a un grupo de voluntarios (el Grupo Asesor de Implementación de Competencia, Elección y Confianza del Consumidor [IAG-CCT]) antes de a un futuro Equipo de Revisión de la AoC sobre Competencia, Confianza y Elección de los Consumidores, para diferentes motivos que incluyen la evaluación e informe a la Junta Directiva de la viabilidad, utilidad y costo-efectividad de la adopción de las recomendaciones del Consejo de la GNSO y el ALAC.

      Visto y considerando que, el 1 de octubre de 2014, el IAG-CCT submitted a la Junta Directiva su Informe final sobre sus recomendaciones para recabar datos para la revisión en materia de competencia, confianza y elección de los consumidores.

      Resuélvase (2015.02.12.07), la Junta Directiva de la ICANN agradece al IAG-CCT por su trabajo diligente y sus recomendaciones para recabar datos como aportes a las futuras revisiones en materia de competencia, confianza y elección del consumidor en el espacio de gTLD;

      Resuélvase (2015.02.12.08), por la presente se instruye al Presidente y Director Ejecutivo de la ICANN, o quien este designe, comenzar de manera inmediata con la recopilación de datos sobre los indicadores de medición recomendados en el Informe Final del IAG-CCT, dando prioridad a aquellos que son sensibles en relación al tiempo y cuando se determine que los datos se encuentran disponibles.

      Resuélvase (2015.02.12.09), por la presente, se instruye al Presidente y Director Ejecutivo, o quien este designe, recopilar datos para los indicadores de medición enumerados en la Tabla 4 de Informe Final del IAG-CCT [DOCX, 105 KB] conforme los datos estén disponibles, teniendo en cuenta que estos indicadores de medición están marcados para una posible recopilación posterior, previo debate del Equipo de Revisión que será formado.

      Fundamentos de las resoluciones 2015.02.12.07 – 2015.02.12.09

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

      Esta resolución es una continuación de las resoluciones que la Junta Directiva aprobó (2013.07.18.05 – 2013.07.18.07 and 2013.09.28.13 – 2013.09.28.14) r, relativas a la evaluación de los indicadores de medición propuestos por la Comunidad para su uso en una futura revisión en virtud de la Afirmación de Compromisos (AoC) sobre el impacto de los nuevos gTLD en las áreas de competencia, confianza y elección de los consumidores. También se basa en las resoluciones de la Junta Directiva (2014.03.27.22 - 2014.03.27.26), relativas a la adopción de las recomendaciones provisionales del Grupo Asesor para la Implementación sobre una encuesta para los consumidores y un estudio en materia económica.

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

      La resolución de la Junta Directiva requiere que la ICANN comience inmediatamente a recabar datos sobre esos indicadores de medición recomendados por el IAG-CCT. La resolución adopta la mayoría de las recomendaciones del IAG y permite al Equipo de Revisión analizar ciertos indicadores de medición en relación a los costos y utilidad, aunque los datos sobre estos indicadores de medición estarán disponibles conforme se recopilen.

      Este trabajo debe comenzar de forma inmediata e implica autorizar al personal a dedicar tiempo para recabar la información necesaria o comprar, o bien, adquirir datos de terceros relevantes, lo que incluye a las partes contratadas de la ICANN.

      ¿Qué materiales significativos analizó la Junta Directiva?

      La Junta Directiva analizó el informe final del Grupo Asesor para la Implementación con fecha del 1 de octubre de 2014 (https://community.icann.org/download/attachments/48349551/IAGCCT%20Final%20report.docx?version=1&modificationDate=1418863127000&api=v2 [DOCX, 105 KB]), los materiales informativos presentados por el personal, las resoluciones adoptadas en el mes de marzo de 2014 que aprobaban financiación para la encuesta para el consumidor y el estudio en materia económica y las cartas de asesoramiento previas, relacionadas del ALAC [PDF, 491 KB] y la GNSO [PDF, 352 KB], que incluye una versión actualizada de dicho asesoramiento con las actuales recomendaciones de IAG-CCT.

      ¿Qué factores consideró importantes la Junta Directiva?

      La Junta Directiva considera que los datos a ser recopilados a partir de estas encuestas son fundamentales para apoyar un examen preciso de la medida en que la introducción de los gTLD ha promovido la competencia, la confianza y la elección de los consumidores. Al participar en estas actividades ahora, la ICANN se compromete a garantizar que los datos relevantes estén disponibles para el futuro Equipo de Revisión, así como para la comunidad más en general, con el fin de apoyar el futuro análisis del Programa de Nuevos gTLD que se realizará en virtud de la AoC. La recomendación requiere que se prosiga con el trabajo de implementación destinado a facilitar el trabajo de la revisión de la AoC en el momento oportuno.

      ¿Se observan impactos financieros o ramificaciones en la ICANN (plan estratégico, plan operativo, presupuesto)?

      Los fondos para implementar esta resolución se incluyen en el presupuesto para el Año Fiscal 2015 (FY15) y se contabilizan en la planificación del presupuesto del Año Fiscal 2016 (FY16).

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

      Esta resolución no tiene ningún impacto sobre la seguridad, la estabilidad ni la flexibilidad del DNS.

      ¿Se requieren comentarios públicos antes de que la Junta Directiva tome medidas?

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

    6. Redesignación de miembros para el Comité Asesor de Seguridad y Estabilidad (SSAC):

      Visto y considerando que la Subsección 2 de la Sección 2 del Artículo XI de los Estatutos rige al Comité Asesor de Seguridad y Estabilidad (SSAC). Visto y considerando que la Junta Directiva, en su Resolución 2010.08.05.07, aprobó revisiones a los Estatutos que establecen periodos de servicio de tres años para los miembros del SSAC, requieren el escalonamiento de dichos periodos y obligan al presidente del SSAC a recomendar la re designación de todos los miembros actuales del SSAC por periodos de servicio completos o parciales, a fin de implementar las revisiones a los Estatutos.

      Visto y considerando que la Junta Directiva, en su resolución 2010.08.05.08, designó a los miembros del SSAC por periodos de servicio de uno, dos y tres años, los cuales comienzan el 1 de enero de 2011 y culminan respectivamente el 31 de diciembre de 2011, el 31 de diciembre de 2012 y el 31 de diciembre de 2013.

      Visto y considerando que, en el mes de junio de 2014, el Comité de Membresía del SSAC inició una revisión anual de los miembros del SSAC cuyos periodos de servicio finalizan el día 31 de diciembre de 2014, y presentó al SSAC sus recomendaciones de re designación.

      Visto y considerando que, el 24 de noviembre de 2014, los miembros del SSAC aprobaron las re designaciones.

      Visto y considerando que el SSAC recomienda a la Junta Directiva re designar a los siguientes miembros del SSAC por un periodo de tres años: Greg Aaron, Don Blumenthal, KC Claffy, Lyman Chapin, Steve Crocker, Mark Kosters, Russ Mundy, Rod Rasmussen y Mark Seiden.

      Resuélvase (2015.02.12.10), la Junta Directiva acepta la recomendación del SSAC y re designa a los siguientes miembros del SSAC por periodos de tres años que comenzarán el 1 de enero de 2015 y finalizarán el 31 de diciembre de 2017: Greg Aaron, Don Blumenthal, KC Claffy, Lyman Chapin, Steve Crocker, Mark Kosters, Russ Mundy, Rod Rasmussen y Mark Seiden.

      Fundamento de la resolución 2015.02.12.10

      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 de los sistemas de asignación de direcciones y de nombres de dominio de Internet. Las personas antes mencionadas brindan al SSAC el conocimiento y la experiencia requeridos para que el Comité cumpla con su mandato y ejecute su misión.

    7. Designación de Geoff Huston como integrante del Comité Asesor de Seguridad y Estabilidad (SSAC)

      Visto y considerando que, ocasionalmente, el Comité Asesor de Seguridad y Estabilidad (SSAC) realiza una revisión y cambio de sus miembros.

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

      Resuélvase (2015.02.12.11): La Junta Directiva designa a Geoff Huston como integrante del SSAC.

      Fundamento de la resolución 2015.02.12.11

      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 de los sistemas de asignación de direcciones y 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é. Geoff Huston aporta valiosos conocimientos al SSAC. El Sr. Huston es Jefe Científico de APNIC. Generalmente participa en proyectos en relación a indicadores de medición y de redes. En forma reciente, se ha centrado en el estudio del agotamiento del pool remanente direcciones IPv4 no asignadas, el tema relacionado con la implementación de IPv6, las mediciones del DNS y la implementación del DNSSEC y el diseño y estabilidad operativa del Recurso de Infraestructura de Clave Pública (RPKI). El SSAC cree que será un miembro que realizará contribuciones significativas al Comité.

    8. Agradecimiento a los miembros de la comunidad que dejan de prestar servicio

      Visto y considerando que, la ICANN desea reconocer la considerable energía y habilidades que los miembros 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, el siguiente miembro del Comité Asesor del Sistema de Servidores Raíz (RSSAC) está concluyendo su período de gestión:

      • Dr. Jun Murai – Presidente Fundador del RSSAC

      Resuélvase (2015.02.12.12): El Dr. Jun Murai 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 Comité Asesor de Seguridad y Estabilidad (SSAC) dejarán de prestar servicio una vez finalizado su período de gestión:

        • Rodney Joffe – Miembro del SSAC
        • Jason Livingood – Miembro del SSAC
        • Bruce Tonkin – Miembro del SSAC
        • Stefano Trumpy – Miembro del SSAC
        • Paul Vixie – Miembro del SSAC

      Resuélvase (2015.02.12.13): Rodney Joffe, Jason Livingood, Bruce Tonkin, Stefano Trumpy y Paul Vixie 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 el siguiente miembro de la Organización de Apoyo para Nombres Genéricos (GNSO) concluirá su mandato:

      • Kristina Rosette - Presidente de la Unidad Constitutiva de Propiedad Intelectual de la GNSO

      Resuélvase (2015.02.12.14): Kristina Rosette 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 Comité Asesor Gubernamental dejarán de prestar servicio una vez finalizado su período de gestión:

      • Tracy Hackshaw – Vicepresidente del GAC
      • Peter Nettlefold – Vicepresidente del GAC

      Resuélvase (2015.02.12.15): Tracy Hackshaw y Peter Nettlefold 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.

    9. Agradecimiento a los patrocinadores de la Reunión N.º 52 de la ICANN

      La Junta Directiva desea agradecer a los siguientes patrocinadores: VeriSign, Inc., Public Interest Registry, Afilias Limited, CentralNic, Internet Domain Name System Beijing Engineering Research Center (ZDNS), Neustar, NCC Group, Trademark Clearinghouse, Uniregistry Corp., Minds + Machines Group, Iron Mountain, Inc., ION Magazine, Radix FZC, e ICANNWIKI, InterConnect Communications Ltd, y Sedo GmbH.

      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 administración y al personal de Fairmont Singapore y Swissôtel The Stamford por ofrecer una maravillosa sede para realizar este evento. Hacemos extensivo el agradecimiento especial a:

      Dawn Ng, Gerente, Convenciones, Junta de Turismo de Singapur; NG Pei Sze, Gerente de Ventas Sénior para Reuniones, Incentivos, Convenciones y Exhibiciones; Ng Sok Hia, Asistente Ejecutiva de Gerente de Ventas y Comercialización; Joanne Kaeli Phua, Ejecutiva de Servicios para Conferencias, Centro de Convenciones Raffles City.

    Todos los miembros presentes de la Junta Directiva votaron a favor de las resoluciones 2012.02.12.01, 2012.02.12.02, 2012.02.12.03, 2012.02.12.04, 2012.02.12.05, 2012.02.12.06, 2012.02.12.07, 2012.02.12.08, 2012.02.12.09, 2012.02.12.10, 2012.02.12.11, 2012.02.12.12, 2012.02.12.13, 2012.02.12.14 y 2012.02.12.15. Las resoluciones fueron aprobadas.

  2. Orden del día principal:

    1. Liberación de los códigos de dos caracteres en el segundo nivel en los gTLD

      Bruce Tonkin presentó la moción y Cherine Chalaby secundó la siguiente resolución propuesta.

      Bruce presentó el punto del orden del día y brindó una descripción general de la resolución propuesta. Esta resolución es producto de los desarrollos y las actividades relacionadas con el lanzamiento de nombres de dominio de dos caracteres en el segundo nivel. El Acuerdo de Registro de Nuevos gTLD brinda dos métodos para liberar nombres de dominio de dos caracteres: (1) dichos nombres pueden liberarse siempre que el Operador de Registro llegue a un acuerdo con el gobierno relacionado y el gerente del código de país, o (2) el Operador de Registro puede proponer la liberación de los nombres sobre la base de la implementación de medidas que eviten confusión con los correspondientes códigos de país, sujeto a la aprobación por parte de la ICANN. En la reunión de Los Ángeles, la Junta Directiva indicó al personal que generara un procedimiento mediante el cual los Operadores de Registro pudieran solicitar la liberación de estos nombres. Posteriormente, la Junta Directiva recibió una carta del Presidente del GAC en la que indica algunas áreas en las que puede mejorarse el proceso. La Junta Directiva también se reunió con el GAC esta semana y obtuvo más asesoramiento del GAC en su comunicado, que fue recibido hoy por la Junta Directiva. Además, hoy la Junta Directiva escuchó a varios oradores en el foro público acerca de este tema.

      Ray Plzak y Chris Disspain comentaron que deberían incorporarse a la resolución propuesta algunas partes del texto del asesoramiento adicional del GAC. Chris explicó que la modificación propuesta atañe a la cláusula "Visto y considerando" de la resolución y sugirió que se incorporara más asesoramiento del GAC, es decir, que se publique en el sitio web del GAC la lista de miembros del GAC que desean acordar con todas las solicitudes y no requieren notificación. La Junta Directiva analizó la modificación y todos sus miembros votaron a favor de ella.

      Luego la Junta Directiva debatió la resolución propuesta recientemente modificada. Cherine Chalaby preguntó cuánto tiempo demoraría completar estos cambios y liberar los códigos de dos letras, ya que la comunidad y los registros aguardan el cambio. Akram Atallah (Presidente, División Global de Dominios) explicó que los períodos de comentarios se pueden programar muy rápidamente después de notificar a los miembros del GAC. Thomas Schneider comentó que algunos gobiernos aún no son miembros del GAC y que probablemente no sea necesario notificarlos de manera independiente. Akram respondió y explicó que la ICANN se esforzará para comunicarse con los gobiernos afectados por la liberación de dominios de dos letras que no son miembros del GAC.

      Luego el Presidente llamó a votación, y la Junta Directiva adoptó la siguiente acción:

      Visto y considerando que, el Acuerdo de Registro de Nuevos gTLD brinda dos métodos para liberar nombres de dominio de dos caracteres: (1) dichos nombres de dos caracteres pueden liberarse siempre que el Operador de Registro llegue a un acuerdo con el gobierno relacionado y el gerente del código de país, o (2) el Operador de Registro puede proponer la liberación de los nombres sobre la base de la implementación de medidas que eviten confusión con los correspondientes códigos de país, sujeto a la aprobación por parte de la ICANN.

      Visto y considerando que, el 16 de octubre de 2014, la Junta Directiva instruyó al personal a desarrollar e implementar un procedimiento eficiente para que la ICANN evalúe las solicitudes para la liberación de nombres de dos caracteres, teniendo en cuenta el asesoramiento del GAC en el Comunicado pronunciado en Los Ángeles el 16 de octubre de 2014.

      Visto y considerando que, la ICANN publicó e implementó el proceso, vigente desde el 1 de diciembre de 2014.

      Visto y considerando que, el 26 de enero de 2015 el Presidente del GAC envió una carta a la Junta Directiva de la ICANN en la que planteaba inquietudes en nombre de algunos miembros del GAC como usuarios del proceso. El GAC brindó una lista de sugerencias de posibles soluciones para abordar sus inquietudes.

      Visto y considerando que, el 11 de febrero de 2015, el GAC emitió asesoramiento a la Junta Directiva en su Comunicado en relación a la liberación de códigos de dos caracteres en el segundo nivel en los gTLD. El GAC recomendó a la Junta Directiva modificar el proceso actual para establecer un mecanismo de notificación eficaz, de manera que los gobiernos pertinentes puedan ser alertados a medida que se inician solicitudes. Se deben considerar completamente los comentarios de los gobiernos relevantes. El GAC también recomendó a la Junta Directiva extender el periodo de comentarios a 60 días. En el sitio web del GAC, se publicará una lista de miembros del GAC que tienen la intención de acordar con todos las solicitudes y no requieren notificación.

      Resuélvase (2015.02.12.16), la Junta Directiva acepta el asesoramiento del GAC contenido en su Comunicado del 11 de febrero de 2015 en relación a la liberación de los códigos de dos caracteres en el segundo nivel en los gTLD. La Junta Directiva instruye al Presidente y Director Ejecutivo, o quien este designe, a revisar el Proceso de Autorización para la Liberación de Etiquetas ASCII de dos caracteres y proceder inmediatamente de la siguiente manera:

      • Implementar mejoras al proceso para alertar a los gobiernos en cuestión cuando se inician las solicitudes. Los comentarios provenientes de los gobiernos pertinentes se deben considerar en su totalidad.
      • En el caso de solicitudes nuevas, el período de comentario público será de 60 días.
      • En el caso de solicitudes que tengan períodos de comentarios pendientes o que hayan finalizado, extender o reabrir el período de comentarios para que cada solicitud cumpla con un período de comentario de 60 días en total.

      Fundamento de la resolución 2015.02.12.16

      La Junta Directiva toma esta acción a fin de aceptar el asesoramiento de GAC contenido en el Comunicado del GAC pronunciado en Singapur el 11 de febrero de 2015 en relación a la liberación de los códigos de dos caracteres en el segundo nivel de los gTLD. El Artículo XI, Sección 2.1 de los Estatutos de la ICANN permite al GAC "exponer temas a la Junta Directiva directamente, ya sea por medio de un comentario o asesoramiento previo, o a través de recomendaciones específicas de acción, recomendaciones sobre el desarrollo de políticas nuevas o sobre la revisión de las políticas existentes". Los Estatutos de la ICANN requieren que la Junta Directiva tome en cuenta el asesoramiento del GAC respecto de las cuestiones de políticas públicas en la formulación y adopción de políticas. Si la Junta Directiva decide llevar a cabo una acción que no se ajusta al asesoramiento del GAC, esta deberá informarlo al GAC y explicar los motivos por los cuales ha decidido no seguir su asesoramiento. La Junta Directiva y el GAC intentarán entonces, de buena fe, hallar una solución que sea aceptable para ambos. En caso de que no fuese posible llegar a una solución, la Junta Directiva informará en su decisión final los motivos por los cuales no siguió el asesoramiento del GAC.

      La acción de la Junta Directiva hoy de aceptar el asesoramiento del GAC es la continuación de su resolución del 16 de octubre de 2014 en la cual la Junta Directiva autoriza al Presidente y Director Ejecutivo a desarrollar e implementar un procedimiento eficiente para la liberación de los dominios de dos caracteres que actualmente deben estar reservados en el Acuerdo de Registro de Nuevos gTLD, teniendo en cuenta el asesoramiento del GAC contendido en su Comunicado pronunciado en Los Ángeles.

      La ICANN desarrolló el Proceso de Autorización para la Liberación de las Etiquetas ASCII de dos caracteres a fin de implementar la resolución de la Junta Directiva. El 12 de noviembre de 2014, la ICANN publicó un blog en el que explicaba el nuevo proceso para la liberación de dominios de dos caracteres, que también se brindó al GAC. El proceso entró en vigencia el 1 de diciembre de 2014. El 26 de enero de 2015 el Presidente del GAC envió una carta a la Junta Directiva de la ICANN en la que planteaba inquietudes en nombre de algunos miembros del GAC como usuarios del proceso. El GAC brindó una lista de sugerencias de posibles soluciones para abordar sus inquietudes en relación al proceso.

      A la fecha, la ICANN ha recibido solicitudes de más de 300 registros en total. Como resultado de la acción de la Junta Directiva hoy, la ICANN extenderá o re abrirá el período de comentarios requerido por el proceso para que las solicitudes estén sujetas a un período de comentarios total de 60 días. En el caso de aquellas solicitudes que cumplieron con el período existente de 30 días, o se encuentran en proceso de hacerlo, el período de comentarios se extenderá o se re abrirá para que cada solicitud cumpla con el nuevo requisito de los 60 días. Por ejemplo, una solicitud que ha completado el período de 30 días, contará con un nuevo período adicional de 30 días. Una solicitud que ha estado sometida a comentarios durante 15 días, tendrá una extensión del período de comentarios durante 30 días para que pueda llegar al total de 60 días. Todas las solicitudes nuevas que se presenten serán, del mismo modo, sometidas a un período de comentarios de 60 días.

      La Junta Directiva analizó varios materiales y consideró además varios factores importantes durante su deliberación en relación a la acción que se estaba tomando. Los materiales y los factores importantes que la Junta Directiva consideró como parte de sus deliberaciones incluyeron los siguientes, entre otros:

      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. No se prevé que la implementación de la acción por parte de la Junta Directiva tenga un impacto fiscal significativo en la ICANN, la comunidad o el público. 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 el gTLD .name (.nombre), la liberación de dominios de dos caracteres en el segundo nivel no crea ningún riesgo razonable de efecto adverso para la seguridad y la estabilidad. Esta acción de la Junta Directiva no es un proceso de políticas definido dentro de las organizaciones de apoyo de la ICANN ni una decisión comprendida por la función organizacional y administrativa de la ICANN que requiera comentario público.

    Todos los miembros de la Junta Directiva presentes votaron a favor de la resolución 2015.02.12.16. Resolución aprobada.

    Después de esto, el Presidente declaró el cierre de la reunión.

Published on 27 April 2015


1 El Grupo de Trabajo recomienda en su pregunta C de la carta orgánica eliminar de la TDRP al Registro como primer nivel en la resolución de disputas. En consecuencia, sin perjuicio de redacción de la pregunta A de la carta orgánica, no se incluyen requisitos para emitir informes para los Registros.

2 Consulte cuatro informes del ADNDRC sobre decisiones relacionadas con la TDRP: http://www.adndrc.org/mten/TDRP_Decisions.php?st=6

3 https://www.icann.org/resources/pages/policy-transfers-2014-07-02-en

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