Resoluciones aprobadas por la Junta Directiva | Reunión Extraordinaria de la Junta Directiva de la ICANN 9 de agosto de 2016

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-08-09-en

Orden del día convenido:
1. Aprobación de las actas de la reunión
Orden del día principal:
Sesión Ejecutiva - Confidencial:
1. Remuneración de riesgo para el Defensor del Pueblo correspondiente al año fiscal 2016 (FY16)
  - Fundamento de la resolución 2016.08.09.16
2. Remuneración de funcionarios
  - Fundamento de las resoluciones 2016.08.09.16 – 2016.08.09.20

Orden del día convenido:
1. Aprobación de las actas de la reunión
  
  Resuélvase (2016.08.09.01): La Junta Directiva aprueba las actas de los días 25 y 27 de junio de 2016 de las reuniones de la Junta Directiva de la ICANN.

Orden del día principal:
1. Carta orgánica del Comité de Revisión de la Evolución de la Zona Raíz (RZERC)
  
  Visto y considerando: Que la ICANN elaboró la carta orgánica propuesta del Comité de Revisión de la Evolución de la Zona Raíz (RZERC) en cooperación con el Grupo de Acción para la Supervisión de la Implementación (IOTF) y el Grupo de Trabajo Intercomunitario sobre Funciones de Nombres (CWG sobre Custodia).
  
  Visto y considerando: Que la carta orgánica propuesta está en consonancia con la propuesta del Grupo de Coordinación de la Transición de la Custodia de las Funciones de la IANA (ICG) que la Junta Directiva aprobó y transmitió a la Administración Nacional de Telecomunicaciones e Información de los Estados Unidos (NTIA) el 10 de marzo de 2016.
  
  Visto y considerando: Que la ICANN abrió un período de comentario público desde el 30 de junio de 2016 hasta el 10 de julio de 2016 <https://www.icann.org/public-comments/draft-rzerc-charter-2016-06-10-en> sobre la carta orgánica propuesta <https://www.icann.org/en/system/files/files/draft-rzerc-charter-10jun16-en.pdf> [PDF, 43 KB].
  
  Visto y considerando: Que el foro de comentarios públicos sobre la carta orgánica propuesta cerró el día 10 de julio de 2016 y que la ICANN recibió siete presentaciones de comentarios tanto por parte de individuos como de organizaciones/grupos. Después de la revisión de estos comentarios, la ICANN coordinó con las partes afectadas de la comunidad de la ICANN para abordar las inquietudes y revisar la carta orgánica de manera adecuada.
  
  Visto y considerando: Que la carta orgánica del RZERC exige que un representante de la Junta Directiva de la ICANN forme parte del Comité.
  
  Resuélvase (2016.08.09.02): La Junta Directiva aprueba la carta orgánica del RZERC en respuesta al comentario público, y se autoriza al Presidente y Director Ejecutivo, o a quien éste designe, a tomar las medidas apropiadas para formar el RZERC.
  
  Resuélvase (2016.08.09.03): La Junta Directiva designa a Suzanne Woolf como integrante del RZERC.
  
  Fundamento de las resoluciones 2016.08.09.02 – 2016.08.09.03
  
  ¿Por qué la Junta Directiva aborda el tema ahora?
  
  El 10 de marzo de 2016, la Junta Directiva aprobó y transmitió la propuesta del Grupo de Coordinación de la Transición de la Custodia de las Funciones de la IANA (ICG) a la Administración Nacional de Telecomunicaciones e Información de los Estados Unidos (NTIA) y ordenó que la ICANN siguiese con la planificación de la implementación. Uno de los requisitos en la parte de nombres de la propuesta del ICG es la formación de un comité permanente para revisar los cambios arquitectónicos propuestos al contenido de la zona raíz del DNS, los sistemas incluidos tanto los componentes de hardware como de software utilizados en la ejecución de los cambios a la zona raíz del DNS, y los mecanismos empleados para la distribución de dicha zona. El Comité, según sus miembros lo consideren necesario, realizará recomendaciones relacionadas a dichos cambios para su consideración por la Junta Directiva de la ICANN. La aprobación de la Junta Directiva en la recomendación del Comité es el reemplazo propuesto del CWG sobre Custodia del rol actual de la NTIA, que ya no se ejercería si vence el Contrato de Funciones de la IANA. Como parte de la planificación de la implementación, la ICANN nombró a este comité permanente Comité de Revisión de la Evolución de la Zona Raíz (RZERC) y trabajó con la comunidad para redactar una carta orgánica para dicho Comité.
  
  ¿Cuál es la propuesta que se está considerando?
  
  La carta orgánica propuesta describe el propósito, el alcance de responsabilidades y la composición del Comité. Asimismo, la carta orgánica estipula cómo deberá comportarse el Comité, incluidos la frecuencia y el método de las reuniones, cómo se deberán tomar las decisiones, los registros de procedimientos, así como los conflictos de interés. Por último, la carta orgánica establece los requisitos para llevar a cabo revisiones y enmiendas a la carta orgánica.
  
  ¿Cuáles son las partes interesadas u otros participantes consultados?
  
  La ICANN consultó con el Grupo de Acción para la Supervisión de la Implementación (IOTF) así como con el CWG sobre Custodia en la elaboración de la carta orgánica propuesta. Asimismo, la ICANN llevó a cabo un período de comentario público sobre la carta orgánica propuesta del 10 de junio de 2016 al 10 de julio de 2016; finalizado dicho período, se resumieron y analizaron los comentarios recibidos.
  
  ¿Qué inquietudes o cuestiones fueron planteadas por la comunidad?
  
  Siete (7) miembros de la comunidad participaron en el período de comentario público. En sus comentarios, los miembros de la comunidad plantearon una inquietud fundamental.
  
  La inquietud fue que el alcance de las responsabilidades del RZERC tal como está redactado parece superponerse con las responsabilidades del RSSAC. El alcance del RZERC tal como está redactado es considerar cuestiones arquitectónicas y operativas que imponen un riesgo potencial a la zona raíz y el sistema raíz. Los comentaristas sugirieron que este alcance podría ser interpretado para significar que el RZERC podría considerar cuestiones relativas al funcionamiento de los servidores raíz, lo cual es una responsabilidad del RSSAC. Para abordar esta inquietud, la ICANN trabajó con el RSSAC para modificar el alcance del RZERC a fin de aclarar que se espera que el RZERC revise los cambios arquitectónicos propuestos al contenido de la zona raíz del DNS, los sistemas incluidos tanto los componentes de hardware como de software empleados en la ejecución de los cambios a la zona raíz del DNS, y los mecanismos empleados para la distribución de dicha zona. El Comité, según sus miembros lo consideren necesario, realizará recomendaciones relacionadas a dichos cambios para su consideración por la Junta Directiva de la ICANN.
  
  ¿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:
  - La carta orgánica propuesta del RZERC <https://www.icann.org/en/system/files/files/draft-rzerc-charter-10jun16-en.pdf> [PDF, 43 KB]
  - Comentarios públicos <https://forum.icann.org/lists/comments-draft-rzerc-charter-10jun16/>
  - Resumen y análisis de los comentarios públicos
  - Propuesta del Grupo de Coordinación de la Transición de la Custodia de las Funciones de la IANA (ICG) <https://www.icann.org/en/system/files/files/iana-stewardship-transition-proposal-10mar16-en.pdf> [PDF, 2.32 MB]
  - La carta orgánica del RZERC según se modificó en respuesta al comentario público.
  ¿Existen impactos positivos o negativos para la comunidad?
  
  La aprobación de la carta orgánica por parte de la Junta Directiva es un paso importante en el proceso de planificación de la implementación para cumplir con uno de los requisitos de la propuesta del ICG, la cual fue avalada por la comunidad global de partes interesadas y aprobada por la Junta Directiva el 10 de marzo de 2016.
  
  ¿Se observan impactos fiscales o ramificaciones en la ICANN (plan estratégico, plan operativo, presupuesto), la comunidad o el público?
  
  No se prevé ningún impacto fiscal.
  
  ¿Se observan cuestiones sobre seguridad, estabilidad o flexibilidad relacionadas con el DNS?
  
  La aprobación de la carta orgánica propuesta sería un paso importante hacia garantizar la seguridad, estabilidad y flexibilidad del DNS posterior a la transición. El alcance de la responsabilidad del RZERC será proporcionar a la Junta Directiva de la ICANN recomendaciones respecto de los cambios arquitectónicos propuestos al contenido de la zona raíz del DNS, los sistemas incluidos tanto los componentes de hardware como de software utilizados en la ejecución de los cambios a la zona raíz del DNS, y los mecanismos empleados para la distribución de dicha zona.
