Skip to main content
Resources

Resoluciones Propuestas de la Junta Directiva | Asamblea Ordinaria de la Junta Directiva de la ICANN

Esta página está disponible en:

Este documento ha sido traducido a varios idiomas como información únicamente. El texto original y válido (en inglés) se puede obtener en: http://www.icann.org/en/groups/board/documents/resolutions-18may13-en.htm

 

  1. Orden del día convenido
    1. Aprobación de las actas de las reuniones de la Junta Directiva
    2. Plazo para la aprobación del Presupuesto del Año Fiscal 2014
      1. Fundamento de las resoluciones 2013.05.18.02 – 2013.05.18.03
    3. Sede de la reunión de la ICANN a realizarse en octubre de 2014 en América del Norte
      1. Fundamento de las resoluciones 2013.05.18.04 – 2013.05.18.06
    4. Propuesta de ACDR para desempeñarse como proveedor de servicios de UDRP
      1. Fundamento de la Resolución 2013.05.18.07
  2. Orden del día principal
    1. Asesoramiento del SSAC sobre Certificados de Nombre Internos
      1. Fundamento de las resoluciones 2013.05.18.08 – 2013.05.18.11
    2. Solicitud presupuestaria del SSAC
      1. Fundamento de la Resolución 2013.05.18.12
  3. Sesión Ejecutiva
    1. Compensación de riesgo del Director Ejecutivo
      1. Fundamento de las resoluciones 2013.05.18.13 – 2013.05.18.14
    2. Resolución confidencial
      1. Fundamento de las resoluciones 2013.05.18.15 – 2013.05.18.18

 

  1. Orden del día convenido:

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

      Resuélvase (2013.05.18.01): Por la presente, la Junta Directiva aprueba el acta de la reunión de la Junta Directiva de la ICANN celebrada el 11 de abril de 2013.

    2. Plazo para la aprobación del Presupuesto del Año Fiscal 2014

      Visto y considerando que, el Presupuesto para el Año Fiscal 2014 se encuentra publicado dentro de un período de comentario público cuya fecha de cierre es el 20 de junio de 2013.

      Visto y considerando que, la ICANN suele aprobar el presupuesto de cada año durante sus reuniones públicas.

      Visto y considerando que, este año, la reunión de mitad de año de la ICANN a realizarse en Durban, Sudáfrica, entre el 14 y el 18 de julio de 2013, tendrá lugar una vez comenzado el Año Fiscal 2014, el cual comienza el 1 de julio de 2014.

      Resuélvase (2013.05.18.02): La Junta Directiva de la ICANN tiene la intención de aprobar el Presupuesto para el Año Fiscal 2014 durante la reunión pública de la ICANN en Durban, Sudáfrica.

      Resuélvase (2013.05.18.03): Para el período que comienza el 1 de julio de 2013 hasta la fecha en que la Junta Directiva apruebe el Presupuesto para el Año Fiscal 2014, la Junta Directiva instruye al Presidente y Director Ejecutivo a gestionar el funcionamiento de la ICANN en consonancia con el Presupuesto para Año Fiscal 2014 publicado para comentario público.

      Fundamento de las resoluciones 2013.05.18.02 – 2013.05.18.03

      Según los Estatutos de la ICANN, el presupuesto correspondiente a un año en particular debe ser aprobado al final del año fiscal precedente (30 de junio). Históricamente, esta aprobación tiene lugar durante la última reunión pública de la ICANN realizada durante el año fiscal (reunión de mitad de año), la cual se suele agendar a fin del mes de junio. Este año, la reunión de mitad de año se llevará a cabo entre el 14 y el 18 de julio de 2013, es decir, en el próximo año fiscal.

      La fecha de cierre del foro de comentario público sobre el Presupuesto para el Año Fiscal 2014 está programada para el 20 de junio de 2013. Dado que esa fecha se encuentra a solo diez días de la finalización del año fiscal, hay poco tiempo para garantizar la revisión y consideración de todos los comentarios públicos (lo cual incluye cualquier cambio potencial al borrador del presupuesto incorporado tras la revisión del comentario público) antes de la presentación del presupuesto ante la Junta Directiva para su consideración. Asimismo, varios miembros de la comunidad de la ICANN han manifestado que prefieren que cada presupuesto de la ICANN sea aprobado durante una reunión pública de la ICANN.

      Con el fin de contar con el tiempo suficiente para la revisión de los comentarios públicos y la consideración por parte de la Junta Directiva de los comentarios sobre el presupuesto, el personal le recomendó al Comité de Finanzas de la Junta Directiva (BFC) que el Presupuesto para el Año Fiscal 2014 fuese aprobado por la Junta Directiva durante la reunión de realizarse en Durban. El BFC estuvo de acuerdo y recomendó que la Junta Directiva resolviese aprobar el Presupuesto para el Año Fiscal 2014 en Durban. Esta acción mejora la responsabilidad de la Junta Directiva ante la comunidad, en tanto que la Junta Directiva está respondiendo a las preferencias expresadas por la comunidad de que la aprobación del presupuesto se realice durante una reunión pública, a la vez que asegura que la Junta Directiva cuente con el tiempo suficiente para considerar los aportes de la comunidad antes de adoptar una decisión respecto del Presupuesto para el Año Fiscal 2014.

      Con el fin de permitir que la ICANN funcione desde el comienzo del Año Fiscal 2014, el cual se inicia el 1 de julio de 2014, hasta la fecha en la cual la Junta Directiva apruebe el Presupuesto para el Año Fiscal 2014, el personal requiere la autorización de la Junta Directiva. Por lo tanto, la Junta Directiva autoriza al Presidente y Director Ejecutivo y a ejercer su gestión durante este periodo de conformidad con el Presupuesto para el Año Fiscal 2014 publicado para comentario público. Esta acción permitirá que la ICANN continúe en funcionamiento mientras esté pendiente la aprobación del Presupuesto para el Año Fiscal 2014.

      La otra alternativa en esta instancia sería que la Junta Directiva adoptara una decisión al 30 de junio de 2013 fuera del marco de una reunión pública. Lo anterior no fue considerado como una opción deseada en virtud de todas las circunstancias.

      Como la demora en la aprobación del presupuesto está acompañada de una medida que permite la continuidad del funcionamiento de la ICANN, no es de esperar que tenga un impacto material sobre las operaciones fiscales planificadas por la organización o sobre la comunidad. Esta decisión no tiene ningún impacto sobe la seguridad, estabilidad o flexibilidad del DNS.

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

    3. Sede de la reunión de la ICANN a realizarse en octubre de 2014 en América del Norte

      Visto y considerando que, la ICANN tiene la intención de celebrar su tercera reunión del 2014 en la región de América del Norte, de conformidad con sus políticas y en consonancia con la resolución de la Junta Directiva del 20 de diciembre de 2012 sobre las sedes de las reuniones a realizarse en 2014.

      Visto y considerando que, el personal ha finalizado una revisión exhaustiva de todas las sedes disponibles para realizar reuniones en América del Norte y considera que la sede de Los Ángeles, California, es la sede más adecuada.

      Visto y considerando que, el Comité de Participación Pública y Participación de Partes Interesadas concuerda en que la ciudad de Los Ángeles, California, sea la sede de la reunión a realizarse en América del Norte en el 2014.

      Resuélvase (2013.05.18.04): La Junta Directiva aprueba a la ciudad de Los Ángeles, California, como sede para la reunión pública de la ICANN a realizarse en América del Norte en 2014, programada entre el 12 y el 17 de octubre de 2014.

      Resuélvase (2013.05.18.05): La Reunión Pública de la ICANN a llevarse a cabo en el 2014 en la ciudad de Los Ángeles queda designada como Reunión Púbica Anual de la ICANN para el 2014.

      Resuélvase (2013.05.18.06): La Junta Directiva reafirma su resolución con fecha 20 de diciembre de 2012 autorizando al Presidente y Director Ejecutivo a realizar todas las gestiones necesarias para llevar a cabo las reuniones de la ICANN en el 2014, lo cual incluye todas las contrataciones y los desembolsos necesarios.

      Fundamento de las resoluciones 2013.05.18.04 – 2013.05.18.06

      De conformidad con sus Estatutos, la ICANN organiza tres reuniones públicas por año en diferentes regiones geográficas del mundo. La reunión No. 51, programada para el 12 al 17 de octubre de 2014, se realizará en la región geográfica de Norteamérica. El personal identificó sedes disponibles y adecuadas, y realizó un análisis exhaustivo de las sedes con el fin de garantizar que cumplan con los Criterios para la Selección de Sedes de Reuniones. Sobre la base de dicho análisis, el personal recomendó que la reunión No. 51 de la ICANN se lleve a cabo en Los Ángeles, California.

      La Junta Directiva revisó la recomendación del personal para realizar la reunión en Los Ángeles, California, y determinó que la propuesta cumplía con los factores significativos de los criterios de selección de la reunión utilizados para guiar el trabajo de selección del sitio. El proceso de selección de este sitio no requiere consulta pública, puesto que la principal consideración es la evaluación de factibilidad cualquier sitio realizada por el personal.

      Las sedes de las reuniones a realizarse en marzo del 2014 (Singapur) y junio de 2014 (Londres) fueron aprobadas por la Junta Directiva el 20 de diciembre de 2012. A título comparativo, el presupuesto para las instalaciones y la producción de la reunión a realizarse en Singapur no ha de superar los US$885.000; el presupuesto para las instalaciones y la producción de la reunión a llevarse a cabo Londres no ha de superar los US$734.000; y el presupuesto para las instalaciones y la producción de la reunión a llevarse a cabo en Los Ángeles no ha de superar los US$568.000. Estas cifras no incluyen otros costos relativos a las reuniones.

      Habrá un impacto financiero en la ICANN por desempeñarse como anfitriona de la reunión y proporcionar apoyo para los viajes, según fuera necesario, así como en la comunidad por los costos de viaje a la reunión. Sin embargo, dicho impacto deberá afrontarse independientemente de donde se lleve a cabo la reunión. No habrá impactos en la seguridad ni en la estabilidad del Sistema de Nombres de Dominio (DNS) a causa de ser los anfitriones de la reunión.

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

    4. Propuesta de ACDR para desempeñarse como proveedor de servicios de UDRP

      Visto y considerando que, el Centro Árabe para la Resolución de Disputas (ACDR) presentó una propuesta ante la ICANN para ser aprobado como proveedor de servicios de UDRP.

      Visto y considerando que, la propuesta del ACDR fue publicada para comentario público el 28 de septiembre de 2010, y una versión revisada de dicha propuesta, que tuvo en consideración los comentarios recibidos, fue publicada el 1 de marzo de 2013; el ACDR ha producido una nueva versión revisada en la cual se aborda una cuestión final planteada en el foro de comentario público el 1 de marzo de 2013.

      Visto y considerando que, la propuesta revisada del ACDR aborda los elementos sugeridos según lo planteado en la Información sobre el Proceso de Aprobación de Proveedores para Servicios de Resolución de Disputas.

      Resuélvase (2013.05.18.07): la Junta Directiva aprueba la solicitud del ACDR para desempeñarse como proveedor de UDRP, y recomienda que el Presidente y Director Ejecutivo, mediante la Oficina del Asesor Jurídico General, entable conversaciones con el ACDR respecto del proceso para la provisión de servicios de UDRP por parte de ACDR.

      Fundamento de la Resolución 2013.05.18.07

      La aprobación por parte de la Junta Directiva de la solicitud de ACDR concluye la labor del ACDR (en colaboración con el personal de la ICANN) en pos de cumplir con los estándares y elementos del proceso de aprobación de los proveedores de Servicios de Política Uniforme de Resolución de Disputas (UDRP) por Nombres de Dominio. Ello mejora la responsabilidad de la ICANN mediante su adhesión a este proceso. Asimismo, la aprobación del primer proveedor de UDRP ubicado en Medio Oriente mejora la responsabilidad de la ICANN ante la comunidad de Internet en su conjunto, mejorando la elección para quienes presenten reclamos por UDRP.

      La propuesta del ACDR había sido publicada en dos oportunidades para la recepción de comentario público. Todos los comentarios recibidos fueron transmitidos al ACDR para su consideración. En algunos de los comentarios contrarios, se planteaban cuestiones como el nivel tarifario, lo cual se encuentra plenamente dentro del ámbito del ACDR. En otros comentarios, se sugirió que la ICANN celebrase contratos con cada uno de sus proveedores de UDRP como forma de requerir uniformidad entre proveedores. Los contratos con proveedores de UDRP nunca fueron un requisito. Sin embargo, respecto de la cuestión de la uniformidad entre proveedores, en la propuesta del ACDR se realizan dos cosas: en primer lugar, se modificaron aquellas áreas resaltadas en las que se percibía el riesgo por falta de uniformidad en la conducta (tales como cuestiones relativas a fechas de inicio y definiciones de escritos); en segundo lugar, en la propuesta ahora se incluye un reconocimiento afirmativo de que la ICANN impone mayores requisitos a los proveedores, y el ACDR cumplirá con dichos requisitos; en tercer lugar, el ACDR ha revisado una parte específica de sus Reglas suplementarias, la cual fuera resaltada por quienes presentaron comentarios por ser un riesgo potencial en materia de uniformidad. Esto representa un avance positivo y contribuye a abordar las preocupaciones respecto de la habilidad a futuro de la ICANN de identificar áreas donde la uniformidad de acción sea parte de sus obligaciones para cumplir con las modificaciones de la ICANN que pudiesen mejorar la uniformidad entre proveedores.

      La consideración por parte de la ICANN de la propuesta del ACDR también pone de relieve la importancia de la responsabilidad ante la comunidad. Luego de que la comunidad haya solicitado la oportunidad de ver nuevamente la propuesta con anterioridad a su aprobación, la Junta Directiva se manifestó de acuerdo y solicitó al personal que procediera con un nuevo período de comentarios. Asimismo, la Junta Directiva solicitó que el personal informase a la comunidad sobre la manera en que concluyó la consideración previa por parte de la ICANN de las cuestiones de uniformidad del proveedor UDRP. Como resultado, se ha preparado un documento informativo, el cual será dado a conocer al público.

      Esta decisión implica un impacto mínimo sobre los recursos de la ICANN, como resultado de su decisión de garantizar la disponibilidad del personal de la ICANN para trabajar con el ACDR en el inicio y mantenimiento de su tarea de proveedor. No se espera un impacto sobre la seguridad, estabilidad o flexibilidad del DNS como resultado de esta decisión.

      La presente acción es una función organizacional y administrativa, respecto de la cual se recibieron comentarios públicos.

  2. Orden del día principal:

    1. Asesoramiento del SSAC sobre Certificados de Nombre Internos

      Visto y considerando que, la delegación de los Dominios de Alto Nivel de los Nombres de Dominio Internacionalizados (IDN TLD) en cierto modo fomenta la seguridad y buena experiencia de los usuarios, lo cual desde hace mucho tiempo representa un tema de importancia para la Junta Directiva de la ICANN y la comunidad mundial.

      Visto y considerando que, el 15 de marzo de 2013, el Comité Asesor de Seguridad y Estabilidad (SSAC) de la ICANN publicó el documento SAC 057: Asesoramiento del SSAC sobre Certificados de Nombre Internos.

      Visto y considerando que, las empresas tienen entornos locales que pueden incluir supuestos respecto de los cuales existen dominios de alto en el nivel de la raíz del DNS público, y/o han introducido dominios locales de alto nivel que pueden estar en conflicto con nombres que aún no se han delegado en el nivel de la raíz del DNS público.

      Visto y considerando que, en virtud de su rol de custodio, la ICANN desea determinar cuáles son estos conflictos potenciales.

      Resuélvase (2013.05.18.08): El 18 de mayo, la Junta Directiva de la ICANN impartió instrucciones al Presidente y Director Ejecutivo para, consultando al SSAC, encomendara un estudio sobre el uso de TLDs que actualmente no se encuentran delegados a nivel de la zona raíz del DNS público en empresas. El estudio debería considerar los impactos potenciales en materia de seguridad de las cadenas de caracteres solicitadas para nuevos gTLDs en relación con este uso.

      Resuélvase (2013.05.18.09): La Junta Directiva solicita al RSSAC que asista a la ICANN en la recolección de datos y en las observaciones relativas a las operaciones del servidor raíz relevantes para el estudio, y a trabajar con los operadores de servidores raíz a los efectos de permitir la puesta en común de tales datos y observaciones según corresponda, con la mayor celeridad posible.

      Resuélvase (2013.05.18.10): La Junta Directiva instruye al Presidente y Director Ejecutivo para que se comunique con el foro de la Autoridad/del Buscador de Certificados a los efectos de recabar estadísticas sobre la distribución de los certificados de nombre internos por dominio de alto nivel, con la mayor celeridad posible.

      Resuélvase (2013.05.18.11): La Junta Directiva solicita al SSAC que considere brindar un mayor asesoramiento sobre su evaluación de las cuestiones identificadas en el estudio de la ICANN, con la mayor celeridad posible.

      Fundamento de las resoluciones 2013.05.18.08 – 2013.05.18.11

      ¿Por qué la Junta Directiva está abordando ahora la cuestión?

      La cuestión de los certificados internos identificada por el SSAC en el documento SAC 057 es un síntoma de que las empresas tienen entornos locales que incluyen supuestos firmes sobre el número estático de dominios de alto nivel y/o han introducido dominios locales de alto nivel que pueden estar en conflicto con nombres que aún no se han asignado. Independientemente de la validez de estos supuestos, con el fin de ejercer su rol de custodio en forma proactiva, la ICANN desea determinar las implicancias en materia de seguridad y estabilidad de estos conflictos potenciales, sobre todo dado que las solicitudes de nuevos gTLDs se encuentran en proceso de evaluación por parte de la ICANN para su delegación en la raíz. Asimismo, este estudio sienta un precedente para futuras rondas potenciales de TLD, en las cuales es necesario realizar estudios similares como una cuestión de debida diligencia.

      ¿Cuáles son las propuestas que se están considerando?

      La Junta Directiva solicita al Presidente y Director Ejecutivo de la ICANN que encomiende un estudio sobre el uso de TLDs que actualmente no se encuentran delegados a nivel de la zona raíz del DNS público en empresas. En el estudio también se considerarían los impactos potenciales en materia de seguridad de las cadenas de caracteres solicitadas para nuevos gTLDs en relación con este uso. Con el fin de llevar a cabo este estudio, la Junta Directiva también está considerando solicitarle al RSSAC que asista a los operadores de la zona raíz en el suministro de estadísticas y observaciones. Por último, la Junta Directiva está considerando solicitarle al SSAC que considere si tiene un mayor asesoramiento para presentar ante la Junta Directiva sobre la base de su análisis de este estudio.

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

      El SSAC presentó el documento "SAC 057: Asesoramiento del SSAC sobre Certificados de Nombre Internos" a la comunidad de la ICANN en Pekín. Como resultado, el SSAC recibió la retroalimentación de la comunidad sobre esta cuestión, y los aportes de la comunidad sirvieron como información para la solicitud del SSAC.

      ¿Qué inquietudes o cuestiones mencionó la comunidad?

      Algunos miembros de la comunidad han planteado sus preocupaciones acerca del uso de los TLDs que actualmente no están delegados en el nivel de la raíz dentro del DNS público, y respecto de su impacto sobre las empresas cuando la ICANN delegue estos TLDs dentro del DNS público. Algunos integrantes de la comunidad han solicitado una evaluación de dichos riesgos con el fin de que la comunidad de la ICANN pueda tomar decisiones sobre la base de mayor información. Algunos integrantes de la comunidad han manifestado que sus estudios indican que no hay riesgo significativo para la seguridad y estabilidad del DNS y han exhortado a la ICANN a continuar con el curso de la evaluación y la eventual delegación de todas las solicitudes de gTLD exitosas, independientemente del conflicto debido a los certificados de nombre internos.

      ¿Qué materiales significativos revisó la Junta Directiva?

      Informe del SSAC sobre Certificados de Nombre Internos1 [PDF, 1.14 MB], Informe del SSAC sobre Consultas Inválidas de Dominios de Alto Nivel en el Nivel de la Raíz del Sistema de Nombres de Dominio (15 de noviembre de 2010, con correcciones)2 [PDF, 507 KB], Informe del Comité Asesor de Seguridad y Estabilidad sobre el Escalamiento de la Zona Raíz (6 de diciembre de 2010)3 [PDF, 175 KB]

      ¿Qué factores considera importantes la Junta Directiva?

      Al adoptar esta acción, la Junta Directiva consideró las recomendaciones presentadas por el SSAC en los documentos SAC 045, 046 y 057.

      ¿Se observan impactos positivos o negativos en la comunidad?

      La acción de la Junta Directiva de impartir instrucciones al personal, mediante el Presidente y Director Ejecutivo, de encomendar un estudio detallado sobre los riesgos relativos al uso de TLDs que actualmente no están delegados en el nivel de la raíz del DNS público en empresas tendrá un impacto positivo sobre la comunidad, ya que redundará en la mejora del entendimiento de esta cuestión al brindar mayor información sobre impactos en materia de seguridad de las cadenas de caracteres de nuevos gTLD solicitadas en relación con este uso. Ello permitirá que la comunidad y la Junta Directiva entiendan en más detalle las preocupaciones potenciales en materia de seguridad y estabilidad si se delegan los TLDs en conflicto, y el impacto sobre la funcionalidad general de Internet. 

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

      No se espera que esta acción tenga un impacto sobre los recursos de la ICANN, e impartir instrucciones para que se realice esta tarea puede resultar en cambios a los planes de implementación para los nuevos gTLDs. Si bien el estudio en sí mismo no tendrá un impacto fiscal sobre la CANN, la comunidad o el público, es posible que el estudio pueda traer a la luz riesgos que conlleven un requisito de implementar ciertas medidas de protección para los gTLDs en conflicto. Asimismo, es posible que algunos nuevos gTLDs no sean elegibles para la delegación.

      ¿Se observa alguna cuestión de seguridad, estabilidad o flexibilidad relacionada con el DNS?

      En el documento SAC057 se han identificado varios riesgos en materia de seguridad para el DNS. El propósito del estudio es presentar una visión más cuantitativa del problema, y brindar información que sirva de base para futuras decisiones.

      La presente es una función organizacional y administrativa respecto de la cual no se requiere comentario público. Sin embargo, es probable que las recomendaciones que surjan del trabajo encomendado mediante esta resolución requieran los aportes de la comunidad antes de ser consideradas por parte de la Junta Directiva.

    2. Solicitud presupuestaria del SSAC

      Visto y considerando que, el 11 de abril de 2013, la Junta Directiva aprobó las solicitudes presupuestarias de las SO y los AC presentadas mediante el Proceso de Avance Acelerado para su inclusión en el Presupuesto del Año Fiscal 2014.

      Visto y considerando que, en su momento, la Junta Directiva no aprobó una solicitud del SSAC relativa a viajes adicionales a la reunión de la ICANN en Durban.

      Resuélvase (2013.05.18.12): La Junta Directiva aprueba la solicitud del SSAC por un monto de US$20.000 para viajes adicionales a la reunión de la ICANN en Durban, a los efectos de su inclusión en el Presupuesto de la ICANN para el Año Fiscal 2014 como parte del Proceso de Avance Acelerado para las Solicitudes Presupuestarias Adicionales de las SO y los AC.

      Fundamento de la Resolución 2013.05.18.12

      El Proceso de Avance Acelerado de las Solicitudes Presupuestarias Adicionales de las SO y los AC conlleva una aprobación presupuestaria antes de lo usual, lo cual resulta en una adaptación razonable para las actividades que comienzan cerca del inicio del AF2014. Este pequeño incremento dentro del proceso y plazo de aprobación presupuestaria establecido dentro de la ICANN contribuye a facilitar el trabajo de la comunidad y del personal de la ICANN, y no genera gastos adicionales.

      Ante la recomendación del Comité de Finanzas de la Junta Directiva, y a la luz del rol específico del SSAC dentro de la ICANN, esta decisión es importante en pos del trabajo sobre la seguridad, estabilidad y flexibilidad del DNS, si bien no es de esperar un impacto directo sobre la seguridad, estabilidad o flexibilidad del DNS como resultado de esta decisión.

      La presente acción es una función organizacional y administrativa, respecto de la cual la ICANN recibió los aportes de la comunidad.

  3. Sesión Ejecutiva:

    1. Compensación de riesgo del Director Ejecutivo

      Visto y considerando que, cada miembro de la Junta Directiva ha confirmado no poseer conflictos de interés con respecto a la fijación del pago a percibir por el Presidente y Director Ejecutivo en concepto de compensación de riesgo para el segundo trimestre del AF 2013.

      Visto y considerando que, el Comité de Compensaciones recomendó a la Junta Directiva aprobar un pago al Presidente y Director Ejecutivo en concepto de compensación de riesgo correspondiente al segundo trimestre del AF2013.

      Resuélvase (2013.05.18.13): La Junta Directiva aprueba un pago al Presidente y Director Ejecutivo en concepto de compensación de riesgo correspondiente al segundo trimestre del AF 2013.

      Resuélvase (2012.05.18.14): Los términos específicos de esta resolución deberán mantenerse bajo confidencialidad por tratarse de una "acción relativa al personal o a cuestiones laborales, en un todo de acuerdo con la Sección 5.2 del Artículo III de los Estatutos de la ICANN.

      Fundamento de la Resolución 2013.05.18.13 – 2013.05.18.14

      Cuando se contrató al Presidente y Director Ejecutivo, se le ofreció un salario básico, y un componente salarial en concepto de compensación de riesgo como parte de su paquete remunerativo. Al igual que el personal de la ICANN, el Presidente y Director Ejecutivo es evaluado sobre la base de metas específicas que él fija junto con el Comité de Compensaciones.

       En Pekín, el Comité de Compensaciones recomendó que la Junta Directiva aprobase la compensación de riesgo del Presidente y Director Ejecutivo para el segundo trimestre del AF 2013, y la Junta Directiva concuerda con dicha recomendación.

      Si bien esto tendrá un impacto fiscal sobre la ICANN, dicho impacto fue contemplado en el presupuesto del AF 2013. Esta decisión no tendrá ningún impacto 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.

    2. Resolución confidencial

      [Se omiten las resoluciones]

      Resuélvase (2013.05.18.18): los términos específicos de esta resolución  [Resoluciones 2013.05.18.15, 2013.05.18.16 y 2013.05.18.17] permanecerán bajo confidencialidad por tratarse de una "acción relativa al personal o a cuestiones laborales", de acuerdo con el Artículo III, sección 5.2 de los estatutos de la ICANN, y la totalidad de la resolución permanecerá bajo confidencialidad de conformidad con la misma disposición estatutaria hasta tanto esté pendiente la determinación por parte del Presidente y Director Ejecutivo de que dicha sección que no reviste confidencialidad pueda tomar carácter público.

      Fundamento de las resoluciones 2013.05.18.15 – 2013.05.18.18

      [Se omiten las resoluciones]


1 Véase http://www.icann.org/en/groups/ssac/documents/sac-057-en.pdf [PDF, 1.14 MB]

2 Véase http://www.icann.org/en/groups/ssac/documents/sac-045-en.pdf [PDF, 507 KB]

3 Véase http://www.icann.org/en/groups/ssac/documents/sac-046-en.pdf [PDF, 175 KB]

resolutions-18may13-es.pdf  [297 KB]

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."