Skip to main content
Resources

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

Esta página está disponible en:

Este documento ha sido traducido a varios idiomas 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-11apr13-en.htm

 

  1. Agenda convenida
    1. Aprobación de las minutas de la Junta Directiva
    2. Enmiendas estatutarias del RSSAC
    3. Centro de oficinas en Estambul, Turquía
    4. Vigencia de las Estructuras de Responsabilidad en los Estatutos
    5. Solicitud de eliminación de propiedad cruzada de .CAT
    6. Confirmación del proceso seguido en relación a la redelegación del dominio .GA en representación de Gabón
    7. Cambio de nombre del Comité de Participación Pública
    8. Solicitud Presupuestaria Acelerada para SO/AC
    9. Resoluciones de agradecimiento – Miembros de la comunidad que se retiran 15
    10. Agradecimiento a los Patrocinadores de la Reunión ICANN46
    11. Agradecimiento a escribas, intérpretes, personal y equipos del evento y del hotel que participaron en la reunión ICANN46
    12. Agradecimiento a los Patrocinadores locales de la Reunión ICANN46
  2. Agenda Principal
    1. Procedimiento para la generación de etiquetas en la raíz para TLD variantes de IDN y recomendaciones del Estudio sobre la experiencia del usuario
    2. Solicitud de PIA-CC para formar una nueva unidad constitutiva 23
    3. Otros temas a tratar

 

  1. Agenda convenida

    1. Aprobación de las minutas de la Junta Directiva

      Queda resuelto (2013.04.11.01), por la presente la Junta Directiva aprueba las minutas de la reunión extraordinaria de la Junta Directiva de la ICANN del día 28 de febrero de 2013.

    2. Enmiendas estatutarias del RSSAC

      Visto y considerando que, en la Resolución 2011.01.25.10 la Junta Directiva aprobó los pasos de implementación del informe final de revisión del Comité Asesor del Sistema de Servidores Raíz (RSSAC) y solicitó al Comité de Mejoras Estructurales (SIC), en coordinación con el personal, que le proporcione un plan de implementación final para abordar las recomendaciones y conclusiones finales del RSSAC.

      Que, en los meses de julio y agosto de 2012, se conformó un grupo de trabajo integrado por miembros del RSSAC y del SIC para redactar una carta estatutaria revisada del RSSAC, con el fin de satisfacer los requisitos de las recomendaciones finales de la revisión de ese Comité. La Carta estatutaria del RSSAC está establecida en la Sección 2.3 del Artículo XI de los Estatutos de la ICANN.

      Que, el 4 de diciembre de 2012, el SIC examinó las revisiones estatutarias propuestas y las recomendaciones, y recomendó que los cambios sugeridos para la Sección 2.3 del Artículo XI fuesen publicados para la recepción de comentarios públicos. La Junta Directiva aprobó la publicación para la recepción de comentarios públicos del día 20 de diciembre de 2012, y el período de comentarios fue abierto el día 3 de enero de 2013. No se recibió ningún comentario.

      Que, el 28 de marzo de 2013 el SIC recomendó a la Junta Directiva adoptar los cambios de la Sección 2.3 del Artículo XI de los Estatutos.

      Queda resuelto (2013.04.11.02), la Junta Directiva aprueba los cambios propuestos para la Sección 2.3 del Artículo XI de los Estatutos de la ICANN, necesarios para modificar la carta estatutaria del RSSAC en concordancia con las recomendaciones planteadas por la revisión organizacional de dicho Comité.

      Fundamentos de la Resolución 2013.04.11.02

      Estas modificaciones de los Estatutos de la ICANN clarificarán el propósito continuo del Comité Asesor del Sistema de Servidores Raíz (RSSAC). Las mismas fueron recomendadas por el Grupo de trabajo conjunto del RSSAC y el SIC, conformado para concluir con la implementación del Informe final del Grupo de trabajo revisor del RSSAC: pasos para la implementación [PDF, 448 KB], aprobado por la Junta Directiva el día 25 de enero de 2011. Las modificaciones estatutarias propuestas fueron publicadas para la recepción de comentarios públicos, y no se recibieron comentarios en respuesta. La ausencia de comentarios públicos indica que tales modificaciones son deseables para que el RSSAC mejore su eficacia en el entorno actual. Las revisiones estatutarias están redactadas para permitir el tiempo suficiente para que el RSSAC coordine los nuevos términos de mandato de sus miembros, conforme lo requerido en virtud de los Estatutos, con el primer período completo en virtud de los nuevos Estatutos comenzando a partir del 1 julio de 2013.

      La aprobación de estas revisiones estatutarias constituye una función administrativa y organizacional para la cual se solicitaron comentarios públicos. Si bien la aprobación de las modificaciones estatutarias no tienen consecuencias presupuestarias per se, se espera que dichas revisiones estatutarias induzcan gastos del RSSAC. Fortalecido por la enmienda estatutaria revisada, el RSSAC contribuirá al fortalecimiento de la seguridad, estabilidad y flexibilidad del DNS (Sistema de Nombres de Dominio).

      Esta medida forma parte de las funciones administrativas y organizacionales de la ICANN, para la cual se recibieron comentarios públicos.

    3. Centro de oficinas en Estambul, Turquía

      Queda resuelto (2013.04.11.03), el Presidente y CEO está autorizado a implementar ya sea las resoluciones relativas a una oficina de enlace o las resoluciones relativas a una oficina filial —según las consideradas más adecuadas por parte del Presidente y CEO—, así como a abrir cualquier cuenta bancaria necesaria para respaldar la oficina en Turquía.

      (i) Visto y considerando que, la Corporación de Asignación de Nombres y Números de Internet, una entidad jurídica debidamente constituida y existente bajo las leyes del Estado de California y los Estados Unidos de América, que tiene su centro de actividad principal en 12025 E. Waterfront Drive, Suite 300, Los Ángeles, California 90094 EE.UU. ("ICANN"), ha decidido establecer una oficina filial en Estambul, Turquía ("Oficina Filial").

      Queda resuelto (2013.04.11.04), David Olive, con pasaporte de Estados Unidos número [OCULTO], es designado como el representante de la Oficina Filial con todas y cada una de las capacidades para actuar de forma individual en nombre de la Oficina Filial ante —incluyendo pero no limitándose a— cualquiera y todos los tribunales e instituciones privadas y públicas.

      (ii) Visto y considerando que, la Corporación de Asignación de Nombres y Números de Internet, una entidad jurídica debidamente constituida y existente bajo las leyes del Estado de California y los Estados Unidos de América, que tiene su centro de actividad principal en 12025 E. Waterfront Drive, Suite 300, Los Ángeles, California 90094 EE.UU. ("ICANN"), ha decidido establecer una oficina de enlace en Estambul, Turquía ("Oficina de Enlace").

      Queda resuelto (2013.04.11.05), David Olive, [información de identificación personal OCULTA], es designado como el representante de la Oficina de Enlace con todas y cada una de las capacidades para actuar de forma individual en nombre de la Oficina de enlace ante —incluyendo pero no limitándose a— cualquiera y todos los tribunales e instituciones privadas y públicas.

      Fundamentos de las resoluciones 2013.04.11.03 – 2013.04.11.05

      La ICANN se ha comprometido a continuar ampliando su alcance y presencia a nivel global, en todas las zonas horarias de todo el mundo. Uno de los aspectos clave de la internacionalización de la ICANN es el establecimiento de oficinas en Turquía y Singapur. Otro aspecto clave de la internacionalización de la ICANN es asegurar que no todos los miembros de la gerencia principal de la ICANN se encuentren en la oficina de Los Ángeles. A tales efectos, uno de los funcionarios de la ICANN, David Olive, ha acordado trasladarse a Estambul y ser el representante de la filial designada.

      A fin de establecer formalmente una oficina en Estambul, la ICANN debe registrarse para hacer negocios en Turquía. La registración para hacer negocios en Turquía requiere de una resolución específica de la Junta Directiva, estableciendo la filial y el representante de la filial, razón por la cual la Junta ha aprobado esta resolución.

      El establecimiento de oficinas alrededor del mundo será un paso positivo para la comunidad de la ICANN, ya que proporcionará un alcance global más amplio para todos los miembros de la comunidad. Habrá un impacto fiscal sobre la ICANN, el cual ha sido considerado en el presupuesto FY13, y se tendrá en cuenta al aprobar el presupuesto FY14 y en forma posterior. Esta resolución no tiene el propósito de tener ningún impacto sobre la seguridad, estabilidad y flexibilidad del DNS, excepto que podría proporcionar una cobertura adicional a nivel mundial que podría ayudar más rápidamente a abordar cualquier problema de seguridad, estabilidad o flexibilidad.

      Esta medida forma parte de las funciones administrativas y organizacionales de la ICANN que no requieren de comentarios públicos.

    4. Vigencia de las Estructuras de Responsabilidad en los Estatutos

      Visto y considerando que, las recomendaciones 23 y 25 del Equipo Revisor de Responsabilidad y Transparencia indican que la ICANN contrate expertos independientes para revisar las estructuras de responsabilidad de la ICANN y el trabajo histórico realizado en esas estructuras.

      Que, la ICANN convocó a un Panel de Expertos en Estructuras de Responsabilidad (ASEP), integrado por tres expertos internacionales en temas de gobernanza corporativa, responsabilidad y resolución de disputas internacionales, el cual luego de investigar y examinar los procesos de Reconsideración y Revisión Independiente de la ICANN —y luego de múltiples oportunidades para la participación pública—, generó un informe en el mes de octubre de 2012.

      Que, el informe del ASEP fue publicado para la recepción de comentarios públicos, conjuntamente con las revisiones estatutarias propuestas para abordar las recomendaciones de dicho informe.

      Que, posteriormente a que el ASEP y la Junta Directiva examinasen y considerasen los comentarios públicos recibidos, el 20 de diciembre de 2012, la Junta aprobó la revisión de los Estatutos para dar efecto a las recomendaciones del ASEP, e indicó la labor adicional de implementación seguida por una recomendación del personal respecto a la fecha de vigencia de los Estatutos revisados.

      Que, conforme lo contemplado en la resolución de la Junta Directiva y tal como se refleja en los comentarios públicos, es necesario realizar revisiones menores adicionales a los Estatutos a fin de proporcionar flexibilidad en la composición de un panel permanente para el proceso de Revisión Independiente (IRP).

      Queda resuelto (2013.04.11.06), las revisiones de la Sección 2, Artículo IV (Reconsideración) y de la Sección 3, el Artículo IV (Revisión Independiente), son aprobadas por la Junta Directiva —sujetas a una pequeña modificación para hacer frente a los comentarios del público con respecto a la composición de un panel permanente de IRP— y se hará efectiva el día 11 de abril de 2013.

      Fundamentos de la Resolución 2013.04.11.06

      La medida de la Junta Directiva al aceptar el informe del Grupo de Expertos en Estructuras de Responsabilidad (ASEP) y la aprobación de las modificaciones estatutarias concomitantes son para promover el compromiso de la Junta hacia la actuación sobre las recomendaciones del Equipo Revisor de Responsabilidad y Transparencia (ATRT). La labor del ASEP fue solicitada para atender las Recomendaciones 23 y 25 del ATRT, y el trabajo realizado —incluyendo una revisión de las recomendaciones derivadas de la labor del Comité de Estrategia del Presidente sobre la mejora de la confianza institucional—, está directamente alineado con la revisión solicitada por el ATRT.

      La aprobación del trabajo del ASEP representa un gran paso en el compromiso de la ICANN sobre la responsabilidad y rendición de cuentas a la comunidad. Los mecanismos revisados aprobados hoy generarán un acceso más fácil a los procesos de Revisión Independiente y Reconsideración mediante la implementación de formas, el establecimiento de términos definidos para eliminar la vaguedad y la capacidad de presentar peticiones colectivas. Se añade un nuevo motivo de Reconsideración, lo cual aumenta la capacidad de la comunidad para buscar que la Junta Directiva se mantenga responsable por sus decisiones. Las revisiones están dirigidas hacia el establecimiento de una mayor previsibilidad en los procesos, y la seguridad en la toma de decisiones de la ICANN, siendo al mismo tiempo más claro cuando una decisión es susceptible de ser revisada. Los Estatutos, ulteriormente revisados, también abordan una potencial área de preocupación planteada por la comunidad durante los comentarios públicos sobre esta cuestión, en relación con la capacidad de la ICANN para mantener un panel permanente para el proceso de Revisión Independiente. De no poder constituirse un panel permanente, o de no permanecer constituido, los Estatutos permiten ahora que los procedimientos de Revisión Independiente sigan adelante con los panelistas seleccionados en forma individual.

      La adopción de estas recomendaciones tendrá un impacto fiscal sobre la ICANN, en cuanto a la existencia de costos esperados asociados con el mantenimiento de un Presidente del panel permanente para el proceso de Revisión Independiente y los potenciales costos para retener a otros miembros del panel. Sin embargo, se espera que las recomendaciones den lugar a procedimientos menos costosos y que requieran de menor cantidad de tiempo, lo cual será positivo para la ICANN, la comunidad y para aquellos que soliciten una revisión en virtud de estas estructuras de responsabilidad. Se espera que los resultados de este trabajo tengan impactos positivos sobre la ICANN y la comunidad relacionados a una mayor disponibilidad de los mecanismos de responsabilidad. No se prevé que exista ningún impacto sobre la seguridad, la estabilidad o la flexibilidad del DNS como consecuencia de esta medida.

      Esta medida forma parte de las funciones administrativas y organizacionales de la Junta Directiva de la ICANN, para la cual se recibieron comentarios públicos.

    5. Solicitud de eliminación de propiedad cruzada de .CAT

      Visto y considerando que, en el mes de diciembre de 012, Fundació puntCAT solicitó la remoción de las restricciones de propiedad cruzada plasmadas en el contrato firmado el 23 de septiembre de 2005 entre la ICANN y Fundació puntCAT.

      Que, la solicitud cumplió con el "Proceso para la gestión de solicitudes para la eliminación de restricciones a la propiedad cruzada de los operadores de gTLD existentes", adoptada por la Junta Directiva el día 18 de octubre de 2012.

      Que, la ICANN llevó a cabo una revisión en materia de competencia de conformidad con el proceso aprobado por la Junta Directiva, y determinó que la solicitud no presenta cuestiones significativas en cuanto a competencia.

      Que, un período para la recepción de comentarios públicos tomó lugar entre el 22 de diciembre 2012 y el 11 de febrero de 2013 y únicamente se recibió un comentario, emitido en apoyo a la solicitud de la Fundació puntCAT.

      Queda resuelto (2013.04.11.07), se aprueba una enmienda para eliminar la restricción de propiedad cruzada en el Acuerdo de Registro de la Fundació puntCAT firmado el 23 de septiembre de 2005, y se autoriza al Presidente y CEO y al Asesor Jurídico a implementar las medidas necesarias para la implementación de dicha modificación.

      Fundamentos de la Resolución 2013.04.11.07

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

      La eliminación de propiedad cruzada en los registros existentes ha sido objeto de amplios debates por parte de la Junta Directiva y de la comunidad. Esta es la primera vez que un registro existente la ha solicitado, de conformidad con el procedimiento aprobado por la Junta Directiva, aprobado el día 18 de octubre de 2012. Sin embargo, es probable que más adelante la Junta Directiva reciba solicitudes adicionales. En virtud del proceso aprobado por la Junta Directiva en el mes de octubre de 2012 y para eliminar las restricciones a la propiedad cruzada, los operadores de registro de gTLD (dominios genéricos de nivel superior) existentes pueden bien solicitar una enmienda a su Acuerdo de Registro existente o solicitar una transición a la nueva forma del Acuerdo de Registro para nuevos gTLDs. Aunque Fundació puntCAT solicitó una enmienda a su Acuerdo de Registro, aún se le ofrecerá la oportunidad de hacer la transición a la nueva forma del Acuerdo de Registro para los nuevos gTLDs. La remoción de las restricciones a la propiedad cruzada de .BIZ, .INFO y .ORG están siendo consideradas como parte de las negociaciones generales de renovación. La ICANN también está en conversaciones preliminares con .MOBI y .PRO respecto a la eliminación de las restricciones a la propiedad cruzada.

      ¿Cuál es la propuesta que se somete a consideración?

      Una enmienda al Acuerdo de Registro celebrado el día 23 de septiembre 2005 entre la ICANN y la Fundació puntCAT.

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

      Un período para la recepción de comentarios públicos tomó lugar entre el 22 de diciembre 2012 y el 11 de febrero de 2013. 

      ¿Qué inquietudes o cuestiones mencionó la comunidad?

      Sólo se recibió un comentario durante el período de comentarios públicos. El comentario se emitió a favor de la solicitud de la Fundació puntCAT.

      ¿Qué factores considera importantes la Junta Directiva?

      La ICANN llevó a cabo una revisión en materia de competencia de acuerdo con el proceso aprobado por la Junta Directiva para gestionar las solicitudes para la eliminación de restricciones a la propiedad cruzada en los Acuerdos de Registro. La ICANN determinó que la solicitud no plantea cuestiones de competencia significativas.

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

      No existe impacto fiscal sobre la ICANN.

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

      No se han identificado cuestiones sobre seguridad, estabilidad o flexibilidad.

      ¿Constituye esta medida un proceso de políticas definido dentro de las Organizaciones de apoyo de la ICANN o de la función administrativa y organizacional de dicha Corporación, que requiera o no de la recepción de comentarios públicos?

      Esta solicitud ha cumplido con el "Proceso para la gestión de solicitudes para la eliminación de restricciones a la propiedad cruzada de los operadores de gTLD existentes", adoptada por la Junta Directiva el día 18 de octubre de 2012.

      Esta medida forma parte de las funciones administrativas y organizacionales de la ICANN, para la cual se recibieron comentarios públicos.

    6. Confirmación del proceso seguido en relación a la redelegación del dominio .GA en representación de Gabón

      Queda resuelto (2013.04.11.08), la ICANN ha examinado y evaluado la solicitud, así como la documentación que demuestra el proceso de redelegación, estando la misma en el interés de las comunidades de Internet, tanto a nivel local como mundial.

      Fundamentos de la Resolución 2013.04.11.08

      Como parte de las funciones de la IANA (Autoridad de Números Asignados en Internet), la ICANN recibe la solicitud de delegación y redelega los código de país de dominios de nivel superior. El Personal de la ICANN ha revisado y evaluado una solicitud de redelegación para este dominio y ha suministrado un informe a la Junta Directiva de la ICANN indicando que en esta evaluación se siguieron los procedimientos adecuados. La supervisión del proceso por parte de la Junta Directiva ayuda a garantizar que la ICANN ejecute sus responsabilidades correctamente respecto al funcionamiento estable y seguro de sistemas de identificadores únicos y fundamentales de Internet, de conformidad con el Contrato de funciones de la IANA.

      Garantizando que el procesos seguidos realzan la responsabilidad y rendición de cuentas de la ICANN. Esta medida no tendrá ningún impacto fiscal sobre la ICANN ni la comunidad; y no tendrá ningún impacto sobre la seguridad, estabilidad y flexibilidad del sistema de nombres de dominio (DNS).

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

    7. Cambio de nombre del Comité de Participación Pública

      Visto y considerando que, el Artículo XII de los Estatutos establecen que "La Junta directiva puede establecer uno o más comités dependientes de la Junta que continuarán en vigor hasta que ésta determine lo contrario".

      Que, el 7 de noviembre de 2008, la Junta Directiva estableció un comité denominado Comité de Participación Pública (PPC) conforme a su autoridad en virtud del Artículo XII de los Estatutos.  

      Que, ahora el Comité de Participación Pública desea cambiar su nombre por "Comité de Compromiso Público y de Partes Interesadas", que será coherente con el nuevo enfoque de Compromiso de Partes Interesadas adoptado por la ICANN.

      Que, el Comité de Finanzas de la Junta ha recomendado que la Junta Directiva apruebe esta resolución.

      Queda resuelto (2013.04.11.09), la Junta Directiva aprueba el cambio de nombre del Comité de Participación Pública a Comité de Compromiso Público y de Partes Interesadas.

      Fundamentos de la Resolución 2013.04.11.09

      El cambio de nombre propuesto es coherente con la forma en que ahora la ICANN se enfoca sobre el Compromiso de Partes Interesadas a nivel mundial.

      Esta resolución sólo busca un cambio de nombre del Comité, y no un cambio en la estructura o el alcance de dicho Comité. Como el Comité de Gobernanza de la Junta ("BGC") tiene la intención de llevar a cabo una revisión completa de la estructura y el alcance de todos los comités a fines de este año, la presente resolución sólo busca un cambio de nombre para el PPC.

      La adopción de esta medida tendrá un impacto positivo en la comunidad de la ICANN, al garantizar que el nombre del comité refleje adecuadamente el alcance y el compromiso a nivel mundial bajo los cuales la ICANN está funcionando y el comité está supervisando. La presente resolución no tendrá ningún impacto fiscal sobre la ICANN o sobre la comunidad. Esta medida no tendrá ningún impacto directo sobre la seguridad, estabilidad y flexibilidad del sistema de nombres de dominio.

      Esta medida forma parte de las funciones administrativas y organizacionales de la ICANN que no requieren de comentarios públicos.

    8. Solicitud Presupuestaria Acelerada para SO/AC (Organizaciones de Apoyo y Comités Asesores)

      Visto y considerando que, un grupo de trabajo sobre mejoras presupuestarias —que incluye a personal de la ICANN y a miembros de la comunidad— identificó la necesidad de una decisión temprana sobre la financiación de solicitudes específicas por parte de la comunidad de la ICANN, que requieran financiación a principios del año fiscal.

      Que, se elaboró un Proceso de Solicitud Presupuestaria Adicional Acelerada de SO/AC en respuesta a la sugerencia de los grupos de trabajo; y que dicho proceso estuvo destinado a facilitar la recopilación, el análisis y la presentación de solicitudes presupuestarias al Comité de Finanzas de la Junta y a la Junta Directiva para su consideración.

      Que, la Comunidad de la ICANN presentó solicitudes oportunas, las cuales fueron examinadas ​​por un panel de miembros del personal en representación del personal de Políticas, Compromiso de Partes Interesadas y Finanzas.

      Que, el panel revisor recomendó 12 solicitudes presupuestarias aceleradas, representando la solicitud de aprobación de $ 279.000 (doscientos setenta y nueve mil dólares estadounidenses).

      Que, el Comité de Finanzas de la Junta se reunió el día 5 de abril de 2013, examinó el proceso seguido y las recomendaciones del personal, y recomendó que la Junta Directiva apruebe la recomendación del personal.

      Queda resuelto (2013.04.11.10), la Junta Directiva aprueba incluir en el presupuesto del año fiscal 2014 (FY14), un importe para fondos relacionados con las 12 solicitudes identificadas por la Comunidad como parte del Proceso de Solicitud Presupuestaria Adicional Acelerada de SO/AC.

      Fundamentos de la Resolución 2013.04.11.10

      El Proceso de Solicitud Presupuestaria Adicional Acelerada de SO/AC que conlleva a la aprobación presupuestaria en forma más temprana a lo usual constituye un ajuste razonable para las actividades que comienzan cerca del inicio del FY14. Este ligero acrecentamiento para el proceso y calendario establecidos para la aprobación presupuestaria de la ICANN facilita la labor de la comunidad y del personal de la ICANN, y no genera gastos adicionales. El importe de los gastos comprometidos resultantes de esta resolución se considera lo suficientemente pequeño como para no requerir de la identificación específica y aprobación separada de recursos.

      No se prevé ningún impacto sobre la seguridad, estabilidad y flexibilidad del sistema de nombres de dominio, como resultado de esta decisión.

      Esta medida forma parte de las funciones administrativas y organizacionales de la ICANN, para la cual se recibieron comentarios públicos.

    9. Resoluciones de agradecimiento – Miembros de la comunidad que se retiran

      Visto y considerando que, la ICANN desea reconocer la considerable energía y habilidades que los miembros de la comunidad de partes interesadas proporcionan a los procesos de esta Corporación.

      Que, en reconocimiento a estas contribuciones la ICANN desea reconocer y agradecer a los miembros de la comunidad cuando finalizan sus períodos de mandato en Organizaciones de apoyo y Comités asesores.

      Que, el siguiente miembro de la Unidad Constitutiva de Usuarios Comerciales y Empresariales (BC) de la Organización de Apoyo para Nombres Genéricos (GNSO) está dejando su puesto al finalizar su término de mandato:

      Marilyn Cade

      Queda resuelto (2013.04.11.11), Marilyn Cade se ha ganado el profundo agradecimiento de la Junta Directiva por su desempeño durante el término de su mandato, y la Junta Directiva le desea lo mejor en sus emprendimientos futuros.

      Que, los siguientes miembros de la Organización de Apoyo para Nombres de Dominio con Código de País (ccNSO) están dejando sus posiciones al finalizar sus términos de mandato:

      Fernando Espana, .us
      Paulos Nyirenda, .mw
      Rolando Toledo, .pe

      Queda resuelto (2013.04.11.12), Fernando Espana, Paulos Nyirenda y Rolando Toledo se han ganado el profundo agradecimiento de la Junta Directiva por el servicio brindado durante sus términos de mandato y la Junta Directiva les desea lo mejor en sus emprendimientos futuros.

    10. Agradecimiento a los Patrocinadores de la Reunión ICANN46

      La Junta Directiva desea agradecer a los siguientes patrocinadores:

      Verisign, Inc., Afilias Limited, .ORG, The Public Interest Registry, HiChina Zchicheng Technology Limited, .PW Registry, Community.Asia, Iron Mountain, Zodiac Holding Limited, Minds + Machines, Neustar Inc., KNET Co., Ltd., Deloitte Bedrijfsrevisoren BV ovve CVBA, JSC Regional Network Information Center (RU-CENTER), UniForum SA T/A ZA Central Registry, CORE Consejo de Registradores de Internet, Symantec, APNIC Pty Ltd, NCC Group, APTLD (Asociación de Dominios de Alto Nivel de Asia Pacífico), Freedom Registry B.V., Uniregistry Corp., Afnic, ICANN WIKI y a nuestros patrocinadores locales CNNIC (Centro de Información de la Red de Internet de China), CONAC (Centro de Administración de Nombres Organizacionales de China) y la Sociedad de Internet de China.

    11. Agradecimiento a escribas, intérpretes, personal y equipos del evento y del hotel que participaron en la reunión ICANN46

      La Junta Directiva expresa su agradecimiento a los escribas (transcriptores), intérpretes, equipos técnicos y a todo el personal de la ICANN por sus esfuerzos para facilitar que la reunión se llevara a cabo en forma correcta y agradablemente. La Junta desea agradecer a la gerencia y al personal del Hotel Internacional de Beijing por la maravillosa sede de este evento. Un especial agradecimiento para Li Yun, Gerente Principal de Ventas del Hotel Internacional de Beijing y a Nick Yang, Gerente de Servicios de Convención del Hotel Internacional de Beijing.

    12. Agradecimiento a los Patrocinadores locales de la Reunión ICANN46

      Patrocinadores locales de la reunión en Beijing. La Junta Directiva desea hacer extensivo su agradecimiento a los organizadores y patrocinadores locales: al Sr. Bing SHANG, Ministro de Industria y Tecnología de la Información (MIIT); Srta. Xia HAN, Directora del Departamento de Regulación de Telecomunicaciones del MIIT; Sr. Er-Wei SHI, Vicepresidente de la Academia de Ciencias Chinas; Sr. Tieniu TAN, Vicesecretario General de la Academia de Ciencias Chinas; Sr. Xiangyang HUANG, Director de CNNIC; Sr. Xiaodong Lee, Director Ejecutivo (CEO) de CNNIC; Sr. Feng WANG, Viceministro de la Oficina de Comisión Estatal para la Reforma del Sector Público; Sr. Ning FU, Director de la Junta del CONAC; Sr. Ran ZUO, Vicepresidente de la Junta del CONAC; Sr. Qing SONG, CEO del CONAC; Sta. Qiheng HU, Presidente de la Sociedad de Internet de China; Sr. Xinmin GAO, Vicepresidente de la Sociedad de Internet de China; Sr. Wei LU, Secretario General de la Sociedad de Internet de China.

  2. Agenda Principal:

    1. Procedimiento para la generación de etiquetas en la raíz para TLD variantes de IDN y recomendaciones del Estudio sobre la experiencia del usuario

      Visto y considerando que, durante varios años los IDNs (Nombres de Dominio Internacionalizados) han constituido una prioridad para la Junta Directiva, a fin de permitir que los usuarios de Internet accedan a nombres de dominio en su propio idioma; y que la Junta Directiva reconoce que las variantes de IDN constituyen un componente importante para algunas cadenas de caracteres de IDN TLDs (Dominios de Nivel Superior de Nombres de Dominio Internacionalizados);

      Que, la Junta Directiva ha resuelto previamente que los gTLDs variantes de IDN y ccTLDs (dominios de nivel superior con código de país) variantes de IDN no serán delegados hasta completarse el trabajo pertinente;

      Que, desde Diciembre 2010 ICANN ha estado trabajando para encontrar soluciones para garantizar una delegación segura y estable de TLDs variantes de IDN; y que el Programa de TLD variantes de IDN se benefició a partir de la importante participación de la comunidad en la elaboración del Procedimiento para elaborar y mantener reglas para la generación de etiquetas en la zona raíz respetando las etiquetas de IDNA (Nombres de Dominio Internacionalizados en Aplicaciones) y del Informe sobre las implicaciones de la experiencia del usuario con los TLDs variantes activos.

      Queda resuelto (2013.04.11.13), la Junta Directiva indica al personal implementar el Procedimiento para elaborar y mantener reglas para la generación de etiquetas en la zona raíz respetando las etiquetas de IDNA [PDF, 772 KB], incluyendo la actualización de la Guía para el Solicitante de gTLD y Procesos de ccTLD, a fin de incorporar las Reglas para la generación de etiquetas en la zona raíz respetando las etiquetas de IDNA en los respectivos procesos de evaluación.

      Queda resuelto (2013.04.11.14), la Junta Directiva solicita que, antes del 1 de julio de 2013, las Organizaciones de apoyo y Comités asesores interesados ​​proporcionen al personal cualquier aporte u orientación que pudiesen necesitar contemplación en el marco de la implementación de las recomendaciones del Informe sobre las implicaciones de la experiencia del usuario con los TLDs variantes activos [PDF, 1.38 MB].

      Fundamentos de las resoluciones 2013.04.11.13 – 2013.04.11.14

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

      Durante varios años los TLDs variantes de IDN han constituido un tema de interés para una cantidad de usuarios de IDN. El Programa de TLD variantes de IDN ha estado trabajando con expertos de la comunidad en la materia, a fin de desarrollar soluciones que permitan una delegación segura y estable de TLDs variantes de IDN. El Programa ha concluido la labor sobre dos componentes clave de la solución: el Procedimiento para elaborar y mantener reglas para la generación de etiquetas en la zona raíz respetando las etiquetas de IDNA y el Informe sobre las implicaciones de la experiencia del usuario con los TLDs variantes activos, de aquí en adelante referido como el Procedimiento. El Procedimiento está ahora listo para ser considerado y adoptado como el mecanismo, entre otras cosas, para evaluar posibles cadenas de caracteres de IDN TLD y para identificar sus variantes (si las hubiese). Las recomendaciones del Informe sobre las implicaciones de la experiencia del usuario con los TLDs variantes activos están ahora listas para ser implementadas con cualquier aporte y orientación que las Organizaciones de apoyo y Comités asesores pudiesen tener.

      ¿Cuál es la propuesta que se somete a consideración?

      El Procedimiento describe cómo rellenar y mantener las Reglas para la generación de etiquetas en la zona raíz respetando las etiquetas de IDNA, lo cual se espera constituya un componente clave en el procesamiento de solicitudes de IDN TLD. El Procedimiento requiere de la participación de las comunidades pertinentes como un componente central. El Procedimiento incluye resguardos para garantizar la máxima participación de la comunidad —de una comunidad lingüística determinada— y evitar la dominación de una única parte interesada; y requiere la participación de expertos técnicos para garantizar la precisión técnica y lingüística de los contenidos de las Reglas. El Informe sobre las implicaciones de la experiencia del usuario con los TLDs variantes activos incluye una serie de recomendaciones, a fin de posibilitar una buena experiencia del usuario con los TLDs variantes de IDN.

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

      La elaboración del Procedimiento y el Informe incluyó la plena participación de varios miembros de la comunidad. Ambos documentos también pasaron por dos procesos de recepción de comentarios públicos y una serie de presentaciones públicas a partir de las cuales se recabó retroalimentación.

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

      Hubo preocupaciones planteadas acerca de la idea de que en general las variantes no son apropiadas en la zona raíz; sin embargo, el permitir algunos casos específicos podría ser aceptable. También hubo preocupaciones planteadas respecto a la resolución de conflictos y la gobernanza del Procedimiento. No obstante, al contar con un requisito de consenso dentro y entre los paneles, el tema de resolución de conflictos parece haber sido mitigado. En lo que respecta a la gobernanza del Procedimiento, se prevé que el contar con el panel de integración bajo contrato con la ICANN permitirá la remoción de un panelista que pudiese comportarse de una manera no constructiva. También se expresó preocupación respecto a que las cuestiones planteadas en el Informe pudiesen asustar a los lectores y alejarlos de respaldar a las variantes, y el Informe no pone de manifiesto los riesgos (problemas y cuestiones de seguridad) si las variantes no son respaldadas o activadas. Sin embargo, con el fin de garantizar una experiencia segura, estable y aceptable, estas cuestiones necesitan ser señaladas para que las partes respectivas trabajen sobre ellas. La necesidad de variantes está bien articulada por los informes de cuestiones individuales, de modo que esta cuestión está fuera del alcance del estudio actual.

      ¿Qué materiales significativos revisó la Junta Directiva?

      Un documento de la Junta y materiales de referencia que detallan la propuesta, el Procedimiento para elaborar y mantener reglas para la generación de etiquetas en la zona raíz respetando las etiquetas de IDNA y el Informe sobre las implicaciones de la experiencia del usuario con los TLDs variantes activos.

      ¿Qué factores considera importantes la Junta Directiva?

      La Junta Directiva determinó que las Reglas para la generación de etiquetas en la zona raíz respetando las etiquetas de IDNA mejorarán el proceso actual para evaluar las cadenas de caracteres de IDN mediante un proceso determinista de aprobación previa, para definir qué puntos de código son permitidos en la raíz. La Junta Directiva también consideró importante que las reglas constituyan un componente clave para identificar las variantes de las cadenas de caracteres de IDN solicitadas, en forma consistente. El Procedimiento cuenta con la participación de las comunidades pertinentes como un componente central. Además, las Recomendaciones tienen por objeto permitir una buena experiencia del usuario en lo que respecta a los TLD variantes de IDN.

      ¿Se observan impactos positivos o negativos en la comunidad?

      La adopción del Procedimiento y, en consecuencia, las Reglas para la generación de etiquetas en la zona raíz respetando las etiquetas de IDNA beneficiarán a futuros solicitantes de TLD al permitirles comprobar si la cadena de caracteres que intentan solicitar está permitida. Las Reglas también permitirán la identificación determinista de variantes de IDN para las cadenas de caracteres solicitadas. La implementación de las Recomendaciones posibilitará una buena experiencia de usuario con los TLDs variantes de IDN.

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

      No se prevén impactos/ramificaciones fiscales sobre la ICANN a partir de la adopción de la presente resolución.

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

      Se espera que la adopción de las Reglas y la implementación de las Recomendaciones tengan un impacto positivo sobre la seguridad del DNS al contar con un proceso técnico sólido con múltiples puntos de verificación —incluyendo la revisión pública— de los puntos de código y sus variantes (si las hubiese) que se permitirán en la zona raíz; y el despliegue de medidas evita la confusión del usuario respecto a los TLDs variantes de IDN.

      ¿Constituye esta medida un proceso de políticas definido dentro de las Organizaciones de apoyo de la ICANN o de la función administrativa y organizacional de dicha Corporación, que requiera o no de la recepción de comentarios públicos?

      Esta medida forma parte de las funciones administrativas y organizacionales de la ICANN que no requieren de comentarios públicos.

    2. Solicitud de PIA-CC para formar una nueva unidad constitutiva

      Visto y considerando que, la Junta Directiva de la ICANN desea fomentar la participación de un amplio espectro de grupos comunitarios existentes y potenciales en los procesos y actividades de la ICANN.

      Que, la Junta Directiva de la ICANN ha establecido un Proceso para el reconocimiento de nuevas unidades constitutivas de la GNSO que incluye criterios de selección objetivos, fomenta la colaboración y coloca las decisiones sobre las solicitudes, en primera instancia, en manos de las comunidades que se vean directamente impactadas por la potencial nueva unidad constitutiva.

      Que, la Asociación de Cibercafés de la India (CCAOI), presentó una solicitud para el reconocimiento formal de una nueva unidad constitutiva de la GNSO llamada "Acceso Público a Internet/ Ecosistema de Cibercafés" (PIA/CC por sus siglas en inglés), dentro del Grupo de Partes Interesadas No Comerciales de la GNSO (NCSG).

      Que, el personal de la ICANN abrió un foro para la recepción de comentarios públicos durante 68 días, para revisión de la comunidad y reacción ante la propuesta de PIA/CC.

      Que, la Dirigencia del NCSG y el personal de la ICANN participaron en consulta colaborativa y diálogo con los proponentes de PIA/CC.

      Que, la Dirigencia del NCSG y el personal de la ICANN han seguido el proceso y el NCSG ha informado al Comité de Mejoras Estructurales de la Junta sobre su decisión de denegar la solicitud debido a que la solicitud no cumple con los criterios establecidos por la Junta.

      Queda resuelto (2013.04.11.15), la decisión del NCSG de denegar la solicitud de PIA/CC es ratificada, bajo el entendimiento de que la decisión es imparcial y que los proponentes de la unidad constitutiva tienen el derecho de volver a presentar una nueva solicitud.

      Queda resuelto (2013.04.11.16), se indica al Presidente y CEO continuar las discusiones colaborativas con los proponentes de PIA/CC para investigar en mayor detalle y considerar otras opciones para la participación de dicha comunidad, dentro de la comunidad de la ICANN y sus procesos.

      Fundamentos de las resoluciones 2013.04.11.15 – 2013.04.11.16

      El proceso para el reconocimiento de nuevas unidades constitutivas de la GNSO fue diseñado para proporcionar criterios de solicitud específicos y objetivos, a fin de colocar las decisiones sobre el reconocimiento de nuevas unidades constitutivas de la GNSO, en primera instancia, en manos de los grupos de la comunidad que se encuentran en la mejor posición para evaluar las solicitudes. En este caso, se siguió el proceso y el NCSG tomó una decisión.

      Cabe señalar que la ratificación de la Junta Directiva respecto a la decisión del NCSG de rechazar la solicitud de PIA/CC no constituye perjuicio alguno al derecho de los proponentes para volver a presentar una nueva solicitud. La Junta Directiva espera que nuevas conversaciones con los proponentes de PIA/CC puedan dar lugar a un plan de acción que permitirá a los intereses de PIA/CC ser efectivamente incorporados a las actividades y procesos de la ICANN.

      Esta medida no tendrá un impacto inmediato o sustancial sobre los recursos de la ICANN. Se prevé que esta medida no tendrá ningún impacto sobre la seguridad, estabilidad y flexibilidad del sistema de nombres de dominio.

      Esta medida forma parte de las funciones administrativas y organizacionales de la ICANN que no requieren de comentarios públicos.

    3. Otros temas a tratar

      No se adoptó ninguna resolución.

resolutions-11apr13-es.pdf  [293 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."