2. Actas Constitutivas de la PTI
  
  Visto y considerando: Que, el 14 de marzo de 2014, la Administración Nacional de Telecomunicaciones e Información (NTIA) del Departamento de Comercio de los Estados Unidos anunció su intención de transferir la custodia de las funciones de la IANA a la comunidad global de múltiples partes interesadas.
  
  Visto y considerando: Que, el 10 de marzo de 2016, la Corporación para la Asignación de Nombres y Números en Internet (ICANN) aceptó y envió a la NTIA los siguientes documentos para la transición: (i) la Propuesta de Transición de la Custodia de la IANA, elaborada por el Grupo de Coordinación de la Transición de la Custodia de las Funciones de la IANA, (la “Propuesta del ICG”) y (ii) el Informe del Área de Trabajo 1, elaborado por el Grupo de Trabajo Intercomunitario sobre la Mejora de la Responsabilidad de la ICANN (colectivamente denominados "Propuestas de Transición").
  
  Visto y considerando: Que la Propuesta del ICG incluía un requisito de que la ICANN desarrollara una filial para desempeñar las funciones de la IANA relacionadas con los nombres en virtud de un contrato con la ICANN, la IANA posterior a la transición. La Propuesta del ICG requería que la PTI sea una organización benéfica pública sin fines de lucro del Estado de California y que el ICG sea el único miembro de la PTI.
  
  Visto y considerando: Que los abogados de la ICANN trabajaron diligentemente con el asesor independiente al Grupo de Trabajo Intercomunitario para desarrollar una propuesta de transición de la custodia de la IANA sobre las funciones relativas a los nombres (“CWG sobre Custodia”) para elaborar las Actas Constitutivas para la nueva PTI. Dichas Actas preliminares se publicaron para comentario público durante un período de 30 días.
  
  Visto y considerando: Que, al finalizar dicho período de comentario, se realizó un análisis detallado de los comentarios recibidos y, en respuesta a ellos, se hicieron modificaciones a las Actas. La ICANN coordinó esfuerzos con el estudio jurídico independiente respecto de las revisiones.
  
  Visto y considerando: Que el Asesor Letrado General de la ICANN ha afirmado que las Actas Constitutivas de la PTI propuestas siguen siendo congruentes con las Propuestas de Transición y recomienda que la ICANN proceda a formar la filial para permitir que la planificación de la implementación continúe.
  
  Resuélvase (2016.08.09.04): La Junta Directiva de la ICANN autoriza al Director Ejecutivo de la ICANN, o a quien éste designe, a proceder con la formación de la PTI, incluida la presentación de las Actas Constitutivas de la PTI propuestas según fueron revisadas después del período de comentario público.
  
  Fundamento de la resolución 2016.08.09.04
  
  La autorización para que la ICANN proceda con la formación de la PTI, a través de la presentación de las Actas Constitutivas de la PTI, es un paso crucial en la planificación de la implementación de las Propuestas de Transición. Éste es un paso clave para el informe de la ICANN a la NTIA sobre el estado de la planificación de la implementación. Esta autorización oportuna de proceder con la formación de la PTI es necesaria para respaldar el trabajo de la comunidad global de múltiples partes interesadas hacia una compleción exitosa de la custodia de las funciones de la IANA.
  
  Estas Actas de la 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. Las Actas de la PTI fueron publicadas por un período de comentario público de 30 días, durante el cual se recibieron 3 comentarios. Cada uno de los comentarios fue considerado y analizado, y se brindó una explicación respecto de si era necesario modificar las Actas de la PTI a fin de reflejar las cuestiones planteadas en el comentario en cuestión.
  
  Con la pequeña cantidad de comentarios, las Actas no requirieron cambios significativos en respuesta a dichos comentarios. Los cambios realizados incluyeron una modificación al propósito de la PTI para reflejar de manera más precisa el ron limitado y estrecho de la PTI para desempeñar las funciones de la IANA. Se realizó otro cambio para reflejar el umbral adecuado necesario para enmendar las Actas de la PTI.
  
  A la hora de adoptar esta acción, la Junta Directiva se basó en lo siguiente:
  - La Propuesta de Transición de la Custodia de la IANA presentada por el ICG [PDF; 2,32 MB]
  - Informe de Comentarios Públicos sobre las Actas Constitutivas de la PTI
  - Versión preliminar de las Actas Constitutivas de la PTI
  La Junta Directiva también se basó en la afirmación del Asesor Letrado General y Secretario de que las Actas de la PTI reflejaban las Propuestas de Transición, así como los aportes del asesor independiente para crear las Actas de la PTI en respaldo de la Propuesta del ICG.
  
  La autorización de la formación de la PTI está en consonancia con el compromiso de la ICANN para con la responsabilidad y transparencia. Esta acción confirma el compromiso de la ICANN para implementar las Propuestas de Transición y todos los elementos contenidos en ellas.
  
  No se prevé que la formación de la PTI tenga impacto en la seguridad, estabilidad o flexibilidad del DNS, si bien la PTI será esencial para el trabajo sobre seguridad, estabilidad y flexibilidad de la ICANN. Habrá implicancias en los recursos, incluidos los recursos importantes para respaldar una nueva filial.
  
  Esta medida constituye una función organizativa y administrativa que ya se ha sometido a comentario público.
3. Acuerdo con la Entidad encargada del mantenimiento de la Zona Raíz
  
  Visto y considerando: Que, en una carta a la ICANN con fecha 4 de marzo de 2015, la Administración Nacional de Telecomunicaciones e Información de los Estados Unidos (NTIA) solicitó oficialmente que Verisign y la ICANN trabajasen en el desarrollo de una propuesta para efectuar la transición del rol administrativo ejercido por la NTIA en relación con la gestión de la zona raíz de la mejor manera posible, y en forma tal que se mantengan la seguridad, estabilidad y flexibilidad del Sistema de Nombres de Dominio de Internet.
  
  Visto y considerando: Que, en agosto de 2015, la ICANN y Verisign presentaron una propuesta a la NTIA en respuesta a su solicitud <https://www.ntia.doc.gov/files/ntia/publications/root_zone_administrator_proposal-relatedtoiana_functionsste-final.pdf> [PDF, 247 KB]. La propuesta describe dos partes, un período de prueba paralela del Sistema de Gestión de la Zona Raíz (RZMS) y un Acuerdo de Servicios de Mantenimiento de la Zona Raíz (RZMA) con Verisign para que Verisign siga desempeñando la función de entidad encargada del mantenimiento de la Zona Raíz que desempeña hoy en día en virtud del Acuerdo de Cooperación con el Departamento de Comercio.
  
  Visto y considerando: Que la NTIA especificó en una carta a la ICANN con fecha 9 de junio de 2016 que un RZMA finalizado y la compleción exitosa del período de prueba paralela son condiciones previas a la transición de la custodia de la IANA.
  
  Visto y considerando: Que la compleción del RZMA es un requisito 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 y, dado que el RZMA supera los USD 500.000 en total, se requiere que la Junta Directiva apruebe delegar la autoridad de firma al Director Ejecutivo.
  
  Visto y considerando: Que el período de prueba paralela del RZMS finalizó exitosamente el 6 de julio de 2016 <https://www.icann.org/news/announcement-2016-07-14-en>.
  
  Visto y considerando: Que la ICANN y Verisign finalizaron las negociaciones sobre los términos del RZMA propuesto para que Verisign desempeñe la función de entidad encargada del mantenimiento de la Zona Raíz y publicaron el RZMA propuesto por un período de notificación de 30 días tal como lo requiere la propuesta del Grupo de Coordinación de la Transición de la Custodia de las Funciones de la IANA (ICG) <https://www.icann.org/news/blog/root-zone-management-transition-update-preservation-of-security-stability-and-resiliency>.
  
  Visto y considerando: Que el RZMA propuesto contiene disposiciones que incorporan requisitos relevantes del Grupo de Trabajo Intercomunitario sobre Funciones de Nombres (CWG sobre Custodia).
  
  Visto y considerando: Que el Comité de Finanzas de la Junta Directiva revisó las implicancias y los aspectos financieros del RZMA y consideró (i) que los costos propuestos del contrato eran razonables, (ii) que el proceso de adquisición había sido respetado, (iii) que los costos eran asequibles, y, por ende, recomendó que la Junta Directiva aprobara dicho acuerdo.
  
  Resuélvase (2016.08.09.05): Se aprueba el RZMA 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.08.09.05
  
  ¿Por qué la Junta Directiva aborda el tema ahora?
  
  En una carta a la ICANN con fecha 4 de marzo de 2015, la Administración Nacional de Telecomunicaciones e Información de los Estados Unidos (NTIA) “solicitó oficialmente que Verisign y la ICANN trabajasen en el desarrollo de una propuesta para efectuar la transición del rol administrativo ejercido por la NTIA en relación con la gestión de la zona raíz de la mejor manera posible, y en forma tal que se mantengan la seguridad, estabilidad y flexibilidad del Sistema de Nombres de Dominio de Internet”. En agosto de 2015, la ICANN y Verisign presentaron una propuesta a la NTIA en respuesta a su solicitud <https://www.ntia.doc.gov/files/ntia/publications/root_zone_administrator_proposal-relatedtoiana_functionsste-final.pdf> [PDF, 247 KB]. La propuesta describe dos partes, un período de prueba paralela del Sistema de Gestión de la Zona Raíz (RZMS) y un Acuerdo de Servicios de Mantenimiento de la Zona Raíz con Verisign para que Verisign siga desempeñando la función de entidad encargada del mantenimiento de la Zona Raíz que desempeña hoy en día en virtud del Acuerdo de Cooperación con el Departamento de Comercio.
  
  Asimismo, se especificó que la compleción del RZMA era 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 y, dado que supera los USD 500.000 en total, se requiere que la Junta Directiva apruebe delegar la autoridad de firma al Director Ejecutivo.
  
  Desde agosto pasado, la ICANN y Verisign han estado manteniendo discusiones y negociaciones continuas respecto de los términos del RZMA. Las negociaciones concluyeron en junio y se publicó el RZMA propuesto por un período de notificación de 30 días el 30 de junio de 2016. El período de notificación pública de 30 días finalizó el 30 de julio de 2016 y la Junta Directiva ha considerado el RZMA propuesto para su aprobación.
  
  ¿Cuál es la propuesta que se está considerando?
  
  El RZMA propuesto permite que Verisign siga prestando los servicios de mantenimiento de la zona raíz, la firma de la zona raíz con la ZSK y la distribución del archivo de la zona raíz y archivos relacionados a los operadores de la zona raíz a una tarifa nominal. El RZMA estipula un plazo de 8 años con sólidos acuerdos de nivel de servicio que pueden modificarse a través de un proceso de control de cambios si los clientes de la IANA requieren cambios a estos acuerdos de nivel de servicio. El proceso de control de cambios también permite cambios al Sistema de Gestión de la Zona Raíz a medida que la gestión de la zona raíz evoluciona a fin de satisfacer las necesidades de la comunidad. Si bien el plazo de 8 años del RZMA está destinado a promover la seguridad, estabilidad y flexibilidad de las operaciones de mantenimiento de la zona raíz al hacer que Verisign continúe en su rol, el acuerdo también brinda la capacidad para que la comunidad, a través de un proceso impulsado por la comunidad y basado en consenso haga que la ICANN realice la transición de la función a otro proveedor de servicios después de tres años. El RZMA completo fue publicado por un período de notificación pública de 30 días el 30 de junio de 2016 tal como lo exige la propuesta del ICG y puede consultarse en <https://www.icann.org/iana_imp_docs/63-root-zone-maintainer-agreement-v-1-0>.
  
  ¿Cuáles son las partes interesadas u otros participantes consultados?
  
  La ICANN mantuvo discusiones y negociaciones con Verisign, Inc. para finalizar el RZMA propuesto, que luego fue publicado por un período de notificación pública de 30 días, del 30 de junio al 30 de julio de 2016.
  
  ¿Qué inquietudes o cuestiones fueron planteadas por la comunidad?
  
  No hubo cuestiones o inquietudes importantes que llamasen la atención de la ICANN durante el período de notificación pública de 30 días.
  
  ¿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:
  - Acuerdo de Cooperación de Verisign con el Gobierno de los Estados Unidos <https://www.ntia.doc.gov/page/verisign-cooperative-agreement>
  - Carta de la NTIA con fecha 4 de marzo de 2015
  - Propuesta de Verisign y la ICANN en respuesta a la solicitud de la NTIA – Propuesta de la Entidad administradora de la Zona Raíz en relación con la transición de la custodia de las funciones de la IANA <https://www.ntia.doc.gov/files/ntia/publications/root_zone_administrator_proposal-relatedtoiana_functionsste-final.pdf> [PDF, 247 KB]
  - Acuerdo de Servicios de Mantenimiento de la Zona Raíz <https://www.icann.org/iana_imp_docs/63-root-zone-maintainer-agreement-v-1-0>
  - Propuesta del Grupo de Coordinación de la Transición de la Custodia de las Funciones de la IANA (ICG) <https://www.icann.org/en/system/files/files/iana-stewardship-transition-proposal-10mar16-en.pdf> [PDF, 2.32 MB]
  ¿Qué factores la Junta Directiva consideró significativos?
  
  La Junta Directiva consideró cuidadosamente el RZMA para garantizar que contenga disposiciones que permitan que la ICANN cumpla con los requisitos de la comunidad para la transición, tales como:
  - La capacidad de modificar acuerdos de nivel de servicio debido a recomendaciones del Comité Permanente de Clientes
  - La capacidad de llevar a cabo modificaciones al Sistema de Gestión de la Zona Raíz debido a recomendaciones del Comité de Revisión de la Evolución de la Zona Raíz
  - La capacidad para que la comunidad, a través de un proceso impulsado por la comunidad y basado en consenso, haga que la ICANN realice la transición de la función de encargada de mantenimiento a otro proveedor de servicios
  - Asimismo, la Junta Directiva consideró cuidadosamente los términos del RZMA para garantizar que la función de mantenimiento pueda seguir siendo desempeñada de manera segura, estable y confiable después de la transición.
  ¿Existen impactos positivos o negativos para la comunidad?
  
  Un objetivo clave del RZMA propuesto y la participación continua con Verisign, Inc. para el desempeño de la función de mantenimiento es ofrecer operaciones seguras y estables de la zona raíz a lo largo de la transición de la custodia de la IANA y en el futuro. La aprobación del RZMA propuesto por parte de la Junta Directiva garantizaría que se sigan cumpliendo las expectativas de los clientes de la IANA.
  
  ¿Se observan impactos fiscales o ramificaciones en la ICANN (plan estratégico, plan operativo, presupuesto), la comunidad o el público?
  
  Verisign, Inc. ha desempeñado históricamente, de manera exclusiva, la función de mantenimiento sin costo alguno y se desea contratar directamente con Verisign, Inc. para el desempeño continuo de este trabajo a fin de garantizar la continuidad, seguridad y estabilidad durante el período de transición. Los términos del RZMA permiten que la comunidad, a través de un proceso impulsado por la comunidad y basado en consenso, haga que la ICANN realice la transición de la función de encargada de mantenimiento a otro proveedor de servicios. Este contrato crea una tarifa nominal anual de USD 300.000 por año pagaderos a Verisign, Inc. por el desempeño de la función de mantenimiento. El Comité de Finanzas de la Junta Directiva ha revisado las implicancias y los aspectos financieros del RZMA propuesto y recomendó a la Junta Directiva que lo aprobara, sobre la base de esta revisión.
  
  ¿Se observan cuestiones sobre seguridad, estabilidad o flexibilidad relacionadas con el DNS?
  
  La aprobación del RZMA propuesto por la Junta Directiva garantizaría la continuidad, seguridad y estabilidad del funcionamiento de la zona raíz durante el período de transición y con posterioridad a él.
