Skip to main content
Resources

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

Esta página está disponible en:

Este documento ha sido traducido a varios idiomas a título informativo únicamente. El texto original y autoritativo (en inglés) se puede obtener en: https://www.icann.org/resources/board-material/resolutions-2016-09-15-en

  1. Orden del día convenido:
    1. Implementación de las Recomendaciones del RSSAC003 para la validez de la firma KSK
    2. Delegación del dominio .বাংলা ("bangla") en representación de Bangladesh en código de escritura bengalí
    3. Contratación de la sede y emplazamiento para la reunión de la ICANN de octubre de 2018
    4. Designación del Presidente y Presidente electo del Comité de Nominaciones de 2017
  2. Orden del día principal:
    1. Contrato de Funciones de nombres de la IANA entre la ICANN y PTI
    2. Acuerdo de Servicios entre la ICANN y PTI
    3. Enmienda al Acuerdo de Registro de .COM
    4. Ítems de gobernanza de PTI: Adopción de los Estatutos de PTI. Designación de los Directores de la Junta Directiva Inicial de PTI. Designación del Presidente de PTI
    5. Consideración adicional de la Declaración Final del IRP de Dot Registry
    6. Consideración del Informe del Defensor del Pueblo en relación a dotgay, solicitud de LLC para .GAY
    7. Solicitud de Reconsideración 16-3 (dotgay LLC)
    8. Otros temas a tratar

 

  1. Orden del día convenido:

    1. Implementación de las Recomendaciones del RSSAC003 para la validez de la firma KSK

      Visto y considerando: Que, el 16 de septiembre de 2015, el Comité Asesor del Sistema de Servidores Raíz (RSSAC) de la ICANN (Corporación para la Asignación de Nombres y Números en Internet) publicó el documento RSSAC0003: Informe sobre los TTL (Tiempos de Vida Útil) de la Zona Raíz.

      Visto y considerando: Que, en el documento RSSAC003, el informe recomienda que los asociados de la Gestión de la Zona Raíz aumenten los períodos de validez de las firmas, para las firmas generadas por la Clave para la firma de la llave de la zona raíz (ambas KSK y ZSK). El informe también recomienda que la validez de la firma KSK debe ser aumentada a al menos 21 días, la validez de la firma ZSK debe ser aumentada a al menos 13 días, y que en este momento no se realicen más cambios en los TTL de la Zona Raíz.

      Visto y considerando: Que, tras recibir el documento RSSAC003, el personal de la ICANN realizó un análisis de factibilidad y costos relacionados al aumento de la validez de la firma KSK y creó un plan de implementación de KSK para que sea examinado por la Junta Directiva.

      Visto y considerando: Que la Junta Directiva ha considerado el asesoramiento del RSSAC en el documento RSSAC003, además de la viabilidad y los costos de implementación del asesoramiento relativo a la KSK. La Junta Directiva entiende que la entidad encargada del mantenimiento de la Zona Raíz también está considerando las recomendaciones del documento RSSAC003 en relación a la ZSK.

      Resuélvase (2016.09.15.01): La Junta Directiva adopta el asesoramiento del RSSAC para la validez de la firma KSK, presentado en el documento RSSAC 003, y encomienda al Presidente y Director Ejecutivo de la ICANN, o a quien éste designe, proceder a implementar las recomendaciones de KSK del documento RSSAC 003 en colaboración con los asociados de la Gestión de la Zona Raíz.

      Fundamento de la resolución 2016.09.15.01

      El 16 de septiembre de 2015, el Comité Asesor del Sistema de Servidores Raíces de la ICANN (RSSAC) publicó el documento RSSAC0003: Informe sobre los TTL (Tiempos de Vida) de la Zona Raíz. En este informe, el RSSAC estudia los TTL (valores de "Tiempo de Vida Útil") para la zona raíz y hasta qué punto los actuales TTL de la zona raíz siguen siendo apropiados para el entorno de Internet actual.

      El informe identificó dos posibles problemas relacionados con la interacción entre el valor de caducidad del Inicio de Autoridad (SOA) de la zona raíz y los períodos de validez de firma de la zona raíz existentes, y recomienda que los mismos sean tratados por la comunidad de Operaciones del DNS (Sistema de Nombres de Dominio). En particular, el RSSAC recomienda que los asociados de la Gestión de la Zona Raíz aumenten los períodos de validez de las firmas, para las firmas generadas por la Clave para la firma de la llave de la zona raíz (ambas KSK y ZSK). La validez de la firma KSK debe ser aumentada a al menos 21 días. La validez de la firma ZSK debe ser aumentada a al menos 13 días.

      Las condiciones bajo las cuales ocurren problemas de validez de la firma son muy raras, no se han producido hasta la fecha y es poco probable que afecten a los usuarios finales en este momento. Por lo tanto, el RSSAC cree que esta cuestión no es urgente y que se debe abordar dentro de un período de tiempo razonable después de una actualización de los documentos de procedimientos necesarios y pruebas de software.

      Tras recibir el documento RSSAC003, el personal de la ICANN realizó un análisis de factibilidad y costos para la implementación de la recomendación de KSK del documento RSSAC y creó un plan de implementación de KSK con cronogramas e hitos de alto nivel, para que sea examinado por la Junta Directiva.

      La Junta Directiva ha considerado el asesoramiento del RSSAC en el documento RSSAC003, además de la viabilidad y los costos de implementación del asesoramiento relativo a la KSK, y adopta el asesoramiento del RSSAC para la validez de la firma KSK, presentado en el documento RSSAC003. La Junta Directiva también encomienda a la ICANN continuar con la implementación de las recomendaciones de KSK presentadas en el documento RSSAC003, en colaboración con los asociados de la Gestión de la Zona Raíz.

      Esta es una cuestión operativa que no requiere de comentarios públicos. No se prevé ningún impacto fiscal. La aprobación e implementación de la recomendación del RSSAC mejorará la seguridad, la estabilidad y flexibilidad del sistema de nombres de dominio.

      La Junta Directiva entiende que la NTIA (Administración Nacional de Telecomunicaciones e Información de los Estados Unidos) ya ha acordado con Verisign, como entidad encargada del mantenimiento de la Zona Raíz, que Verisign debe cambiar el período de validez de la firma para la ZSK, y que el trabajo está programado para realizarse en septiembre de 2016.

    2. Delegación del dominio .বাংলা ("bangla") en representación de Bangladesh en código de escritura bengalí

      Resuélvase (2016.09.15.02): Como parte del ejercicio de sus responsabilidades conforme al Contrato de Funciones de la IANA (Autoridad de Números Asignados en Internet), la ICANN ha examinado y evaluado la solicitud de delegación del dominio de alto nivel con código de país .বাংলা al Ministerio de Correos, Telecomunicaciones y Tecnologías de la Información de la División de Correos y Telecomunicaciones de Bangladesh. La documentación demuestra que se siguieron los procedimientos adecuados durante la evaluación de la solicitud.

      Resuélvase (2016.09.15.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.

      Fundamento de las resoluciones 2016.09.15.02 – 2016.09.15.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 se está considerando?

      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 Ministerio de Correos, Telecomunicaciones y Tecnologías de la Información de la División de Correos y Telecomunicaciones de Bangladesh.

      ¿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 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 comentario público.

    3. Contratación de la sede y emplazamiento para la reunión de la ICANN de octubre de 2018

      Visto y considerando: Que la ICANN tiene la intención de realizar su tercera reunión pública de 2018 en la región de Europa.

      Visto y considerando: Que el personal ha realizado una revisión exhaustiva de todas las sedes propuestas en Europa y considera que la de Barcelona, España, es la más adecuada.

      Resuélvase (2016.09.15.04): La Junta Directiva autoriza al Presidente y Director Ejecutivo, o a quien éste designe, a realizar y facilitar todas las contrataciones y desembolsos que se requieran para el centro de convenciones de la reunión pública de la ICANN que se realizará en octubre de 2018 en Barcelona, España, hasta un monto máximo de [MONTO OMITIDO POR MOTIVOS DE NEGOCIACIÓN], y que la reunión pública de la ICANN de octubre de 2018 sea designada Reunión General Anual de 2018.

      Resuélvase (2016.09.15.05): Algunos puntos específicos de esta resolución tendrán carácter confidencial por motivos de negociación, conforme al Artículo III, Sección 5.2 de los Estatutos de la ICANN, hasta que el Presidente y Director Ejecutivo determine que la información confidencial puede publicarse.

      Fundamento de las resoluciones 2016.09.15.04 – 2016.09.15.05

      Como parte de su calendario de reuniones públicas, la ICANN actualmente celebra tres reuniones al año en distintas regiones geográficas (de conformidad con lo establecido en los Estatutos de la ICANN). La reunión N.º 63 de la ICANN, programada para el 20 al 26 de octubre de 2017, se celebrará en la región geográfica de Europa. El 23 de marzo de 2015, se publicó una convocatoria para recomendar sedes para la reunión a realizarse en Europa. La ICANN recibió diversas propuestas. El personal realizó un análisis exhaustivo de todas las propuestas, así como también de otras sedes, y preparó un documento para identificar aquellas que cumplían con los criterios de selección para reuniones (véase https://meetings.icann.org/en/host). En función de las propuestas y el análisis, la ICANN ha seleccionado la ciudad de Barcelona, España, como sede de la reunión ICANN63.

      La Junta Directiva examinó la información presentada por el personal para celebrar la reunión pública de la ICANN de octubre de 2018 en Barcelona, España; la determinación que indica que la propuesta cumple con los factores significativos de los criterios de selección para reuniones; y los costos relacionados con las instalaciones seleccionadas.

      Habrá un impacto financiero sobre la ICANN basado en la celebración de la reunión y el suministro de apoyo para viajes, según sea necesario, así también sobre la comunidad, al incurrir en los gastos de viaje para asistir a la reunión. Sin embargo, dicho impacto hubiese existido independientemente de la sede seleccionada para la reunión. Esta acción no tendrá impacto alguno sobre la seguridad o la estabilidad del DNS.

      La Junta Directiva agradece a todos aquellos que recomendaron sedes para la reunión N.º 63 de la ICANN.

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

    4. Designación del presidente y presidente electo del Comité de Nominaciones de 2017

      Visto y considerando: Que el BGC (Comité de Gobernanza de la Junta Directiva) analizó las Expresiones de Interés de los candidatos para presidente y presidente electo del Comité de Nominaciones 2017 ("NomCom"), consideró los resultados de la evaluación de 360 grados del liderazgo del NomCom 2016 y entrevistó a los candidatos.

      Visto y considerando: Que el BGC ha recomendado la designación de Hans Petter Holen como Presidente del NomCom para el año 2017, y la designación de Zahid Jamil como Presidente Electo del NomCom para el año 2017.

      Resuélvase (2016.09.15.06): Por la presente, la Junta Directiva designa a Hans Petter Holen como el Presidente del Comité de Nominaciones de 2017 y a Zahid Jamil como el Presidente Electo del Comité de Nominaciones de 2017.

      Fundamento de la resolución 2016.09.15.06

      De acuerdo con los Estatutos de la ICANN, la Junta Directiva debe designar al presidente y al presidente electo del NomCom. Véase 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 la carta orgánica del BGC en http://www.icann.org/en/committees/board-governance/charter.htm. El 24 de mayo de 2016, el BGC publicó una convocatoria de Manifestaciones de Interés (EOI) a ser presentadas antes del 10 de junio de 2016 (véase (https://www.icann.org/news/announcement-2016-05-24-enn). La convocatoria para EOI fue luego extendida hasta el día 30 de julio de 2016 (véase https://www.icann.org/news/announcement-2016-06-10-en). Antes de hacer sus recomendaciones, el BGC recibió y examinó varias EOI, supervisó una evaluación de 360 grados del liderazgo del NomCom 2016 y entrevistó a los candidatos. La Junta Directiva ha sometido a consideración la recomendación del BGC respecto del presidente y presidente electo para el NomCom 2017 y está de acuerdo con ella. Asimismo, la Junta Directiva desea agradecer a todos quienes manifestaron su interés en formar parte del liderazgo de NomCom 2017.

      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 tendrá ningún impacto económico en la ICANN que no haya sido ya previsto, y no se observarán impactos negativos en la seguridad, estabilidad o flexibilidad del sistema de nombres de dominio.

  2. Orden del día principal:

    1. Contrato de Funciones de nombres de la IANA entre la ICANN y PTI

      Visto y considerando: Que la finalización del Contrato de las Funciones de Nombres <https://www.icann.org/en/system/files/files/proposed-iana-naming-function-agreement-10aug16-en.pdf> [PDF, 283 KB] cumple un requisito del paquete de propuestas que la Junta Directiva aprobó el 10 de marzo de 2016 para la transición de la custodia de las funciones de la IANA por parte de la NTIA hacia la comunidad mundial de múltiples partes interesadas.

      Visto y considerando: Que el Contrato de las Funciones de la IANA fue redactado para cumplir con los requisitos de la Propuesta para la Transición de la Custodia de la IANA del Grupo de Coordinación de la Transición de la Custodia de las Funciones de la IANA.

      Visto y considerando: Que a través del Contrato de las Funciones de Nombres, la ICANN contratará a Identificadores Técnicos Públicos (PTI) para desempeñarse como operador de las Funciones de Nombres de la IANA y para realizar las funciones de la IANA relacionadas con los nombres.

      Visto y considerando: Que la ICANN solicitó comentarios públicos sobre el Contrato de Funciones de Nombres propuesto, del 10 de agosto de 2016 al 9 de septiembre de 2016 <https://www.icann.org/public-comments/iana-naming-function-agreement-2016-08-10-en>.

      Visto y considerando: Que el foro de comentarios públicos sobre el Contrato de las Funciones de Nombres propuesto cerró el día 9 de septiembre de 2016, y que la ICANN recibió ocho comentarios, tanto por parte de individuos como de organizaciones/grupos. Se proporcionó a la Junta Directiva un resumen y análisis de los comentarios <https://www.icann.org/en/system/files/files/report-comments-iana-naming-function-agreement-15sep16-en.pdf> [PDF, 497 KB].

      Resuélvase (2016.09.15.07): Se aprueba el Contrato de Funciones de Nombres propuesto y se autoriza al Presidente y Director Ejecutivo, o a quien éste designe, a tomar las medidas apropiadas para finalizar e implementar dicho Acuerdo.

      Fundamento de la resolución 2016.09.15.07

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

      La finalización del Contrato de Funciones de Nombres está especificado como uno de los requisitos del paquete de propuestas que la Junta Directiva aprobó el 10 de marzo de 2016 para realizar la transición de la custodia de la función de la IANA por parte de la NTIA a la comunidad global de múltiples partes interesadas. Desde el 15 de julio de 2016, la ICANN ha trabajado con el CWG sobre Custodia (Grupo de Trabajo Intercomunitario para el Desarrollo de una Propuesta para la Transición de la Custodia de las Funciones de la IANA relativas a las Funciones de Nombres) y con sus asesores externos para finalizar el Contrato de Funciones de Nombres. Después de incorporar la retroalimentación inicial del CWG sobre Custodia, el Acuerdo fue publicado por un período de comentario público de 30 días, el 10 de agosto de 2016. El período de comentarios públicos de 30 días finalizó el 9 de septiembre de 2016 y hoy se le solicita a la Junta Directiva considerar el Acuerdo propuesto para su aprobación.

      ¿Cuál es la propuesta que se está considerando?

      El Contrato de Funciones de Nombres propuesto designa a PTI como el operador de las funciones de nombres de la IANA y autoriza a PTI a realizar las funciones de nombres de la IANA. El Acuerdo incluye Expectativas de Nivel de Servicio para el desempeño de las funciones de nombres de la IANA, las cuales fueron acordadas entre la ICANN y el CWG sobre Custodia. El Acuerdo sólo entrará en vigencia tras la finalización exitosa de la transición de la custodia de la IANA.

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

      La ICANN realizó un período de comentarios públicos sobre el Contrato de Funciones de Nombres propuesto, entre el 10 de agosto de 2016 y el 9 de septiembre de 2016. La ICANN también trabajó en estrecha colaboración con el CWG sobre Custodia y con sus asesores externos para atender cualquier inquietud. Tras el período de comentario público, los comentarios fueron resumidos y analizados.

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

      Hubo dos preocupaciones importantes planteadas durante el proceso de revisión del CWG sobre Custodia.

      La primera preocupación fue planteada por algunos en la comunidad de ccTLD y estaba relacionada con las políticas aplicables para la gestión de zonas raíz de los ccTLD. Después de consultar con la comunidad de ccTLD y los miembros del GAC que participaron en las deliberaciones del CWG sobre Custodia, el Acuerdo fue actualizado para reflejar que las políticas aplicables incluyen: (1) Aquellas definidas por la ccNSO; y (2) el RFC 1591 ("Estructura y Delegación del Sistema de Nombres de Dominio") según lo interpretado por el Marco de Interpretación de Políticas y Directrices Actuales relativas a la Delegación y Redelegación de Nombres de Dominio de Alto Nivel con Código de País, del mes de octubre de 2014. Además de estas políticas, cuando sea apropiado, PTI consultará los Principios y Directrices del Comité Asesor Gubernamental de 2005 para la Delegación y Administración de Dominios de Alto Nivel con Código de País.

      La segunda preocupación, también planteada por algunos en la comunidad de ccTLD, fue que los ccTLD que no tienen contratos con la ICANN "no desean nombrar a la ICANN a cargo de sus entradas en la zona raíz" y esto debería reflejarse en el Acuerdo. La ICANN señaló que en la Propuesta, el CWG sobre Custodia de hecho espera que los roles de la ICANN y de la entidad encargada del mantenimiento de la Zona Raíz no cambien después de la transición. El párrafo 1158 de la propuesta del CWG sobre Custodia establece:

      Actualmente, la actualización de la Zona Raíz requiere la participación activa de tres partes: la IFO (entidad operadora de las funciones de la IANA), la entidad encargada del mantenimiento de la Zona Raíz y la NTIA. La IFO recibe las solicitudes de cambio por parte de varias fuentes, las valida y las envía a la entidad encargada del mantenimiento de la Zona Raíz quien, una vez recibida la autorización por parte de la NTIA, actualiza el archivo de zona raíz, firma las DNSSEC y las distribuye a los operadores de raíz.

      Después de la transición sólo estarán la IFO y la entidad encargada del mantenimiento de la Zona Raíz. En este momento, el CWG sobre Custodia no recomienda ningún cambio en las funciones realizadas por estos dos roles. El CWG sobre Custodia recomienda que deben haber propuestas para realizar cambios en los roles asociados con la modificación de la Zona Raíz, que dichas propuestas deben ser objeto de una consulta con la comunidad más amplia.

      ¿Qué materiales significativos analizó la Junta Directiva?

      Como parte de sus deliberaciones, la Junta Directiva analizó diversos materiales, incluidos, entre otros, los siguientes materiales y documentos:

      ¿Qué factores la Junta Directiva consideró significativos?

      La Junta Directiva consideró en qué medida se incorporaron los comentarios públicos al Contrato de Funciones de Nombres propuesto. Especialmente significativa es la participación del CWG sobre Custodia y la dependencia en los abogados externos en cuanto a la revisión e identificación de cambios adicionales al Contrato de Funciones de Nombres. El acuerdo de la ICANN para asumir las modificaciones generadas a través del CWG sobre Custodia ayuda a asegurar la continua coherencia con la Propuesta de Transición de la custodia de la IANA. La Junta Directiva también consideró los términos del Acuerdo para asegurar que la función de nombres de la IANA continuará siendo desempeñada de una manera segura, estable y confiable que satisfaga las necesidades de los clientes.

      ¿Existen impactos positivos o negativos para la comunidad?

      El Contrato de Funciones de Nombres propuesto establece los requisitos y obligaciones para que PTI realice la Función de Nombres de la IANA de una manera segura, estable y confiable. El Acuerdo también incluye Expectativas de Nivel de Servicio para el desempeño de la Función de Nombres de la IANA. La aprobación del Acuerdo propuesto por parte de la Junta Directiva cumplirá uno de los requisitos principales de la propuesta desarrollada por la comunidad para la transición de la custodia de la IANA, aprobada por la Junta Directiva el 10 de marzo de 2016, y asegurará que la Función de Nombres de la IANA continúe funcionando de manera segura, estable y fiable, satisfaciendo las necesidades de los clientes.

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

      No se espera ningún impacto fiscal significativo como consecuencia de la aprobación del Contrato de Funciones de Nombres por parte de la Junta Directiva. La ICANN proporcionará los servicios necesarios a PTI para que cumpla con las obligaciones en virtud del presente Acuerdo propuesto. Estos servicios y costos asociados se encuentran especificados en un Acuerdo de Servicios separado entre la ICANN y PTI.

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

      La aprobación del Contrato de Funciones de Nombres por parte de la Junta Directiva aseguraría el funcionamiento continuo de la función de nombres de la IANA de manera segura, estable y fiable, después de la transición.

    2. Acuerdo de Servicios entre la ICANN y PTI

      Visto y considerando: Que la finalización del Acuerdo de Servicios <https://www.icann.org/iana_imp_docs/111-services-agreement-v-14sep16> [DOCX, 47 KB] cumple un requisito del paquete de propuestas que la Junta Directiva aprobó el 10 de marzo de 2016 para la transición de la custodia de las funciones de la IANA por parte de la NTIA hacia la comunidad mundial de múltiples partes interesadas.

      Visto y considerando: Que el Acuerdo de Servicios fue redactado para cumplir con los requisitos de la Propuesta de Transición de la custodia de la IANA del Grupo de Coordinación de la Transición de la Custodia de las Funciones de la IANA, y las obligaciones que la ICANN tiene en virtud del Contrato de Funciones de Nombres.

      Visto y considerando: Que la ICANN consultó con el CWG sobre Custodia, su asesor externo, el IETF (Grupo de Trabajo en Ingeniería de Internet) y los RIR (Registros Regionales de Internet) para abordar cualquier inquietud y finalizar el Acuerdo.

      Resuélvase (2016.09.15.08): Se aprueba el Acuerdo de Servicios propuesto y se autoriza al Presidente y Director Ejecutivo, o a quien éste designe, a tomar las medidas apropiadas para finalizar e implementar dicho Acuerdo.

      Fundamento de la resolución 2016.09.15.08

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

      El paquete de propuestas que la Junta Directiva aprobó el 10 de marzo de 2016 para la transición de la custodia de las funciones de la IANA por parte de la NTIA hacia la comunidad mundial de múltiples partes interesadas, requiere que la ICANN proporcione los servicios y recursos necesarios a PTI para que dicha entidad desempeñe las funciones de la IANA. Este requisito se incluye en el Contrato de Funciones de Nombres entre la ICANN y PTI.

      La ICANN ha trabajado intensamente con el CWG sobre Custodia, su asesor externo, el IETF y los RIR para finalizar el Acuerdo de Servicios que hoy se presenta a la Junta Directiva para su consideración y aprobación.

      ¿Cuál es la propuesta que se está considerando?

      El Acuerdo compromete a la ICANN a proporcionar los servicios y recursos necesarios a PTI para que dicha entidad desempeñe las funciones de la IANA.

      Los recursos dedicados incluyen a los empleados actuales del departamento de IANA de la ICANN, quienes desempeñan los servicios de las funciones de la IANA en forma directa. Los recursos compartidos incluyen empleados de otros departamentos de la ICANN, quienes llevan a cabo o participan en procesos directamente relacionados con la entrega de las funciones de la IANA. Los servicios de apoyo incluyen servicios proporcionados por los departamentos de la ICANN para apoyar las operaciones de PTI (por ejemplo, Recursos Humanos, Finanzas, Compras, etc.).

      Todos los servicios y recursos proporcionados a PTI serán facturados al costo por la ICANN a PTI. PTI también será financiada total y exclusivamente por la ICANN. Se estima que el ámbito de alcance de los servicios representará un costo anual de USD9 millones (utilizando como base el presupuesto del año fiscal 2017).

      En lo que se refiere a los recursos dedicados, el Acuerdo establece que los empleados de la ICANN que actualmente se desempeñan en el departamento de la IANA serán secundados por PTI. El Acuerdo también establece el compromiso de que, dentro de los tres (3) años de la fecha de entrada en vigor del Acuerdo, PTI contará con los programas, procesos y políticas necesarios para ofrecer empleo a tiempo completo a dichos empleados secundados. En el caso de que PTI ofrezca facilitar ese cambio de empleo.

      En virtud del Acuerdo, la ICANN realizará esfuerzos razonables para suministrar servicios tales como contabilidad, comunicaciones y recursos humanos, establecidos por la ICANN para sus propias operaciones. El Acuerdo permite a la ICANN cambiar, suspender o rescindir el suministro de un servicio, siempre y cuando el cambio, suspensión o rescisión no genere ningún riesgo material para la seguridad y estabilidad del sistema de nombres de dominio. Por ejemplo, si la ICANN hace un cambio en sus ofertas de cobertura dental, las ofertas de cobertura dental disponibles para aquellos que trabajan con PTI se harán compatibles con la cobertura cambiada.

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

      Dado que el Acuerdo constituye un compromiso detallado y operativo con respecto a los servicios y recursos específicos necesarios para apoyar a PTI, no fue factible solicitar comentarios públicos sobre el documento. Sin embargo, la ICANN consultó con el IETF y los RIR para abordar cualquier inquietud, y trabajó intensamente con el CWG sobre Custodia y su asesor externo para finalizar el Acuerdo.

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

      La comunidad no planteó cuestiones importantes, ya que la mayoría de las cuestiones fueron de naturaleza jurídica acerca de que los términos fuesen reflejados adecuadamente.

      ¿Qué materiales significativos analizó la Junta Directiva?

      Como parte de sus deliberaciones, la Junta Directiva analizó diversos materiales, incluidos, entre otros, los siguientes materiales y documentos:

      ¿Qué factores la Junta Directiva consideró significativos?

      La Junta Directiva consideró que los requisitos del Acuerdo fuesen coherentes con los procesos de planificación financiera de la ICANN y que el Acuerdo proporcione a PTI los recursos necesarios para desempeñar las funciones de la IANA.

      ¿Existen impactos positivos o negativos para la comunidad?

      El Acuerdo asegura que PTI contará con los recursos necesarios para realizar las funciones de la IANA para las comunidades de nombres, números y parámetros de protocolo.

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

      Los servicios serán facturados al costo por la ICANN a PTI que, a su vez, es una entidad total y exclusivamente financiada por la ICANN. Se estima que el ámbito de alcance de los servicios representará un costo anual de USD9 millones (utilizando como base el presupuesto del año fiscal 2017 de la ICANN, aprobado por la Junta Directiva <https://www.icann.org/resources/board-material/resolutions-2016-06-25-en#2.c).

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

      La aprobación del Acuerdo de Servicios propuesto por parte de la Junta Directiva aseguraría que PTI cuente con los recursos necesarios para continuar con el funcionamiento continuo de las funciones de nombres de la IANA de manera segura, estable y confiable, después de la transición.

    3. Enmienda al Acuerdo de Registro de .COM

      Visto y considerando: Que la ICANN y Verisign participaron en deliberaciones sobre una enmienda propuesta al Acuerdo de Registro .COM ("Enmienda") del 1 de diciembre de 2012 y acordaron prorrogar el término del Acuerdo hasta el 30 de noviembre de 2024, para que coincida con el término del Acuerdo de Servicios de la entidad encargada del mantenimiento de la Zona Raíz, con el fin de mejorar la seguridad, la estabilidad y la flexibilidad de las operaciones de la zona de raíz.

      Visto y considerando: Que la Enmienda propuesta también requiere que Verisign y la ICANN cooperen y negocien de buena fe para: (1) enmendar el Acuerdo de Registro de .COM antes del segundo aniversario de la Enmienda propuesta, a fin de preservar y mejorar la seguridad de Internet o del Dominio de Alto Nivel (TLD); y (2) según sea necesario para la coherencia con los cambios en el Acuerdo de Cooperación entre Verisign y el Departamento de Comercio de los Estados Unidos. Todos los demás términos y condiciones del Acuerdo de Registro existente permanecen sin cambios.

      Visto y considerando: Que la ICANN abrió un período de comentario público desde el 30 de junio de 2016 hasta el 12 de agosto de 2016 <https://www.icann.org/public-comments/com-amendment-2016-06-30-en> sobre el Acuerdo propuesto. Noventa y nueve (99) comentarios fueron presentados por individuos y organizaciones/grupos.

      Visto y considerando: Que la Junta Directiva examinó cuidadosamente los comentarios y el resumen y análisis de los comentarios realizado por parte del personal.

      Visto y considerando: Que la ICANN llevó a cabo una revisión del desempeño reciente de Verisign en virtud del actual Acuerdo de Registro de .COM, y encontró que Verisign cumplía sustancialmente con sus requisitos contractuales.

      Resuélvase (2016.09.15.09): la enmienda propuesta al Acuerdo de Registro de .COM <https://www.icann.org/sites/default/files/tlds/com/com-amend-1-pdf-30jun16-en.pdf> [PDF, 100 KB] es aprobada, con sujeción a la implementación del RZMA (Acuerdo de Servicios de Mantenimiento de la Zona Raíz), y se autoriza al Presidente y Director Ejecutivo, o a quien éste designe, a tomar dichas medidas según corresponda para finalizar y ejecutar el Acuerdo.

      Fundamento de la resolución 2016.09.15.09

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

      El 1 de diciembre de 2012, la ICANN y VeriSign, Inc. firmaron un Acuerdo de Registro en virtud del cual VeriSign, Inc. gestiona el dominio de alto nivel .COM. El acuerdo actual vence el día 30 de noviembre de 2018. La ICANN y Verisign han negociado una Enmienda propuesta, la cual fue publicada para comentario público de la ICANN por un período de 42 días, entre el 30 de junio de 2016 y el 12 de agosto de 2016. En este momento, la Junta Directiva está aprobando la Enmienda propuesta para la continuidad de gestión del TLD .COM por parte de Verisign.

      ¿Cuál es la propuesta que se está considerando?

      La Enmienda propuesta: (1) extiende el plazo del Acuerdo de Registro de .COM al 30 de noviembre de 2024 para que coincida con el término del Acuerdo de Servicios de Mantenimiento de la Zona Raíz (RZMA) entre la ICANN y Verisign; (2) compromete a Verisign y a la ICANN a cooperar y negociar de buena fe para enmendar el Acuerdo de Registro de .COM antes del segundo aniversario de la Enmienda propuesta a fin de preservar y mejorar la seguridad de Internet o del TLD; (3) compromete a Verisign y a la ICANN a cooperar y negociar de buena fe para enmendar los términos del Acuerdo de Registro de .COM que sean necesarios para la coherencia con los cambios en el Acuerdo de Cooperación entre Verisign y el Departamento de Comercio de los Estados Unidos. Todos los demás términos y condiciones del Acuerdo de Registro existente permanecen sin cambios.

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

      La ICANN inició negociaciones bilaterales con Verisign para acordar los términos de la Enmienda propuesta. La Enmienda propuesta fue luego publicada para comentario público, entre el 30 de junio de 2016 y el 12 de agosto de 2016. Luego del período de comentario público, los comentarios fueron resumidos y analizados.

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

      Hubo 99 comentarios presentados por individuos y grupos/organizaciones durante el período de comentario público de 42 días. Algunos comentarios en general apoyaron la Enmienda propuesta mientras que otros plantearon preocupaciones. A continuación se proporciona un resumen y análisis de los comentarios, los cuales también se encuentran publicados en y también se publican en <https://www.icann.org/en/system/files/files/report-comments-com-amendment-09sep16-en.pdf> [PDF, 200 KB].

      ¿Qué materiales significativos analizó la Junta Directiva?

      Como parte de sus deliberaciones, la Junta Directiva analizó diversos materiales, incluidos, entre otros, los siguientes materiales y documentos:

      ¿Qué factores la Junta Directiva consideró significativos?

      La Junta Directiva examinó cuidadosamente los comentarios públicos recibidos sobre la Enmienda propuesta, junto con el resumen y análisis de esos comentarios.

      La Junta Directiva reconoce que algunos comentarios en general apoyaron la Enmienda propuesta, y algunos expresaron su apoyo general, pero también pidieron a la ICANN y/o a Verisign clarificar la relación del Acuerdo de Cooperación y la Enmienda propuesta, particularmente en torno al precio y las disposiciones o temas que serían objeto de negociaciones de buena fe antes del segundo aniversario de la fecha de entrada en vigor de la enmienda propuesta.

      Si bien la Junta Directiva reconoce los cambios sugeridos en la Enmienda propuesta para especificar qué disposiciones se discutirán en el segundo aniversario de la Enmienda propuesta, la Junta Directiva señala que el texto redactado en la versión preliminar de la Enmienda propuesta logra el equilibrio de un compromiso a entablar negociaciones, a la vez que proporciona un margen de flexibilidad para considerar temas futuros relacionados con la preservación y la mejora de la seguridad y la estabilidad de Internet o del TLD en este panorama cambiante.

      Con respecto a la revisión de la Enmienda propuesta para tener en cuenta posibles cambios o la cancelación del Acuerdo de Cooperación entre Verisign y el Departamento de Comercio, la Junta Directiva señala que la Enmienda propuesta ya tiene en cuenta el Acuerdo de Cooperación. La Enmienda propuesta incluye texto que exige a la ICANN y a Verisign emprender negociaciones de buena fe para realizar cambios al Acuerdo de Registro de .COM, conforme sea necesario a los fines de mantener la coherencia con los cambios o la rescisión o expiración del Acuerdo de Cooperación.

      La Junta Directiva también reconoce que se han presentado varios comentarios relacionados con los precios de los nombres de dominio .COM. Algunos comentarios sugirieron que el tope de precios actual establecido en el Acuerdo de Registro debe permanecer en vigor, mientras que otros recomendaron que los precios deben ser reducidos. La Junta Directiva señala que la Sección 7.3(d) del Acuerdo de Registro de .COM especifica el precio máximo que Verisign puede cobrar por los servicios de registro. La Enmienda propuesta no modifica esta disposición.

      La Junta Directiva también reconoce los comentarios presentados en oposición a la presunta disposición del derecho de renovación en el Acuerdo de Registro de .COM y las sugerencias de que el presunto derecho de renovación debería ser eliminado en caso de ocurrir ciertos eventos, tal como un incumplimiento sustancial al Acuerdo de Registro que no fuese subsanado. Otros sugirieron que en lugar de extender el Contrato de Registro de .COM, se debía establecer una licitación pública competitiva del mismo, a fin de asegurar el cobro de los precios más bajos a los Registratarios. La Junta Directiva señala que el presunto derecho de renovación establecido en la Sección 4.2 del Contrato de Registro de .COM constituye una disposición que está en todos los Acuerdos de Registro de la ICANN. La disposición permite a un Operador de Registro el derecho de renovar el Acuerdo al momento de su vencimiento, siempre y cuando el Operador de Registro se encuentre en regla al momento de la renovación, conforme lo establecido en los términos de la presunta disposición de renovación. Esta presunta disposición de renovación está en vigor para garantizar la estabilidad, la seguridad y la fiabilidad en el funcionamiento del TLD, es decir, para fomentar la inversión a largo plazo en operaciones sólidas del TLD. Esto ha servido al interés público al fomentar la inversión en la infraestructura del Registro de TLD y mejoras en la fiabilidad de las operaciones del TLD. La ICANN ha descrito previamente los fundamentos para la presunta renovación de los Registros: "A falta de razones compensatorias, en los cambios regulares de un Operador de Registro existe poco beneficio público y un significativo potencial de interrupción. Además, una posibilidad significativa de perder el derecho a administrar el Registro tras un breve período de tiempo crea incentivos adversos para favorecer la ganancia a corto plazo sobre la inversión a largo plazo. Por otro lado, la comunidad, actuando a través de la ICANN, debe tener la capacidad de reemplazar a un Operador de Registro que no está brindando un servicio adecuado a la comunidad al administrar un Registro".

      La Junta Directiva reconoce los comentarios de que el Acuerdo de Registro de .COM debe ajustarse a las nuevas salvaguardias y protecciones de propiedad intelectual que se encuentran en el Acuerdo de Registro de Nuevos gTLD. Algunos comentarios señalaron que ciertos Operadores de Registro de gTLD legados han adoptado la forma general del Acuerdo de Registro de Nuevos gTLD (por ejemplo, .PRO, .CAT, .TRAVEL), incluyendo las mejoras y salvaguardas adicionales, y que se debería requerir que .COM haga lo mismo. Algunos sugirieron que no requerir que .COM esté sujeto a las nuevas mejoras, salvaguardias y protecciones de propiedad intelectual establecidas en el Acuerdo de Registro de Nuevos gTLD plantea preocupaciones sobre si la ICANN se adhiere a sus valores fundamentales relacionados con el trato no discriminatorio o preferencial, en servicio al interés público, la transparencia y la competencia. La Junta Directiva señala que la Enmienda propuesta publicada para comentario público es una simple extensión del término de acuerdo vigente, y que el cambio hacia la forma del Acuerdo de Registro de Nuevos gTLD requeriría una discusión y una consulta de la comunidad más extensas. La propuesta de una Enmienda sencilla en este momento, para extender el plazo del Acuerdo de Registro de .COM, tiene por objeto que las operaciones del TLD .COM se mantengan estables, seguras y confiables.

      La Junta Directiva también señala que la Enmienda propuesta contiene una disposición que compromete a la ICANN y a Verisign a cooperar y negociar de buena fe para enmendar el Acuerdo de Registro de .COM antes del segundo aniversario de la Enmienda propuesta, a los fines de preservar y mejorar la seguridad de Internet o del TLD. Este texto fue negociado para ofrecer una oportunidad de futuras deliberaciones que pueden ser necesarias para discutir posibles cambios hacia la preservación y mejora de la seguridad de Internet o del TLD .COM.

      La Junta Directiva reconoce los comentarios que solicitan la confirmación de que Verisign deberá implementar políticas de consenso desarrolladas en el futuro que puedan suministrar salvaguardias y mejoras adicionales. La Junta Directiva señala que la Sección 3.1 (b) del Acuerdo de Registro de .COM establece que: "En todo momento durante la vigencia de este Acuerdo y sujeto a los términos del mismo, el Operador de Registro cumplirá e implementará todas las Políticas de Consenso encontradas en http://www.icann.org/en/general/consensus-policies.htm, a partir de la fecha de entrada en vigencia y que en el futuro se puedan desarrollar y adoptar de conformidad con los Estatutos de la ICANN y tal como se establece a continuación".

      La Junta Directiva reconoce los comentarios que se opusieron a la renovación anticipada del Acuerdo de Registro de .COM y la vinculación con el Acuerdo de Servicios de Mantenimiento de Zona Raíz (RZMA). Estos comentarios señalaron que la infraestructura de mantenimiento de la zona raíz nunca debería haber estado "inextricablemente entrelazada" con las operaciones de .COM de Verisign. Algunos cuestionaron cómo la vinculación de los dos acuerdos mejoraría la seguridad, la estabilidad y la flexibilidad de las operaciones de la raíz y argumentaron que la vinculación representa una sola fuente de fracaso. Estos comentarios instaron al personal técnico de la ICANN a comenzar a explorar cómo podría lograrse alguna separación práctica entre la zona de raíz y las operaciones técnicas de .COM si esa eventualidad se plantea y asegurar que tal acción no represente una amenaza para la seguridad y estabilidad del DNS.

      La Junta Directiva señala que Verisign ha estado suministrando "servicios de registro" en virtud de su Acuerdo Cooperativo con la NTIA por muchos años, el cual fue ampliamente definido para incluir funciones como entidad encargada del mantenimiento de la zona raíz y servicios de registro del dominio de alto nivel .COM. Dada la naturaleza unificada de estas dos funciones bajo el Acuerdo Cooperativo, gran parte de la infraestructura que apoya la función como entidad encargada del mantenimiento de la zona raíz está "entrelazada" con las operaciones del TLD de Verisign para .COM. Un factor clave para garantizar la seguridad de las operaciones de la zona raíz fue asegurar que dichas operaciones continúen contando con el beneficio de su relación histórica con las operaciones del dominio .COM. Ello se pudo lograr mediante la simple ampliación del plazo de vigencia del Acuerdo de Registro de .com propuesto, a fin de que coincida con el plazo de vigencia del nuevo RZMA. Si bien los términos de los acuerdos están vinculados entre sí en el sentido de que expiran al mismo tiempo, los acuerdos no contienen ninguna disposición que vincule el desempeño de las obligaciones en virtud del Acuerdo de Registro de .COM, con las obligaciones en virtud del RZMA. De hecho, el Acuerdo de Servicios de Mantenimiento de la Zona Raíz ("RZMA"), aprobado por la Junta Directiva de la ICANN el 9 de agosto de 2016, incluye disposiciones que proveen a la comunidad la capacidad ―a través de un proceso basado en consenso y liderado por la comunidad― de requerir a la ICANN la transición de la función de mantenimiento de la zona raíz a otro proveedor de servicios, tres años después de la entrada en vigencia del acuerdo.

      La Junta Directiva reconoce los comentarios que sugieren que no requerir que .COM esté sujeto a las nuevas mejoras, salvaguardias y protecciones de propiedad intelectual establecidas en el Acuerdo de Registro de Nuevos gTLD plantea preocupaciones sobre si la ICANN se adhiere a sus valores fundamentales relacionados con el trato no discriminatorio o preferencial, en servicio al interés público, la transparencia y la competencia.

      La Junta Directiva señala que los Estatutos enumeran los valores fundamentales que deben guiar las decisiones y acciones de la ICANN en el desempeño de su misión, y la ICANN toma seriamente su compromiso con esos valores. Conforme lo establecido en los Estatutos, los "valores fundamentales se expresan deliberadamente en términos muy generales, a fin de brindar una guía útil y relevante en la más amplia gama posible de circunstancias. Dado que no son estrechamente prescriptivos, la forma específica en que se aplicarán, individual o colectivamente, a cada nueva situación dependerá necesariamente de muchos factores que no pueden anticiparse ni enumerarse de forma completa; y dado que son declaraciones de principios y no prácticas, surgirán inevitablemente situaciones en las que no será posible alcanzar una fidelidad exacta con los once valores fundamentales de forma simultánea. Cualquier organismo de la ICANN que efectúe una recomendación o tome una decisión deberá poner en práctica su propio juicio a fin de determinar los valores fundamentales más relevantes y cómo aplicarlos a las circunstancias específicas del caso en cuestión, y determinar, de ser necesario, un equilibrio adecuado y justificable entre los valores encontrados. Al examinar los comentarios y la aprobación de la Enmienda propuesta, la Junta Directiva ha tenido en cuenta los valores fundamentales pertinentes para equilibrar las prioridades en competencia.

      Asimismo, la Junta Directiva reconoce los comentarios relativos a las cuestiones de competencia y a brindar igualdad de condiciones. El Artículo II, sección 3 de los Estatutos de la ICANN establece que: "La ICANN no aplicará sus estándares, políticas, procedimientos o prácticas de forma injusta ni tratará a una parte en particular de manera distinta salvo causas justificadas de naturaleza sustancial y razonable, como la promoción de competencia eficaz." La Junta Directiva señala que el Contrato de Registro de .COM contiene muchos términos diferentes que no están presentes en otros acuerdos de Registro. Estos términos únicos pueden considerarse favorables o desfavorables, dependiendo del punto de vista de cada uno. Por ejemplo, la disposición de control de precios de la Sección 7.3 del Acuerdo de Registro de .COM controla estrictamente la capacidad del Operador de Registro para aumentar los precios, de una manera que no está presente en ningún otro Acuerdo de Registro.

      ¿Existen impactos positivos o negativos para la comunidad?

      La ICANN llevó a cabo una revisión del desempeño reciente de Verisign en virtud del actual Acuerdo de Registro de .COM, y encontró que Verisign cumplía sustancialmente con sus requisitos contractuales.

      La aprobación de la Enmienda propuesta por parte de la Junta Directiva tiene por objeto asegurar el funcionamiento estable, seguro y confiable del TLD .COM.

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

      No se espera ningún impacto fiscal significativo como consecuencia de la aprobación de la Enmienda propuesta por parte de la Junta Directiva.

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

      No se espera que la eventual aprobación de la Enmienda propuesta por parte de la Junta Directiva tenga impacto alguno sobre sobre la seguridad, la estabilidad o la flexibilidad del DNS.

    4. Ítems de gobernanza de PTI: Adopción de los Estatutos de PTI. Designación de los Directores de la Junta Directiva Inicial de PTI. Designación del Presidente de PTI

      Estatutos de PTI

      Visto y considerando: Que la aprobación de los estatutos se considera en el mejor interés de PTI, como una Corporación de Beneficio Público sin Fines de Lucro de California.

      Visto y considerando: Que estos Estatutos de PTI iniciales fueron desarrollados en forma coherente con los requerimientos de la Propuesta del ICG, recibida por la Junta Directiva de la ICANN el 10 de marzo de 2016, incluso en forma coordinada con el CWG sobre Custodia y sus asesores externos.

      Visto y considerando: Que los Estatutos de PTI iniciales estuvieron sujetos a un período de comentario público de 30 días, desde el 12 de julio de 2016 hasta el 11 de agosto de 2016, durante el cual se recibieron cuatro comentarios. El personal de la ICANN elaboró un análisis resumido y un informe que identificó la forma en que cada comentario fue considerado y tratado, y la ICANN coordinó las revisiones con el asesor externo del CWG sobre Custodia.

      Visto y considerando: Que el Asesor Letrado General de la ICANN ha afirmado que los Estatutos de PTI propuestos mantienen coherencia con la Propuesta del ICG y recomienda que la ICANN, como miembro único de PTI, proceda con la aprobación.

      Visto y considerando: Que los Estatutos de PTI no entrarán en vigor hasta que sean aprobados, tanto por la Junta Directiva de PTI como por la ICANN como miembro único.

      Resuélvase (2016.09.15.10): La Junta Directiva de la ICANN, en su rol de miembro único de PTI, aprueba los Estatutos disponibles aquí <https://www.icann.org/iana_imp_docs/109-revised-pti-bylaws_18aug16-v-v1> [DOCX, 72 KB] como los Estatutos iniciales para PTI.

      Presidente de PTI

      Visto y considerando: Que, de conformidad con la Sección 7.2 de los Estatutos de PTI, la ICANN como el miembro único está autorizado a nombrar un Presidente de PTI.

      Resuélvase (2016.09.15.11): Por la presente, la Junta Directiva de ICANN, en su calidad de miembro único de PTI, nombra a Elise Gerich como Presidenta de PTI.

      Junta Directiva de PTI - Directores Iniciales

      Visto y considerando: Que la ICANN, en su calidad de miembro único de PTI, tiene la obligación de nombrar a todos los miembros de la Junta Directiva de PTI, de conformidad con el Artículo 5 de los Estatutos de PTI.

      Visto y considerando: Que los Estatutos de PTI, en la Sección 5.2.1, autorizan a la Junta Directiva de PTI a tener cinco Directores.

      Visto y considerando: Que la ICANN, como miembro único de PTI, debe nombrar a cuatro Directores Iniciales a la Junta de PTI; dos Directores Iniciales que sean empleados de la ICANN o de PTI y dos Directores Iniciales que sean candidatos identificados por el Grupo de Trabajo Intercomunitario para el Desarrollo de una Propuesta para la Transición de la Custodia de las Funciones de la IANA relativas a las Funciones de Nombres, de conformidad con la Sección 5.2.2.2 de los Estatutos de PTI.

      Visto y considerando: Que, como miembro único de PTI, la ICANN debe nombrar al Presidente de PTI y a la Junta Directiva de PTI. Elise Gerich ha sido nombrada Presidenta de PTI. La Presidenta del PTI forma parte de la Junta Directiva de PTI en calidad ex officio, con un término de mandato que coincide con su desempeño como Presidenta del PTI.

      Visto y considerando que la ICANN recomienda que Akram Atallah, Presidente de la División Global de Dominios de la ICANN y David Conrad, Director de Tecnologías de la ICANN, sean los dos Directores Iniciales que son empleados de la ICANN o PTI.

      Visto y considerando: Que el CWG sobre Custodia recomienda que Lise Fuhr y Jonathan Robinson actúen como Directores Iniciales.

      Resuélvase (2016.09.15.12): La ICANN, en su calidad de miembro único de PTI, designa a Akram Atallah, David Conrad, Lise Fuhr y Jonathan Robinson como Directores Iniciales del PTI con términos para terminar como se especifica en la Sección 5.5 de los Estatutos de PTI.

      Constituyente

      Visto y considerando: Que el día 9 de agosto de 2016, la Junta Directiva de la ICANN aprobó la presentación de las Actas Constitutivas para Identificadores Técnicos Públicos (o PTI) con el Secretario del Estado de California.

      Visto y considerando: Que para completar esa presentación, la ICANN identificó a Akram Atallah para desempeñarse como el constituyente de PTI a los fines de firmar y archivar las Actas Constitutivas de PTI.

      Visto y considerando: Que los Estatutos de PTI fueron recibidos por el Secretario del Estado de California el 10 de agosto de 2016.

      Visto y considerando que, Akram Atallah no ha tomado otra actuación como constituyente de PTI, y ha presentado una carta de renuncia como el constituyente de PTI.

      Resuélvase (2016.09.15.13): Que cualquier o todas las acciones hasta ahora tomadas por cualquier Funcionario Autorizado para efectuar o evidenciar la intención y el propósito de las resoluciones anteriores sean, y por la presente son, aprobadas, ratificadas y confirmadas como plena voluntad de la Compañía o dicho afiliado y la plena voluntad de la Junta Directiva.

      Resuélvase (2016.09.15.14): La Junta Directiva de la ICANN, en su rol de miembro único de PTI, acepta la renuncia de Akram Atallah como constituyente de PTI, en vigor al momento del nombramiento de los Directores Iniciales de PTI, anteriormente mencionado.

      Fundamento de las resoluciones 2016.09.15.10 – 2016.09.15.14

      Las resoluciones aquí adoptadas cumplen hoy la responsabilidad de la ICANN como miembro único de PTI para permitir que PTI tenga la estructura de gobernanza establecida y esté operativamente preparada para llevar a cabo las actividades requeridas al completarse con éxito la transición de la custodia de la IANA. Con la aceptación de la renuncia del constituyente, la ICANN puede avanzar, de manera transparente y responsable ante su comunidad, con la adopción de los Estatutos de PTI y la designación de la Junta Directiva de PTI (incluso el Presidente de PTI). Esto permitirá a la Junta Directiva de PTI reunirse en un futuro próximo para completar sus actividades organizativas necesarias, las cuales incluirán la aceptación de los Estatutos de PTI, el nombramiento de funcionarios y la adopción de documentos de gobernanza como la Política sobre Conflictos de Interés. La Junta Directiva de PTI también puede determinar cómo delegar autoridad para la aprobación y ejecución de los contratos necesarios para las operaciones de PTI, tales como el Acuerdo de Funciones de Nombres de PTI, el Acuerdo de Servicios con la ICANN y otros acuerdos de subcontratación entre PTI y la ICANN.

      Estas resoluciones no autorizan a PTI a realizar ninguna de las funciones de IANA, antes de que la transición de la custodia de la IANA haya culminado. Este es también un aspecto importante de la responsabilidad.

      Los Estatutos de PTI son el producto del trabajo colectivo de los equipos de asuntos legales internos y externos, junto con el intenso trabajo del CWG sobre Custodia. Los Estatutos de PTI fueron publicados para un período de comentario público de 30 días, durante el cual se recibieron cuatro comentarios. Cada uno de los comentarios fue considerado y analizado, y se brindó una explicación respecto de si era necesario modificar los Estatutos de PTI a fin de reflejar las cuestiones planteadas dentro del comentario. Al modificar los Estatutos de PTI, la ICANN trabajó estrechamente con el CWG sobre Custodia y sus asesores externos, y se hicieron revisiones para asegurar que los directores nombrados por la comunidad para la Junta Directiva de PTI estuviesen siempre presentes en las reuniones de la Junta Directiva de PTI y Comité de la Junta, y fuesen tenidos apropiadamente en cuenta en las decisiones clave que requieren de umbrales más altos que una mayoría simple. Los Estatutos de PTI, tal como se han modificado, siguen siendo coherentes con la Propuesta de transición del ICG. Para entrar en vigencia, los Estatutos de PTI aún deben ser adoptados por la Junta Directiva de PTI.

      El nombramiento del Presidente y la Junta Directiva de PTI se realiza en total conformidad con las obligaciones establecidas en los Estatutos de PTI y respetando las recomendaciones de la comunidad sobre la composición propuesta de la Junta Directiva.

      A la hora de adoptar estas acciones, la Junta Directiva se basó en lo siguiente:

      La Junta Directiva también se basó en la afirmación del Asesor Letrado General y Secretario de que los Estatutos de PTI reflejaban las Propuestas de Transición, así como los aportes del asesor independiente para crear los Estatutos de PTI en respaldo de la Propuesta del ICG.

      Estas acciones continúan confirmando el compromiso de la ICANN para implementar las Propuestas de Transición y todos los elementos contenidos en ellas.

      No se prevé que ninguna de las acciones tomadas hoy tengan impacto alguno sobre la seguridad, estabilidad o flexibilidad del DNS, si bien PTI será esencial para la labor de la ICANN en materia de la seguridad, estabilidad y flexibilidad del DNS. Habrá implicaciones de recursos para el respaldo de la Junta Directiva de PTI, así como los recursos significativos necesarios para apoyar a un nuevo afiliado.

      La aprobación de los Estatutos de PTI constituye una función organizativa y administrativa que ya se ha sometido a comentario público.

      La aceptación de la renuncia del constituyente, el nombramiento del Presidente de PTI y el nombramiento de la Junta Directiva de PTI constituyen funciones organizativas y administrativas que no necesitan de comentario público.

    5. Consideración adicional de la Declaración Final del IRP de Dot Registry

      Visto y considerando: Que, al adoptar las conclusiones de la mayoría del Panel, respecto a que Dot Registry LLC es la parte prevaleciente en el Proceso de Revisión Independiente (IRP) de Dot Registry vs ICANN (IRP de Dot Registry), la Junta Directiva resolvió considerar los próximos pasos en relación con las Solicitudes de Reconsideración de Dot Registry o los nuevos gTLD relevantes antes de tomar nuevas medidas. (Véase https://www.icann.org/resources/board-material/resolutions-2016-08-09-en - 2.g.)

      Visto y considerando: Que la Junta Directiva ha señalado que la mayoría del Panel del IRP de Dot Registry no realizó ninguna recomendación específica a la Junta Directiva en cuanto a los próximos pasos.

      Visto y considerando: Que la Junta Directiva también ha reconocido las diversas correspondencias y aportes recibidos por parte de Dot Registry y otros en relación a este asunto.

      Visto y considerando: Que la mayoría del Panel del IRP de Dot Registry declaró que el Comité de Gobernanza de la Junta Directiva (BGC) actuó de manera inconsistente con las Actas Estatutarias o Estatutos al evaluar las Solicitudes de Reconsideración 14-30, 14-32 y 14-33. (Consulte la Declaración Final, ¶ 151, disponible en https://www.icann.org/en/system/files/files/irp-dot-registry-final-declaration-redacted-29jul16-en.pdf [PDF, 12.9 MB].)

      Visto y considerando: Que, específicamente, la mayoría del Panel declaró que "la Junta Directiva (actuando a través del BGC) no ejerció debida diligencia y cuidado en tener una cantidad razonable de hechos en frente de ella y no cumplió con sus obligaciones de transparencia, entre ellas no haber puesto a disposición la investigación sobre la cual supuestamente EIU y la ICANN se basaron y no haber puesto a disposición del público el trabajo del personal de la ICANN sobre el cual se basó el BGC). La mayoría del Panel concluye además que la evidencia que se le ha presentado no apoya una determinación de que la Junta Directiva (actuando a través del BGC) ejerció una decisión independiente al llegar a las decisiones de reconsideración ". Véase id., at ¶ 152.

      Resuélvase (2016.09.15.15): La Junta Directiva ordena al Comité de Gobernanza de la Junta Directiva que reevalúe las Solicitudes de Reconsideración de Dot Registry 14-30, 14-32 y 14-33, a la luz de la Declaración Final de la mayoría del Panel del IRP de Dot Registry y las cuestiones identificadas en dicha declaración con respecto a las acciones del BGC en la evaluación de estas Solicitudes de Reconsideración.

      Fundamento de la resolución 2016.09.15.15

      Dot Registry, LLC (Dot Registry) inició un procedimiento de Proceso de Revisión Independiente (IRP) mediante el cual objeta la denegación por parte del Comité de Gobernanza de la Junta Directiva (BGC) de las Solicitudes de Reconsideración de Dot Registry en relación con los informes de Evaluación con prioridad de la comunidad (CPE) cuya conclusión fue que las solicitudes de .INC, .LLC y .LLP, respectivamente, por parte de Dot Registry, no prevalecieron en la CPE (IRP de Dot Registry).

      Dot Registry presentó una solicitud para tener la oportunidad de operar los nuevos dominios de alto nivel .LLC, .INC y .LLP. Dot Registry es uno de los nueve solicitantes de .LLC, uno de los once solicitantes de .INC y uno de los cuatro solicitantes de .LLP. Sin embargo, Dot Registry es el único solicitante que presentó solicitudes basadas en la comunidad de estos gTLD.

      Los paneles de CPE que evaluaron las solicitudes de Dot Registry (Paneles de CPE) determinaron que las solicitudes no cumplían con los criterios requeridos para prevalecer en la CPE, otorgando solo cinco de los 14 puntos necesarios para prevalecer en la CPE (Informes de CPE). Dot Registry presentó las Solicitudes de Reconsideración 14-30, 14-32 y 14-33, en las cuales solicitaba la reconsideración de los Informes de CPE. El 24 de julio de 2014, el Comité de Gobernanza de la Junta Directiva (BGC) denegó las Solicitudes de Reconsideración, concluyendo que Dot Registry “no había demostrado que los Paneles actuaron en contravención del procedimiento o política establecidos al emitir sus informes de CPE respectivos…”.

      Dot Registry inició el IRP de Dot Registry el día 22 de septiembre de 2014, objetando la denegación del BGC de las Solicitudes de Reconsideración de Dot Registry y objetando supuestamente la designación de la ICANN de Economist Intelligence Unit (EIU) como el proveedor externo para realizar las CPE, y la respuesta de la Junta Directiva al asesoramiento del Comité de Gobernanza de la Junta Directiva de la ICANN respecto de .LLC, .INC y .LLP.

      En una decisión de 2 a 1, la mayoría del Panel declaró que Dot Registry era la parte prevaleciente y determinó que “las acciones e inacciones de la Junta Directiva no estaban en consonancia con las Actas Constitutivas y los Estatutos de la ICANN”. (Declaración Final, ¶ 151). Específicamente, la mayoría del Panel declaró que “la Junta Directiva (actuando a través del BGC) no ejerció debida diligencia y cuidado en tener una cantidad razonable de hechos en frente de ella y no cumplió con sus obligaciones respecto de la transparencia” y que no había suficiente evidencia para “respaldar una determinación de que la Junta Directiva (actuando a través del BGC) ejerció un juicio independiente para llegar a las decisiones de reconsideración”. (Ídem, ¶¶ 151-152). La mayoría del Panel también declaró que la ICANN “deberá pagarle a Dot Registry, LLC USD 235.294,37, suma que representa las tarifas, gastos y remuneración anteriormente incurridos por Dot Registry, LLC una vez que se determine que dichos costos incurridos han sido pagados en su totalidad”. (Ídem, ¶ 154)

      La Junta Directiva señaló que la mayoría del Panel indicó que “para llegar a estas conclusiones, el Panel no está evaluando si el personal de la ICANN o la EIU no cumplieron con las obligaciones en virtud de las Actas, los Estatutos o la [Guía para el Solicitante (Guía)]”. (Ídem, ¶ 152) Además, también señaló que [l]a mayoría del Panel rechaz[ó] sustituir su juicio por el juicio de la CPE en cuanto a si Dot Registry tiene derecho a la prioridad de la Comunidad”. (Ídem, ¶ 153)

      Durante su consideración inicial de la Declaración Final, la Junta Directiva aceptó las conclusiones de la Declaración Final de que: (i) Dot Registry es la parte prevaleciente en el IRP de Dot Registry, LLC vs la ICANN; y (ii) la ICANN deberá pagar a Dot Registry la suma de USD235.294,37 una vez que se demuestre que estos costos incurridos hayan sido pagados en su totalidad." (Véase https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#2.g.)

      La Junta Directiva también "ha señalado las otras conclusiones contenidas en la Declaración y las conclusiones respecto de las declaraciones de la mayoría del Panel en relación al estándar de revisión de las Solicitudes de Reconsideración al que se hace referencia más arriba, y considerará los próximos pasos en cuanto a las Solicitudes de Reconsideración de Dot Registry o los nuevos gTLD relevantes antes de que la Junta Directiva tome alguna otra medida." (Véase ídem). Además, la Junta Directiva reconoció que la mayoría del Panel no formuló ninguna recomendación específica sobre las próximas medidas a tomarse por parte de la Junta Directiva.

      Dado que la Junta Directiva ha tenido la oportunidad de evaluar a fondo algunos de esas otras conclusiones de la Declaración Final, la Junta Directiva ha determinado que el mejor enfoque en este momento sería que el BGC reevalúe las Solicitudes de Reconsideración de Dot Registry 14-30, 14 -32 y 14-33 a la luz de la Declaración Final de la mayoría del Panel del IRP de Dot Registry y las cuestiones identificadas en dicha declaración con respecto a las acciones del BGC en la evaluación de estas Solicitudes de Reconsideración.

      Como parte de sus deliberaciones para tomar acción, la Junta Directiva analizó diversos materiales, incluidos, entre otros, los siguientes materiales y documentos:

      • Solicitud de Reconsideración 14-30: Dot Registry, LLC (25 de junio de 2014)
      • Solicitud de Reconsideración 14-32: Dot Registry, LLC (26 de junio de 2014)
      • Solicitud de Reconsideración 14-33: Dot Registry, LLC (26 de junio de 2014)
      • Proceso de Revisión Independiente de Dot Registry vs la ICANN
      • Carta de Steve Crocker a Heather Dryden en referencia a: Reunión del NGPC (Comité para el Programa de Nuevos gTLD) del 5 de febrero de 2014 (10 de febrero de 2014)
      • Carta [PDF, 148 KB] de Jeffrey W. Bullock a la Junta Directiva de la ICANN en referencia a: Declaración del IRP de Dot Registry LLC. vs la ICANN (8 de agosto de 2016) [PDF, 1.5 MB]
        Carta de Shaul Jolles a la Junta Directiva de la ICANN en referencia a: Reunión Extraordinaria de la Junta Directiva de la ICANN del 9 de agosto de 2016, en la cual se trató el tema de la Declaración del Proceso de Revisión Independiente ("IRP") de Dot Registry LLC vs la ICANN (01-14-0001-5004), de fecha 29 de julio de 2016 (6 de agosto de 2016)

      No se espera que esta medida tenga ningún impacto financiero directo sobre la organización. Esta medida no tendrá ningún impacto directo sobre la seguridad, estabilidad o flexibilidad del sistema de nombres de dominio.

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

    6. Consideración del Informe del Defensor del Pueblo en relación a dotgay, solicitud de LLC para .GAY

      No se adoptó ninguna resolución.

    7. Solicitud de Reconsideración 16-3 (dotgay LLC)

      No se adoptó ninguna resolución.

    8. Otros temas a tratar

      No se adoptó ninguna resolución.

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