4. Actas Constitutivas Reformuladas de la ICANN
  
  Visto y considerando: Que, el 14 de marzo de 2014, la Administración Nacional de Telecomunicaciones e Información (NTIA) del Departamento de Comercio de los Estados Unidos anunció su intención de transferir la custodia de las funciones de la IANA a la comunidad global de múltiples partes interesadas.
  
  Visto y considerando: Que, el 10 de marzo de 2016, la Corporación para la Asignación de Nombres y Números en Internet (ICANN) aceptó y envió a la Administración Nacional de Telecomunicaciones e Información de los Estados Unidos los siguientes documentos para la transición: (i) la Propuesta de Transición de la Custodia de la IANA, elaborada por el Grupo de Coordinación de la Transición de la Custodia de las Funciones de la IANA, (la “Propuesta del ICG”) y (ii) el Informe del Área de Trabajo 1, elaborado por el Grupo de Trabajo Intercomunitario sobre la Mejora de la Responsabilidad de la ICANN (colectivamente denominados "Propuestas de Transición").
  
  Visto y considerando: Que las Actas Constitutivas de la ICANN debían reformularse a fin de que estuvieran en consonancia con los nuevos Estatutos de la ICANN y para su consistencia con las Propuestas de Transición.
  
  Visto y considerando: Que los abogados de la ICANN trabajaron diligentemente con el asesor independiente al CCWG sobre Responsabilidad para desarrollar las Actas Constitutivas Reformuladas para la ICANN. Dichas Actas Reformuladas se publicaron para comentario público durante un período de 40 días.
  
  Visto y considerando: Que, al finalizar dicho período de comentario, se realizó un análisis detallado de los comentarios recibidos y, en respuesta a ellos, se hicieron modificaciones a las Actas. La ICANN coordinó con las firmas legales independientes respecto de las revisiones.
  
  Visto y considerando: Que el Asesor Letrado General de la ICANN ha afirmado que las Actas Constitutivas Reformuladas propuestas de la ICANN siguen estando en consonancia con las Propuestas de Transición y recomienda que la Junta Directiva apruebe la enmienda a las Actas de la ICANN y autoriza a la ICANN a proceder con la presentación en el momento adecuado.
  
  Resuélvase (2016.08.09.06): La Junta Directiva de la ICANN aprueba las enmiendas propuestas a las Actas Constitutivas de la ICANN, que serán consideradas en vigencia ante el vencimiento del Contrato de Funciones de la IANA entre la ICANN y la NTIA.
  
  Resuélvase (2016.08.09.07): La Junta Directiva de la ICANN autoriza al Director Ejecutivo de la ICANN, o a quien éste designe, a proceder con la presentación de las Actas Constitutivas Reformuladas una vez que entren en vigencia.
  
  Fundamento de las resoluciones 2016.08.09.06 – 2016.08.09.07
  
  La adopción de las Actas Constitutivas Reformuladas es otro paso clave en la planificación de la implementación de las Propuestas de Transición. La Junta Directiva está tomando esta acción ahora para respaldar el informe de estado de la planificación de la transición de la ICANN a la NTIA cuyo plazo vence el 12 de agosto de 2016. La adopción de las enmiendas a las Actas Constitutivas de la ICANN completa los cambios a los documentos de gobernanza clave de la ICANN que deben alinearse con las Propuestas de Transición y respaldan el trabajo de la comunidad global de múltiples partes interesadas hacia la realización exitosa de la custodia de las funciones de la IANA.
  
  Estas Actas Reformuladas fueron desarrolladas conjuntamente entre los equipos de asuntos legales en coordinación con la comunidad de la ICANN. El asesor externo al CCWG sobre Responsabilidad y los abogados de la ICANN trabajaron estrechamente con el CCWG sobre Responsabilidad para confirmar su comprensión y respaldo del documento. Las Actas Reformuladas propuestas fueron publicadas para el público por un período de 40 días, incluida una extensión solicitada. Se recibieron seis comentarios. Cada uno de los comentarios fue considerado y analizado, y se brindó una explicación respecto de si era necesario modificar las Actas a fin de reflejar las cuestiones planteadas en el comentario en cuestión. Los equipos de asuntos legales continuaron con su coordinación estrecha en el desarrollo de las actualizaciones necesarias a las Actas.
  
  Los cambios a las Actas preliminares basados en los comentarios fueron limitados.
  
  A la hora de adoptar esta acción, la Junta Directiva se basó en lo siguiente:
  - La Propuesta de Transición de la Custodia de la IANA presentada por el ICG [PDF; 2,32 MB]
  - Informe del Área de trabajo 1 del Grupo de Trabajo Intercomunitario sobre la Mejora de la Responsabilidad de la ICANN (CCWG sobre Responsabilidad) a la Junta Directiva de la ICANN (“Informe”) [PDF, 6.03 MB]
  - Informe de comentarios públicos de las Actas Constitutivas Reformuladas propuestas (limpio y con texto resaltado a las Actas existentes)
  La Junta Directiva también se basó en la afirmación del Asesor Letrado General y Secretario de que las Actas Reformuladas reflejan las Propuestas de Transición, así como el trabajo del asesor independiente para crear las Actas en respaldo de las Propuestas de Transición.
  
  La adopción de estas Actas está en consonancia con el compromiso de la ICANN para con la responsabilidad y transparencia, ya que esto completa el documento de gobernanza clave que la ICANN necesita implementar para ofrecer a la comunidad las herramientas de responsabilidad nuevas y mejoradas. Esta acción ratifica el compromiso asumido por la ICANN de adoptar los cambios de responsabilidad.
  
  Se prevé que la adopción de estas Actas Reformuladas no tenga ningún impacto sobre la seguridad, estabilidad o flexibilidad del DNS. La implicancias en los recursos de estas Actas Reformuladas son las mismas que las posibles implicancias en los recursos identificadas para la implementación de los nuevos Estatutos de la ICANN.
  
  Esta medida constituye una función organizativa y administrativa que ya se ha sometido a comentario público.
5. Recomendaciones de políticas de la GNSO sobre la acreditación de servicios de privacidad y representacióin (proxy)
  
  Visto y considerando: Que el 31 de octubre de 2013 el Consejo de la GNSO aprobó la carta orgánica para un Grupo de Trabajo que llevase a cabo un Proceso de Desarrollo de Políticas que había sido solicitado por la Junta Directiva de la ICANN respecto de la acreditación por parte de la ICANN de proveedores de servicios de registración de nombres de dominio de privacidad y representación (proxy), como se describe con mayor detalle en http://gnso.icann.org/en/drafts/raa-pp-charter-22oct13-en.pdf [PDF, 463 KB].
  
  Visto y considerando: Que el PDP siguió los pasos establecidos para dicho proceso, de acuerdo con lo estipulado en los Estatutos de la ICANN, lo que generó el Informe Final que fue presentado ante el Consejo de la GNSO el 8 de diciembre de 2015.
  
  Visto y considerando: Que el Grupo de Trabajo sobre Cuestiones de la Acreditación de Servicios de Privacidad y Representación (WG) alcanzó pleno consenso respecto de todas sus recomendaciones finales (véase http://gnso.icann.org/en/issues/raa/ppsai-final-07dec15-en.pdf) [PDF, 1.24 MB].
  
  Visto y considerando: Que el Consejo de la GNSO examinó y debatió las recomendaciones finales de PDP WG sobre las Cuestiones de la Acreditación de Servicios de Privacidad y Representación y adoptó las recomendaciones el día 21 de enero de 2016 mediante votación unánime (véase http://gnso.icann.org/en/council/resolutions - 201601).
  
  Visto y considerando: Que la votación del Consejo de la GNSO superó el umbral de votación requerido (es decir, la mayoría calificada) para imponer nuevas obligaciones a las partes contratadas de la ICANN.
  
  Visto y considerando: Que, de conformidad con los Estatutos de la ICANN, se abrió un período de comentario público sobre las recomendaciones aprobadas a fin de brindar a la comunidad una oportunidad razonable para comentar sobre su adopción antes de la acción por parte de la Junta Directiva de la ICANN, y los comentarios recibidos se han resumido e informado (véase https://www.icann.org/en/system/files/files/report-comments-ppsai-recommendations-31mar16-en.pdf) [PDF, 299 KB].
  
  Visto y considerando: Que los Estatutos de la ICANN estipulan que la Junta Directiva debe solicitar la opinión del GAC respecto de “cualquier política que está siendo considerada por la Junta Directiva para su adopción que sustancialmente afecte el funcionamiento de Internet o terceros, incluida la imposición de cualquier tarifa o cargo” y “tome debidamente en cuenta cualquier asesoramiento presentado oportunamente” como resultado.
  
  Visto y considerando: Que la Junta Directiva notificó al GAC respecto de la publicación de las recomendaciones finales de la GNSO para comentario público el 19 de febrero de 2016 (véase https://gacweb.icann.org/download/attachments/27492514/2016-02-19-Steve-Crocker-to-Thomas-Schneider-GNSO-PDP.pdf?version=1&modificationDate=1456046942000&api=v2) [PDF, 819 KB].
  
  Visto y considerando: Que, en su Comunicado pronunciado en Marrakech el 9 de marzo de 2016, el GAC informó a la Junta Directiva de la ICANN que necesitaba más tiempo para considerar las posibles inquietudes de política pública en relación con la adopción de las recomendaciones finales de PDP (véase https://gacweb.icann.org/download/attachments/28278854/GAC Morocco 55 Communique FINAL.pdf?version=1&modificationDate=1458046221000&api=v2 [PDF, 567 KB]).
  
  Visto y considerando: Que el 15 de mayo de 2016 la Junta Directiva acusó recibo de las recomendaciones de PDP emitidas por la GNSO y resolvió considerarlas en su primera reunión después de ICANN56 para permitir que el GAC brinde asesoramiento en forma oportuna, si lo hubiese (véase https://www.icann.org/resources/board-material/resolutions-2016-05-15-en - 2.a).
  
  Visto y considerando: Que en su Comunicado pronunciado en Helsinki el 30 de junio de 2016, el GAC informó a la Junta Directiva de la ICANN que ordenase que las inquietudes del GAC fueran abordadas eficazmente en la mayor medida posible por el Equipo para la Revisión de la Implementación que se reunirá para implementar las recomendaciones adoptadas (véase https://gacweb.icann.org/display/gacweb/Governmental+Advisory+Committee?preview=/27132037/43712639/20160630_GAC%20ICANN%2056%20Communique_FINAL%20.pdf [PDF, 328 KB]).
  
  Resuélvase (2016.08.09.08): La Junta Directiva por el presente adopta todas las recomendaciones finales del Grupo de Trabajo de PDP sobre Cuestiones de la Acreditación de Servicios de Privacidad y Representación, según fueron aprobadas mediante votación unánime del Consejo de la GNSO el 21 de enero de 2016 (“Recomendaciones de Política sobre Privacidad/Representación”).
  
  Resuélvase (2016.08.09.09): La Junta Directiva ordena al Presidente y Director Ejecutivo, o a quien éste designe, elaborar y ejecutar un plan de implementación, incluidos costos y plazos, para las Recomendaciones de Política sobre Privacidad/Representación en consonancia con el Anexo A de los Estatutos de la ICANN y las Pautas y Principios del Equipo para la Revisión de la Implementación avalados por la Junta Directiva el 28 de septiembre de 2015 (véase https://www.icann.org/resources/board-material/resolutions-2015-09-28-en - 2.f), y seguir con las comunicaciones con la comunidad sobre dicho trabajo. En el caso de que surjan cuestiones relativas a las políticas durante el transcurso de las discusiones sobre la implementación, las mismas deberían ser remitidas a la GNSO de conformidad con el marco para la implementación asociado a las recomendaciones de política de la GNSO, incluyendo las Pautas y Principios del Equipo para la Revisión de la Implementación.
  
  Resuélvase (2016.08.09.10): La Junta Directiva acepta el asesoramiento del GAC del Comunicado pronunciado en Helsinki respecto de las Recomendaciones de Política de Privacidad/Representación. La Junta Directiva considerará el asesoramiento del GAC y brindará aportes al Equipo para la Revisión de la Implementación para su consideración en la planificación de la implementación.
  
  Fundamento de las resoluciones 2016.08.09.08 – 2016.08.09.10
  
  ¿Por qué la Junta Directiva está abordando ahora la cuestión?
  
  Al momento de comenzar las negociaciones con el Grupo de Partes Interesadas de Registradores para una nueva forma del Acuerdo de Acreditación de Registradores (RAA) en octubre de 2011, la Junta Directiva de la ICANN también solicitó un Informe de Cuestiones de la GNSO que, al finalizar las negociaciones sobre el RAA, daría comienzo a un PDP de la GNSO para abordar las cuestiones pendientes que no fueron tratadas durante las negociaciones sobre el RAA. En junio de 2013, la Junta Directiva de la ICANN aprobó un nuevo RAA de 2013 y el tema de acreditación de los servicios de privacidad y representación (proxy) fue identificado como la única cuestión a resolverse mediante dicho proceso. Este tema también ha sido señalado por el Equipo de Revisión de WHOIS en su Informe Final, publicado en mayo de 2012, en el cual el Equipo de Revisión había destacado la falta actual de reglas claras y uniformes respecto de estos servicios, lo que generaba resultados impredecibles para las partes interesadas. El Equipo de Revisión consideró que una supervisión y regulación adecuadas sobre dichos servicios abordaría las necesidades e inquietudes de las partes interesadas y recomendó que la ICANN considerase un sistema de acreditación. Hasta el desarrollo de un programa de acreditación, solo ciertos aspectos de dichos servicios son abarcados en una especificación provisoria al RAA de 2013, que vencerá el 1 de enero de 2017 o ante la implementación de un programa de acreditación por parte de la ICANN, lo que ocurra primero.
  
  El Consejo de la GNSO aprobó todas las recomendaciones finales del Informe Final del Grupo de Trabajo de PDP con fecha 8 de diciembre de 2015 en su reunión del 21 de enero de 2016, y un Informe sobre Recomendaciones a la Junta Directiva en febrero de 2016. De conformidad con los Estatutos de la ICANN, se abrió un período de comentario público para permitir aportes públicos sobre la adopción de las recomendaciones después del cual las recomendaciones de PDP fueron remitidas a la Junta Directiva para su revisión. El 15 de mayo de 2016, la Junta Directiva resolvió considerar tomar acción sobre las recomendaciones en la primera reunión de la Junta Directiva después de ICANN56 en Helsinki, Finlandia, para permitir que el GAC brinde asesoramiento oportuno sobre inquietudes de política pública planteadas por las recomendaciones de PDP, si lo hubiese. El asesoramiento del GAC en su Comunicado pronunciado en Helsinki fue que la Junta Directiva ordenase que las inquietudes del GAC fueran abordadas eficazmente en la mayor medida posible durante la fase de implementación de las recomendaciones de PDP.
  
  ¿Cuál es la propuesta que se está considerando?
  
  Las recomendaciones de política de la GNSO incluyen requisitos obligatorios mínimos para la operación de los servicios de privacidad y representación (proxy); el mantenimiento de puntos de contacto designados para informes de uso indebido y la publicación de una lista de proveedores acreditados; requisitos relacionados con el manejo de solicitudes de divulgación o publicación de detalles de contacto de clientes por ciertos terceros solicitantes; condiciones relacionadas con la divulgación y publicación de dichos detalles así como la negación a divulgar o publicar; y principios que rigen la anulación de acreditación de proveedores de servicios. La lista completa y el alcance de las recomendaciones finales pueden consultarse en el Anexo A del Informe de Recomendaciones del Consejo de la GNSO a la Junta Directiva (véase http://gnso.icann.org/en/drafts/council-board-ppsai-recommendations-09feb16-en.pdf) [PDF, 491 KB].
  
  ¿Cuáles son las partes interesadas u otros participantes consultados?
  
  Tal como lo requiere el Manual para PDP de la GNSO, el Grupo de Trabajo se comunicó con todas las unidades constitutivas y todos los grupos de trabajo de partes interesadas de la GNSO así como las Organizaciones de Apoyo y Comités Asesores para recibir aportes durante la etapa temprana del PDP. El Grupo de Trabajo también celebró sesiones abiertas a la comunidad en todas las reuniones públicas de la ICANN que tuvieron lugar durante el ciclo de vigencia de este PDP. Asimismo, solicitó aportes sobre posibles cuestiones de implementación de los equipos de Cumplimiento y Servicios para Registradores de la ICANN. Se abrieron períodos de comentario público para el Informe Preliminar de Cuestiones que precedió al PDP, el Informe Inicial del Grupo de Trabajo y la adopción del Consejo de la GNSO del Informe Final del Grupo de Trabajo. Las recomendaciones finales como se detallan en el Informe Final se completaron en función de la revisión y el análisis del Grupo de Trabajo de todos los comentarios públicos y aportes recibidos en respuesta a su Informe inicial.
  
  Con posterioridad al asesoramiento del GAC en su Comunicado pronunciado en Marrakech del 9 de marzo de 2016 y la resolución de la Junta Directiva del 15 de mayo de 2016, se llevaron a cabo también discusiones sobre el tema entre la Junta Directiva y la comunidad en ICANN56 en Helsinki, Finlandia.
  
  ¿Qué inquietudes o cuestiones fueron planteadas por la comunidad?
  
  Un cantidad significativa de comentarios públicos fueron recibidos por el Grupo de Trabajo respecto de la posibilidad de que se realice una distinción entre los registratarios de nombres de dominio con dominios que sirven para fines no comerciales y registratarios que realizan transacciones financieras en línea. Esta ha sido una pregunta abierta en el Informe inicial del Grupo de Trabajo, ya que en ese entonces varios miembros del Grupo de Trabajo habían respaldado dicha distinción. Como resultado de las deliberaciones más detalladas del Grupo de Trabajo después de la revisión de los comentarios públicos recibidos, el Grupo de Trabajo llegó a un consenso sobre una recomendación de que no se realizara dicha distinción con fines de acreditar los servicios.
  
  También se han expresado inquietudes respecto de la necesidad de garantizar que existan medidas de protección implementadas para mantener la privacidad de los datos de los clientes y que se logre un equilibrio entre una necesidad legítima de acceso a la información (por ejemplo, por los agentes del orden público y los titulares de derechos de propiedad intelectual) y la necesidad de proteger la privacidad. Muchos comentarios públicos recibidos en respuesta al Informe inicial del Grupo de Trabajo también destacaron los posibles peligros de divulgar información privada sin causa, incluida la amenaza a la seguridad física de ciertos grupos de registratarios de nombres de dominio y clientes de servicios de privacidad/representación. Las recomendaciones finales del Grupo de Trabajo incluyen varios principios y políticas sugeridos que apuntan a brindar pautas más concretas de las que existen actualmente para los servicios de privacidad y representación (proxy), terceros solicitantes de información de clientes y registratarios de nombres de dominio en relación con temas tales como el manejo de notificaciones al cliente, solicitudes de información y transferencias de nombres de dominio.
  
  El Grupo de Trabajo también recibió diversos comentarios respecto de la falta de un marco detallado para la presentación y el manejo confidencial de solicitudes de divulgación de autoridades del orden público, incluso del Grupo de Trabajo de Seguridad Pública del GAC. En su informe inicial, el Grupo de Trabajo solicitó aportes de la comunidad sobre la pregunta en cuanto a si y de qué manera podría desarrollarse dicho marco así como sobre preguntas más específicas tales como si debería ser obligatorio que los proveedores acreditados cumplan con solicitudes expresas de autoridades del orden público en la jurisdicción del proveedor de no notificar a un cliente. En función de los aportes recibidos, el Grupo de Trabajo acordó que los proveedores de servicios de privacidad y representación (proxy) acreditados cumplan con las solicitudes expresas de las autoridades del orden público de no notificar a un cliente cuando esto es exigido por la ley aplicable. Los proveedores serían libres de adoptar voluntariamente normas más estrictas o cooperar de alguna otra forma con las autoridades del orden público. El Informe Final del Grupo de Trabajo también contiene una sugerencia para ciertos requisitos mínimos que podrían incluirse si dicho marco se elaborara durante la etapa de implementación de las recomendaciones de PDP adoptadas.
  
  ¿Qué materiales significativos analizó la Junta Directiva?
  
  La Junta Directiva revisó el Informe Final del Grupo de Trabajo de PDP, el Informe de Recomendaciones del Consejo de la GNSO sobre el tema a la Junta Directiva, el resumen de comentarios públicos recibidos en respuesta al período de comentario público que se abrió después de la adopción por parte del Consejo de la GNSO de las recomendaciones contenidas en el Informe Final, y el asesoramiento recibido del GAC al respecto, según lo estipulado en los comunicados pronunciados en Marrakech y Helsinki.
  
  ¿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 mayoría calificada del Consejo obliga a la Junta Directiva a adoptar las recomendaciones, a menos que, por el voto de más de dos tercios, la Junta Directiva determine que tal política recomendada no responde a los mejores intereses de la ICANN o de su comunidad.
  
  Asimismo, los Estatutos permiten aportes del GAC en relación a las inquietudes de política pública que pueden plantearse si la Junta Directiva adopta una política propuesta. El GAC había planteado esta posibilidad respecto de este PDP y la Junta Directiva seguirá considerando el asesoramiento que el GAC brindó.
  
  ¿Existen impactos positivos o negativos para la comunidad?
  
  El desarrollo de un programa de acreditación de proveedores de servicios de privacidad y representación (proxy) requerirá recursos significativos y tomará un tiempo sustancial. Es probable que la especificación provisoria contenida en el RAA de 2013 deba ser extendida más allá de su fecha de vencimiento actual del 1 de enero de 2017, a fin de permitir el desarrollo de dicho programa.
  
  La implementación de las recomendaciones de la GNSO dará como resultado un conjunto más uniforme de estándares para muchos aspectos de los servicios de privacidad y representación (proxy), incluidos procedimientos más consistentes para el manejo, procesamiento y determinación de solicitudes de terceros por proveedores acreditados, en los cuales se puedan incorporar medidas de protección razonables para proteger la privacidad de los consumidores y se puedan abordar inquietudes de política pública señaladas por el GAC en la medida de lo posible. En la actualidad, no hay un esquema de acreditación para los servicios de privacidad y representación (proxy) ni se acordó un conjunto de mejores prácticas desarrollado por la comunidad para la prestación de dichos servicios. Este PDP representa un intento de formar una base sólida para el desarrollo e implementación de un marco de acreditación por parte de la ICANN y forma parte de los esfuerzos continuos de la ICANN para mejorar el sistema de WHOIS, incluyendo la implementación de las recomendaciones formuladas por el Equipo de Revisión de WHOIS.
  
  No obstante, como se señaló anteriormente, la implementación de todas las recomendaciones de PDP requerirán mucho tiempo y muchos recursos debido a la escala del proyecto y el hecho de que ésta será la primera vez que la ICANN haya implementado dicho programa para este sector de la industria. Si bien el RAA puede servir como un punto de referencia útil para este programa, el Informe Final del Grupo de Trabajo reconoció que quizá éste no sea el modelo más adecuado por diversos motivos. Garantizar que la planificación de la implementación aborde en la mayor medida posible las inquietudes de política pública que el GAC ha identificado, incluso desarrollar posiblemente un marco de divulgación para las autoridades del orden público, probablemente sea una parte importante del trabajo de implementación.
  
  El Informe Final del Grupo de Trabajo también señala áreas en las que puede requerirse trabajo adicional, lo que podría incrementar la carga de trabajo de la comunidad en el corto plazo. Por ejemplo, se deberá abordar la cuestión de servicios de privacidad y representación (proxy) en el contexto de las transferencias de nombres de dominio en la próxima revisión de la Política de Transferencia entre Registradores.
  
  ¿Se observan impactos fiscales o ramificaciones en la ICANN (plan estratégico, plan operativo, presupuesto), la comunidad o el público?
  
  Pueden haber impactos fiscales en la ICANN asociados con la creación de un nuevo programa de acreditación que abarque específicamente a los proveedores de servicios de privacidad y representación (proxy). El plan de implementación debería considerar los costos y plazos para la implementación. Dado que la especificación provisoria actual del RAA aplicable a dichos servicios vence el 1 de enero de 2017, también se deberá considerar extender su duración después de la adopción de las recomendaciones de PDP.
  
  ¿Se observan cuestiones sobre seguridad, estabilidad o flexibilidad relacionadas con el DNS?
  
  No hay cuestiones sobre la seguridad, estabilidad ni flexibilidad relacionadas con el DNS que puedan atribuirse directamente a la implementación de las recomendaciones de PDP. Si bien la acreditación de los proveedores de servicios de privacidad y representación (proxy) forma parte del esfuerzo general de la ICANN por mejorar el sistema del WHOIS, no afecta ni cambia el protocolo del WHOIS (incluido el traspaso del RDAP nuevo) o las funciones actuales del sistema del WHOIS. El Grupo de Trabajo realizó sus recomendaciones finales con el entendimiento de que la implementación de sus recomendaciones se realizaría en el contexto de cualquier otro cambio técnico o relativo a las políticas al sistema del WHOIS, el cual no está incluido en el alcance de este PDP.
6. Consideración de la recomendación del BGC sobre la Solicitud de Reconsideración 16-3 (.GAY)
  
  Punto eliminado del orden del día.
7. Consideración de la Declaración final del IRP de Dot Registry contra la ICANN
  
  Visto y considerando: Que el 29 de julio de 2016, un Panel (Panel) de Revisión Independiente (IRP) emitió su Declaración Final en el IRP presentado por Dot Registry, LLC (Dot Registry) contra la ICANN (Declaración Final).
  
  Visto y considerando: Que la mayoría del Panel declaró que “las acciones e inacciones de la Junta Directiva no eran congruentes con las Actas Constitutivas y los Estatutos de la ICANN” en 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 la evidencia delante del Panel no respaldaba 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. (Véase Declaración Final, ¶¶ 151-152).
  
  Visto y considerando: Que la mayoría del Panel también declaró que “Dot Registry es la parte prevaleciente” y que la ICANN deberá pagarle USD 235.294,37 una vez que se demuestre que estos costos incurridos hayan sido pagados en su totalidad”. (Id. ¶ 154.)
  
  Visto y considerando: 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”. (Id. en ¶ 153)
  
  Visto y considerando: Que la mayoría del Panel no realizó ninguna recomendación a la Junta Directiva en cuanto a qué acción subsiguiente, si la hubiese, la Junta Directiva debería tomar en aras de la Declaración Final.
  
  Visto y considerando: Que Dot Registry ha indicado en una carta a la Junta Directiva, entre otras cosas, que su “informe de expertos de 90 páginas” es “suficiente y convincente para ayudar a la Junta Directiva a determinar que las solicitudes de Dot Registry deberían haber sido aprobadas en la CPE” y a solicitar que la ICANN “proceda con la contratación con Dot Registry respecto de .INC, .LLC y .LLP. (Véase https://www.icann.org/en/system/files/correspondence/jolles-to-icann-board-06aug16-en.pdf [PDF, 1.5 MB]).
  
  Visto y considerando: Que el Panel consideró y objetó el estándar actual de revisión empleado por el BGC al revisar las Solicitudes de Reconsideración.
  
  Visto y considerando: Que, de acuerdo con el artículo IV, sección 3.21 de los Estatutos de la ICANN, la Junta Directiva ha considerado la Declaración Final.
  
  Resuélvase (2016.08.09.11): La Junta Directiva acepta las conclusiones de la Declaración Final de que: (i) Dot Registry es la parte prevaleciente en el IRP de Dot Registry, LLC contra la ICANN; y (ii) la ICANN deberá pagarle USD 235.294,37 una vez que se demuestre que estos costos incurridos hayan sido pagados en su totalidad.
  
  Resuélvase (2016.08.09.12): La Junta Directiva 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.
  
  Resuélvase (2016.08.09.13): En virtud de la carta reciente recibida de Dot Registry y las inexactitudes fácticas que han sido informadas en los informes publicados en el blog en línea, la Junta Directiva ordena al Secretario, o a quien éste designe, publicar los materiales informativos de la Junta Directiva sobre este asunto en forma simultánea con las resoluciones.
  
  Fundamento de las resoluciones 2016.08.09.11 – 2016.08.09.13
  
  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.
  
  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ó este IRP el 22 de septiembre de 2014, objetando que 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”. (Id. en ¶¶ 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”. (Id. en ¶ 154).
  
  La Junta Directiva ha señalado 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)]”. (Id. en ¶ 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”. (Id. en ¶ 153).
  
  La mayoría del Panel consideró y objetó el estándar actual de revisión empleado por el BGC al revisar las Solicitudes de Reconsideración, indicando que consideró que el estándar que debía aplicar el BGC al “evaluar una Solicitud de Reconsideración” debería ser: “¿La acción tomada está en conformidad con las Actas, los Estatutos y la [Guía]?” (Id. en ¶ 79). Asimismo, la mayoría del Panel indicó que, al revisar las Solicitudes de Reconsideración, “el BGC debe determinar si la CPE (en este caso, EIU) y el personal de la ICANN respetaron los principios de equidad, transparencia, evitando los conflictos de interés, y la no discriminación tal como lo estipulan las Actas, los Estatutos y la [Guía] de la ICANN” (id. en ¶ 88), y que los terceros tales como la EIU están “obligados a cumplir con las Actas y los Estatutos de la ICANN”. (Id. en ¶ 101).
  
  La Junta Directiva reconoce las declaraciones importantes del Panel respecto del estándar de revisión de las Solicitudes de Reconsideración 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.
  
  Tal como fue requerido, la Junta Directiva ha considerado la Declaración Final. Tal como se ha indicado previamente, la Junta Directiva toma en cuenta muy seriamente los resultados de uno de los mecanismos de responsabilidad más reconocidos de la ICANN.
  
  En consecuencia, y por las razones establecidas en esta resolución y fundamentos, la Junta Directiva ha aceptado la Declaración Final del Panel, tal como se indicó anteriormente.
  
  La Junta Directiva también señala que ha recibido una carta de Dot Registry, con fecha 6 de agosto de 2016, en la que se indica, entre otras cosas, que su “informe de expertos de 90 páginas” es “suficiente y convincente para ayudar a la Junta Directiva a determinar que las solicitudes de Dot Registry deberían haber sido aprobadas en la CPE” y a solicitar que la ICANN “proceda con la contratación con Dot Registry respecto de .INC, .LLC y .LLP”. (Véase Anexo B a los Materiales de Referencia y https://www.icann.org/en/system/files/correspondence/jolles-to-icann-board-06aug16-en.pdf [PDF, 1.5 MB].) La Junta Directiva desea reiterar 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”. (Id. en ¶ 153)
  
  Además, la Junta Directiva señala que existen numerosas otras solicitudes pendientes de estos gTLD (nueve correspondientes a .INC, ocho correspondientes a LLC y tres correspondientes a .LLP), las cuales también deben ser consideradas. En consecuencia, como se señaló anteriormente, la Junta Directiva considerará los próximos pasos antes de tomar cualquier otra acción respecto de las Solicitudes de Reconsideración de Dot Registry o las solicitudes de .INC, .LLC o .LLP.
  
  Por último, la Junta Directiva también señala que han habido informes publicados en blogs en línea sobre lo que expresa realmente la Declaración Final, incluso muchos de los puntos informados han sido inexactitudes fácticas, que han sido identificadas y corregidas en el Anexo C a los Materiales de Referencia en relación con este tema del orden del día.
  
  No se espera que esta acción tenga impacto financiero directo en la organización, si bien podrían existir algunos costos indirectos, tales como el análisis relativo al estándar sobre las Solicitudes de Reconsideració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.
8. Consideración de la solicitud de cancelación de la Solicitud de .HOTEL presentada por S.a.r.l del Dominio de Alto Nivel HOTEL (HTLD)
  
  Visto y considerando: Que Travel Reservations SRL (anteriormente Despegar Online SRL), Famous Four Media Limited, Fegistry LLC, Minds + Machines Group Limited, Donuts Inc. y Radix FZC (colectivamente, las Partes Reclamantes de .HOTEL) han solicitado que la ICANN cancele la solicitud de S.a.r.l del dominio de alto nivel HOTEL (HTLD) respecto de .HOTEL.
  
  Visto y considerando: Que la solicitud de las Partes Reclamantes de .HOTEL se basa en las conexiones comerciales aparentes de Dirk Krischenowski con HTLD, junto con su explotación de la publicación del portal que permitió a las partes acceder a información confidencial de varios solicitantes de nuevos gTLD, incluida información de varias de las Partes Reclamantes de .HOTEL.
  
  Visto y considerando: Que la investigación forense de la ICANN de la publicación del portal determinó que el acceso no autorizado del Sr. Krischenowski a información confidencial no sucedió hasta después de que HTLD presentase su solicitud en 2012 y después de que HTLD decidiera participar en la CPE el 19 de febrero de 2014.
  
  Visto y considerando: Que la ICANN no ha revelado evidencia respecto de que: (i) la información que pueda haber obtenido el Sr. Krischenowski como resultado de la publicación del portal fuera utilizada para respaldar la solicitud de .HOTEL por parte de HTLD; o (ii) cualquier información obtenida por el Sr. Krischenowski permitiera que la solicitud de HTLD prevaleciera en la CPE.
  
  Resuélvase (2016.08.09.14): La Junta Directiva concluye que no se justifica la cancelación de la solicitud de .HOTEL por parte de HTLD.
  
  Resuélvase (2016.08.09.15): La Junta Directiva solicita al Presidente y Director Ejecutivo, o a quien éste designe, que prosiga con el procesamiento de la solicitud de .HOTEL por parte de HTLD.
  
  Fundamento de las resoluciones 2016.08.09.14 – 2016.08.09.15
  
  HTLD y las Partes Reclamantes de .HOTEL presentaron solicitudes para .HOTEL y fueron todas ellas colocadas en un conjunto de solicitudes controvertidas. Como la solicitud de HTLD estaba basada en la comunidad, su solicitud fue invitada a participar en la Evaluación con prioridad de la comunidad (CPE) el 19 de febrero de 2014. HTLD resultó ser la parte prevaleciente en la CPE el 11 de junio de 2014, por lo cual excluyó a las Partes Reclamantes de .HOTEL de seguir el proceso.
  
  Las Partes Reclamantes de .HOTEL han argumentado que la explotación de la publicación del portal del Sr. Krischenowski que permitió que las partes tuvieran acceso a información confidencial de varios solicitantes de nuevos gTLD, incluida información de varias de las Partes Reclamantes de .HOTEL, junto con las aparentes conexiones comerciales del Sr. Krischenowski con HTLD, es motivo para que la ICANN cancele la solicitud de .HOTEL presentada por HTLD.
  
  La investigación forense de la ICANN de la publicación del portal reveló que las credenciales de usuario del Sr. Krischenowski y sus asociados, Oliver Süme y Katrin Ohlmer, fueron responsables de numerosas instancias de presunto acceso no autorizado intencional a información confidencial de otros solicitantes, lo que ocurrió de marzo a octubre de 2014. El Sr. Krischenowski reconoció que tuvo acceso a información confidencial de otros usuarios, pero negó haber actuado de manera impropia o ilícita. Entre otras cosas, el Sr. Krischenowski alegó que no se dio cuenta que la publicación del portal era una anomalía y que utilizó la herramienta de búsqueda de buena fe. El Sr. Krischenowski y sus asociados también certificaron a la ICANN que eliminarían o destruirían toda la información obtenida y afirmaron que no habían usado ni usarían la información obtenida, así como tampoco la transmitirían a terceros.
  
  Con respecto a los reclamos sobre la participación del Sr. Krischenowski con HTLD cuando tuvo acceso a la información confidencial, la ICANN ha sido informada que él no estaba vinculado directamente a la solicitud de .HOTEL presentada por HTLD como contacto autorizado ni como accionista, funcionario o director. El Sr. Krischenowski fue un accionista con el 50 % y director ejecutivo de GmbH del dominio de alto nivel HOTEL, Berlín (GmbH Berlín), la cual era un accionista minoritario (48,8 %) de TTLD.
  
  La ICANN no ha revelado evidencia respecto de que: (i) la información que pueda haber obtenido el Sr. Krischenowski como resultado de la publicación del portal fuera utilizada para respaldar la solicitud de .HOTEL por parte de HTLD; o (ii) cualquier información obtenida por el Sr. Krischenowski permitiera que la solicitud de HTLD prevaleciera en la CPE. HTLD presentó su solicitud en el año 2012, decidió participar en la CPE el 19 de febrero de 2014 y prevaleció en la CPE el 11 de junio de 2014. La primera instancia en la que el Sr. Krischenowski tuvo acceso no autorizado a información confidencial recién ocurrió a principios de marzo de 2014 y sus búsquedas relacionadas con las Partes Reclamantes de .HOTEL recién ocurrieron los días 27 de marzo, 29 de marzo y 11 abril de 2014. Por lo tanto, incluso si se asume que el Sr. Krischenowski obtuvo información confidencial perteneciente a las Partes Reclamantes de .HOTEL, esto no habría tenido ningún impacto en el proceso de CPE para la solicitud de .HOTEL presentada por HTLD. Específicamente, si la solicitud de HTLD cumplió con los criterios de la CPE se basó en la solicitud tal como se presentó en mayo de 2012, o cuando los últimos documentos que enmendaban la solicitud fueron cargados por HTLD el 30 de agosto de 2013 – todo lo cual ocurrió antes de que el Sr. Krischenowski o sus asociados tuvieran acceso a la información confidencial, lo que ocurrió de marzo a octubre de 2014. Además, no hay evidencia o reclamo alguno por las Partes Reclamantes de .HOTEL respecto de que el Panel de CPE haya tenido interacción alguna con el Sr. Krischenowski o HTLD durante el proceso de CPE, el cual comenzó el 19 de febrero de 2014.
  
  En aras de la resolución de la Junta Directiva del 10 de marzo de 2016 en la que se ordena al “Presidente y Director Ejecutivo de la ICANN, o a quien éste designe, llevar a cabo la investigación de las cuestiones alegadas por las Partes Reclamantes de .HOTEL respecto de la configuración del portal tan pronto como sea posible y proporcionar un informe a la Junta Directiva para su consideración después de la finalización de dicha investigación” (véase las resoluciones de la Junta Directiva del 10 de marzo, disponibles en https://www.icann.org/resources/board-material/resolutions-2016-03-10-en#2.a), la ICANN informó a HTLD de la solicitud de las Partes Reclamantes de .HOTEL para cancelar la solicitud de .HOTEL presentada por HTLD, proporcionó a HTLD la oportunidad de responder y solicitó información de HTLD respecto de su asociación con el Sr. Krischenowski. En respuesta, Philipp Grabensee, el actual y único Director Ejecutivo de HTLD, confirmó a la ICANN que, al momento de la conducta objetada, el Sr. Krischenowski erar accionista del 50 % y director ejecutivo de GmbH Berlín, la cual era un accionista minoritario (48,8 %) de HTLD. El Sr. Grabensee también confirmó que el Sr. Krischenowski actuó como consultor de la solicitud de HTLD en el momento en que fue presentada (en el año 2012) y que el Sr. Krischenowski representó a HTLD en tres objeciones por confusión de cadenas de caracteres iniciadas por HTLD en contra de las solicitudes presentadas por Despegar y Booking.com en el año 2013.
  
  El Sr. Grabensee también indicó que, al tener acceso a información privada, el Sr. Krischenowski no actuó en representación de HTLD ni en respaldo de su solicitud de .HOTEL. El Sr. Grabensee señaló que el Sr. Krischenowski no usó la identificación de inicio de sesión de HTLD, no informó al personal de HTLD sobre “su acción”, “no proporcionó la información a la que tuvo acceso” a HTLD o su personal, y el “personal de HTLD no tenía conocimiento sobre la acción del Sr. Krischenwski y no la consintió ni la aprobó”.
  
  Por último, el Sr. Grabensee señaló los siguientes cambios recientes a la relación de HTLD con el Sr. Krischenowski: (i) los servicios de consultoría comercial entre HTLD y el Sr. Krischenowski finalizaron el 31 de diciembre de 2015; (ii) el Sr. Krischenowski renunció a su cargo de director ejecutivo de GmbH Berlín a partir del 18 de marzo de 2016; (iii) la empresa absorbida del Sr. Krischenowski transfirió sus acciones del 50 % en GmbH Berlín a la Sra. Ohlmer ( a través de su empresa absorbida); (iv) GmbH Berlín transferirá sus acciones en HTLD a Afilias plc; y (v) el Sr. Grabensee ahora es el único Director Ejecutivo de HTLD.
  
  La Junta Directiva tuvo la oportunidad de considerar todos los materiales presentados en relación con la solicitud de las Partes Reclamantes de .HOTEL para la cancelación de la solicitud de .HOTEL presentada por HTLD. Con posterioridad a la consideración de toda la información relevante suministrada y por los motivos estipulados en la Resolución y Fundamento, la Junta Directiva ha determinado que no se justifica la cancelación de la solicitud de .HOTEL presentada por HTLD y, por ende, se rechaza la solicitud de las Partes Reclamantes de .HOTEL.
  
  La Junta Directiva toma estos reclamos seriamente y sus miembros han ejercido un juicio independiente al tomar esta decisión, la cual se considera que es en el mejor interés de la organización y de toda la comunidad. No obstante, la Junta Directiva reconoce que, basándose en la información disponible, el Sr. Krischenowski pudo haber realizado algunas acciones inadecuadas en relación con la configuración del portal y la Junta Directiva está considerando si esta conducta debería abordarse directamente con el Sr. Krischenowski.
  
  Esta decisión no tiene un impacto financiero directo en la ICANN y no afectará la seguridad, la estabilidad ni la flexibilidad del sistema de nombres de dominio.
  
  Esta decisión forma parte de las funciones administrativas y organizacionales que no requieren comentario público.

Sesión Ejecutiva - Confidencial:
1. Remuneración de riesgo para el Defensor del Pueblo correspondiente al año fiscal 2016 (FY16)
  
  Visto y considerando: Que, el Comité de Remuneración recomendó que la Junta Directiva aprobase la remuneración de riesgo del Defensor del Pueblo correspondiente al año fiscal 2015 (FY16).
  
  Resuélvase (2016.08.09.16): Por la presente, la Junta Directiva aprueba un pago al Defensor del Pueblo para su remuneración de riesgo correspondiente al FY16.
  
  Fundamento de la resolución 2016.08.09.16
  
  Anualmente, el Defensor del Pueblo tiene la oportunidad de percibir una parte de su compensación según objetivos de desempeño específicos establecidos por la Junta Directiva, a través del Comité de Compensaciones. Esto no sólo incentiva al Defensor del Pueblo a desempeñar sus obligaciones regulares con creces, sino que genera encuentros periódicos durante el año entre éste y los miembros de la Junta Directiva con el fin de garantizar que dicho funcionario esté alcanzando sus metas y satisfaciendo las necesidades de la comunidad de la ICANN.
  
  La puntuación de los objetivos de desempeño del Defensor del Pueblo surge de la propia evaluación del funcionario y de la revisión que realiza el Comité de Remuneración, el cual hace una recomendación a la Junta Directiva.
  
  La puntuación de los objetivos de desempeño anuales del Defensor del Pueblo está en consonancia con los objetivos de la ICANN y ayuda a ampliar el servicio que el Defensor del Pueblo presta a la comunidad de la ICANN. Si bien existe un impacto fiscal a partir de los resultados de la puntuación, dicho impacto ya se encuentra contemplado en el presupuesto anual. Esta acción no tendrá impacto alguno en la seguridad, estabilidad o flexibilidad del DNS.
  
  Esta decisión forma parte de las funciones administrativas y organizacionales que no requieren comentario público.
2. Remuneración de funcionarios
  
  Visto y considerando: Que la atracción y retención de personal altamente cualificado es esencial para las operaciones y deseos de la ICANN para garantizar una remuneración competitiva para el personal.
  
  Visto y considerando: Que los datos de mercado independientes proporcionados por consultores externos expertos en remuneración indican que los incrementos actuales y propuestos a los montos de remuneración para el Presidente de la División Global de Dominios, Asesor Letrado General y Secretario, Director de Finanzas, Director de Operaciones y Director de Tecnologías de la Información, y Vicepresidente Sénior de Desarrollo de Políticas y Gerente General de la Sede Regional de la ICANN en Estambul están dentro del objetivo de la ICANN del 50 al 75 por ciento de la remuneración total en efectivo basado en datos de mercado comparables para los cargos respectivos.
  
  Visto y considerando: Que los datos de mercado independientes proporcionados por consultores externos expertos en remuneración indican que la remuneración actual para el Director de Finanzas está por debajo del objetivo de la ICANN del 50 al 75 por ciento de la remuneración total en efectivo basado en datos de mercado comparables para los cargos respectivos.
  
  Visto y considerando: Que la remuneración del Presidente de la División Global de Dominios, el Asesor Letrado General y Secretario, el Director de Finanzas y el Vicepresidente Sénior de Desarrollo de Políticas y Gerente General de la Sede Regional de la ICANN en Estambul, no ha sido ajustada desde el 1 de julio de 2014.
  
  Visto y considerando: Que los ajustes remunerativos para el Director de Operaciones y el Director de Tecnologías de la Información establecerán un mejor alineamiento con el cronograma de revisión de remuneración de los otros cuatro funcionarios.
  
  Visto y considerando: Que cada uno de los miembros de la Junta Directiva ha confirmado que no está en conflicto con respecto a los paquetes de remuneración para cualquiera de los Funcionarios de la ICANN.
  
  Resuélvase (2016.08.09.17): La Junta Directiva otorga al Presidente y Director Ejecutivo la discrecionalidad para ajustar la remuneración para el año fiscal 2017, a partir del 1 de julio de 2016, de: (i) Akram Atallah, Presidente, GDD; (ii) John Jeffrey, Asesor Letrado General y Secretario; y (iii) David Olive, Vicepresidente Sénior de Desarrollo de Políticas y Gerente General de la Sede Regional de la ICANN en Estambul, de conformidad con el estudio independiente sobre remuneración comparable, sujeto a la limitación de que sus salarios básicos anuales para el año fiscal 2017 no aumentarán más del 6 % de sus salarios básicos actuales.
  
  Resuélvase (2016.08.09.18): La Junta Directiva otorga al Presidente y Director Ejecutivo la discrecionalidad de ajustar la remuneración para el año fiscal 2017, a partir del 1 de julio de 2016, de Xavier Calvez, Director de Finanzas, de conformidad con el estudio independiente sobre remuneración comparable, sujeto a la limitación de que su salario básico anual para el año fiscal 2017 no aumentará más del 10 % de su salario básico anual actual.
  
  Resuélvase (2016.08.09.19): La Junta Directiva otorga al Presidente y Director Ejecutivo la discrecionalidad de ajustar la remuneración para el año fiscal 2017, a partir del 1 de julio de 2016, de Susanna Bennett, Directora de Operaciones, de conformidad con el estudio independiente sobre remuneración comparable, sujeto a la limitación de que su salario básico anual para el año fiscal 2017 no aumentará más del 3% de su salario básico anual actual.
  
  Resuélvase (2016.08.09.20): La Junta Directiva otorga al Presidente y Director Ejecutivo la discrecionalidad de ajustar la remuneración para el año fiscal 2017, a partir del 1 de julio d e2016, de Ashwin Rangan, Director de Tecnologías de la Información, de conformidad con el estudio independiente sobre remuneración comparable, sujeto a la limitación de que su salario básico anual para el año fiscal 2017 no aumentará más del 5% de su salario básico anual actual.
  
  Fundamento de las resoluciones 2016.08.09.16 – 2016.08.09.20
  
  Atraer y retener personal altamente cualificado proporcionando un paquete de remuneración competitivo es crucial para la organización. Un mercado de trabajo que mejore proporcionará más oportunidades disponibles para el personal altamente cualificado fuera de la ICANN.
  
  El Presidente y Director Ejecutivo de la ICANN ha solicitado que se le conceda la facultad de aumentar los salarios básicos para el año fiscal 2017 de: (i) el Presidente de la División Global de Dominios, el Asesor Letrado General y Secretario, y el Vicepresidente Sénior de Desarrollo de Políticas y Gerente General de la Sede Regional de la ICANN en Estambul, hasta un 6 % de sus salarios básicos actuales; (ii) el Director de Finanzas, hasta un 10 % de su salario básico actual; (iii) la Directora de Operaciones, hasta un 3 % de su salario básico actual; y (iv) el Director de Tecnologías de la Información, hasta un 5 % de su salario básico actual. Asimismo, El Presidente y Director Ejecutivo ha informado a la Junta Directiva que pretende también ejercer la misma discreción con respecto a los otros miembros del Equipo Ejecutivo de la ICANN que no sean funcionarios (lo cual no requiere la aprobación de la Junta Directiva).
  
  La ICANN atraviesa una fase crítica que requiere la continuidad de determinadas capacidades y conocimientos especializados, en particular para algunos proyectos clave en curso, incluidos, entre otros, el Programa de Nuevos gTLD, las revisiones de la Afirmación de Compromisos y otras revisiones en curso, la transición de la custodia de la IANA del Gobierno de los Estados Unidos, la expansión del cumplimiento contractual y la optimización de las iniciativas de globalización. Cada uno de estos proyectos requiere de ejecutivos bien informados y capacitados a fin de garantizar el cumplimiento de las metas y los objetivos operativos de la ICANN, así como también la mitigación de riesgos en la mayor medida posible. Respetar la filosofía de empleo de la ICANN y proporcionar remuneraciones competitivas ayudará a garantizar que se cumplan estas metas.
  
  Cabe señalar, sin embargo, que anteriormente se había discutido que el plan era buscar únicamente la autorización para aumentar los salarios de los Funcionarios relevantes cada dos años. El año pasado, la Junta Directiva autorizó al Presidente y Director Ejecutivo a emplear su discreción para ajustar el salario básico de los dos Funcionarios cuya remuneración actual no había sido ajustada desde que comenzaron a trabajar en la ICANN. Estos ajustes se hicieron efectivos el 1 de julio de 2015, que es la misma fecha en la que el resto del personal realiza sus ajustes salariales.
  
  Al intentar alinear mejor el momento de la revisión y los aumentos de la remuneración de todo el personal, se recomienda que los salarios básicos de los Funcionarios sean revisados para ajuste este año y cada año a partir de este momento. Éste es un cambio de la revisión de la remuneración y el ciclo de ajuste actual de dos años de los Funcionarios
  
  La continuidad y retención del personal clave durante fases organizativas fundamentales resulta beneficioso para todos los aspectos de la organización. Por lo tanto, los ajustes salariales previstos en la presente resolución probablemente generarán un impacto positivo en la organización y su esfuerzo por cumplir con su misión, así como en la transparencia y responsabilidad de la organización. Habrá cierto impacto fiscal para la organización, pero ese impacto no tendrá un efecto en el presupuesto general del año fiscal en curso y será cubierto en el presupuesto del año fiscal 2017. Esta resolución no tendrá ningún impacto directo sobre la seguridad, estabilidad y flexibilidad del sistema de nombres de dominio.
  
  Esta decisión forma parte de las funciones administrativas y organizacionales que no requieren comentario público.

ICANN

Get Started

News and Media

Policy

Public Comment

Resources

Community

Quicklinks

Resoluciones aprobadas por la Junta Directiva | Reunión Extraordinaria de la Junta Directiva de la ICANN 9 de agosto de 2016

Orden del día convenido:

Aprobación de las actas de la reunión

Orden del día principal:

Carta orgánica del Comité de Revisión de la Evolución de la Zona Raíz (RZERC)

Fundamento de las resoluciones 2016.08.09.02 – 2016.08.09.03

Actas Constitutivas de la PTI

Fundamento de la resolución 2016.08.09.04

Acuerdo con la Entidad encargada del mantenimiento de la Zona Raíz

Fundamento de la resolución 2016.08.09.05

Actas Constitutivas Reformuladas de la ICANN

Fundamento de las resoluciones 2016.08.09.06 – 2016.08.09.07

Recomendaciones de políticas de la GNSO sobre la acreditación de servicios de privacidad y representacióin (proxy)

Fundamento de las resoluciones 2016.08.09.08 – 2016.08.09.10

Consideración de la recomendación del BGC sobre la Solicitud de Reconsideración 16-3 (.GAY)

Consideración de la Declaración final del IRP de Dot Registry contra la ICANN

Fundamento de las resoluciones 2016.08.09.11 – 2016.08.09.13

Consideración de la solicitud de cancelación de la Solicitud de .HOTEL presentada por S.a.r.l del Dominio de Alto Nivel HOTEL (HTLD)

Fundamento de las resoluciones 2016.08.09.14 – 2016.08.09.15

Sesión Ejecutiva - Confidencial:

Remuneración de riesgo para el Defensor del Pueblo correspondiente al año fiscal 2016 (FY16)

Fundamento de la resolución 2016.08.09.16

Remuneración de funcionarios

Fundamento de las resoluciones 2016.08.09.16 – 2016.08.09.20