Skip to main content
Resources

Acta | Asamblea Extraordinaria 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/minutes/minutes-28jul11-en.htm

El 28 de julio de 2011, a las 11:00 a.m., hora UTC, se celebró la Asamblea Extraordinaria de la Junta Directiva de la Corporación para la Asignación de Números y Nombres en Internet (ICANN).

El presidente, Steve Crocker, declaró abierta la sesión.

Junto al presidente, los siguientes directores participaron de la reunión en forma total o parcial: Rod Beckstrom (presidente y director ejecutivo [CEO]), Sébastien Bachollet, Cherine Chalaby, Bertrand de la Chapelle, Chris Disspain, Bill Graham, Gonzalo Navarro, Ray Plzak, R. Ramaraj, George Sadowsky, Mike Silber, Bruce Tonkin (vicepresidente), Katim Touray y Kuo-Wei Wu.

Erika Mann se excusó.

Los siguientes coordinadores de la Junta Directiva participaron de la reunión en forma total o parcial: Heather Dryden, coordinadora del Comité Asesor Gubernamental (GAC); Ram Mohan, coordinador del Comité Asesor de Seguridad y Estabilidad (SSAC); Thomas Narten, coordinador del Grupo de Trabajo de Ingeniería de Internet (IETF); Reinhard Scholl, coordinador del Grupo de Alianza Técnica (TLG), y Suzanne Woolf, coordinadora del Comité Asesor del Sistema de Servidores Raíz (RSSAC).

  1. Agenda convenida
  2. Recepción del Marco conceptual y de trabajo sobre seguridad, estabilidad y flexibilidad para el año fiscal 2012
  3. Designación de un nuevo defensor del pueblo
  4. Informe del CEO
  5. Cualquier otro asunto

  1. Agenda convenida

  2. El presidente de la Junta Directiva presentó los puntos de la agenda convenida y aprobó la resolución de esta última.

    Por ello, la Junta Directiva tomó la siguiente acción:

    Resuélvase: Por la presente, se aprueban las siguientes resoluciones de esta agenda convenida:

    1.1 Aprobación del acta de la reunión de la Junta Directiva de la ICANN del día 20 de junio de 2011

    Resuélvase (2011.07.28.01): Por la presente, la Junta Directiva aprueba el acta de la reunión de la Junta Directiva de la ICANN del día 20 de junio de 2011.

    1.2 Aprobación del acta de la reunión de la Junta Directiva de la ICANN del día 24 de junio de 2011

    Resuélvase (2011.07.28.02): Por la presente, la Junta Directiva aprueba el acta de la reunión de la Junta Directiva de la ICANN del día 24 de junio de 2011.

    1.3 Aprobación del acta de la Asamblea Constitutivade la Junta Directiva de la ICANN del día 24 de junio de 2011

    Resuélvase (2011.07.28.03): Por la presente, la Junta Directiva aprueba el acta de la Asamblea Constitutivade la Junta Directiva de la ICANN del día 24 de junio de 2011.

    1.4 Aprobación del acta de la reunión de la Junta Directiva de la ICANN del día 25 de junio de 2011

    Resuélvase (2011.07.28.04): Por la presente, la Junta Directiva aprueba el acta de la reunión de la Junta Directiva de la ICANN del día 25 de junio de 2011.

    1.5 Aprobación de la redelegación del dominio .om, que representa a Omán

    Visto y considerando que OM es el código de país de dos letras ISO 3166-1 designado para Omán.

    Que la ICANN ha recibido una solicitud de redelegación del dominio .OM a la Autoridad Reguladora de las Telecomunicaciones.

    Y que la ICANN ha examinado la solicitud y ha determinado que la redelegación propuesta es adecuada para los intereses de las comunidades de Internet a nivel local y mundial.

    Por la presente, queda resuelto (2011.07.28.05) que se aprueba la redelegación propuesta del dominio de alto nivel .OM a la Autoridad Reguladora de las Telecomunicaciones.

    Fundamentos para la Resolución 2011.07.28.05

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

    Cuando el personal considera que el solicitante ha presentado una solicitud adecuadamente completa y en condiciones de obtener una decisión favorable de la Junta Directiva, presenta las solicitudes de delegación y redelegación de los dominios con código de país a la Junta Directiva, a fin de obtener la correspondiente decisión.La Junta Directiva de la ICANN, de acuerdo con los compromisos asumidos por la ICANN para el procesamiento oportuno de las solicitudes relacionadas con la función de la Autoridad de Números Asignados en Internet (IANA) y, en particular, con la zona raíz del Sistema de Nombres de Dominio (DNS), desea evaluar estas solicitudes en la próxima Asamblea Extraordinaria prevista.

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

    La propuesta consiste en aprobar una solicitud dirigida a la IANA para cambiar o designar a la organización patrocinadora (denominada también administradora o custodio) de un dominio de alto nivel con código de país.

    De acuerdo con las prácticas establecidas, la Junta Directiva de la ICANN es responsable de tomar la decisión de dar curso a estas solicitudes en una de las etapas de este proceso de múltiples pasos.

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

    Durante la evaluación de una solicitud de delegación, el personal de la ICANN consulta al solicitante, al actual operador (si corresponde) y a otras partes directamente relacionadas. La ICANN no ha realizado consultas abiertas sobre este tema, ajustándose a las prácticas de la ICANN sobre confidencialidad de las solicitudes de cambio de zona raíz incompletas.

    ¿Qué inquietudes o cuestiones mencionó la comunidad?

    Las preocupaciones o temas se incluyen en el informe público que se publicará junto con esta acción. Este informe se publicará en el sitio web de IANA en http://www.iana.org/ si la solicitud de cambio de la zona raíz logra completar exitosamente la etapa de procesamiento definitivo, que lleva de uno a dos meses luego de la decisión de la Junta Directiva.

    ¿Qué materiales de importancia analizó la Junta Directiva?

    La Junta Directiva se encarga de evaluar las solicitudes frente a una amplia variedad de criterios de interés público. Entre estos criterios figuran: establecer que el código de país sea elegible (es decir, se incluya en la norma ISO 3166-1); que el administrador propuesto cuente con el apoyo de la comunidad local de Internet; que el operador propuesto califique a nivel operativo y técnico; que el administrador propuesto esté radicado en el país en cuestión y se rija por la legislación local; que el administrador propuesto opere de manera imparcial y equitativa; que, en casos en que exista una transferencia de operaciones, se disponga de un plan adecuado para preservar la estabilidad actual del dominio; y que la acción sea compatible con las leyes y disposiciones locales aplicables. Durante el proceso de recopilación de los empleados, el solicitante debe entregar diversos materiales de respaldo sobre estos temas. La información obtenida de los materiales provistos y el resto de las investigaciones realizadas por el personal se ponen a disposición de la Junta Directiva y se publican en un informe público al finalizar la implementación de la solicitud aprobada.

    ¿Qué factores considera importantes la Junta Directiva?

    La Junta Directiva toma en cuenta los factores mencionados en el informe público relacionados con los principios básicos de delegación de dominios con código de país referidos anteriormente.

    ¿Se observan impactos positivos o negativos en la comunidad?

    La aprobación oportuna de administradores de nombres de dominio con código de país que cumplen con los diversos criterios de interés público tiene un impacto positivo para la misión de la ICANN a nivel general y para las comunidades locales a las que están destinados los dominios de alto nivel con código de país.

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

    La administración de las delegaciones de dominios con código país en la zona raíz del DNS forma parte de las funciones de la IANA y, por ello, la acción de delegación no debería causar variaciones de importancia en los gastos ya planificados.Si bien no corresponde a la ICANN la función de evaluar el impacto fiscal de las operaciones internas de los dominios de alto nivel con código de país dentro de un país, le corresponde garantizar que el operador se encuentre radicado en el país y que cuente con los mecanismos adecuados para permitir que la comunidad local de Internet controle adecuadamente el actual funcionamiento de los dominios.

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

    Para las delegaciones de dominios de alto nivel con código de país, la ICANN trata de aprobar únicamente aquellas solicitudes que den respuesta satisfactoria a preocupaciones razonables y en las que el nuevo administrador propuesto haya demostrado un nivel adecuado de capacidad técnica y operativa que prácticamente no dé lugar a tales preocupaciones.

    Las resoluciones 2011.07.28.01, 2011.07.28.02, 2011.07.28.03, 2011.07.28.04, y 2011.07.28.05 fueron aprobadas en una sola votación de conformidad con los puntos de la agenda convenida. Todos los miembros de la Junta Directiva presentes aprobaron estas resoluciones en forma unánime. Erika Mann y Mike Silber no estuvieron presentes para votar estas resoluciones.

  3. Recepción del Marco conceptual y de trabajo sobre seguridad, estabilidad y flexibilidad para el año fiscal 2012

  4. Jeff Moss, director de seguridad, presentó un informe acerca del Marco conceptual y de trabajo sobre seguridad, estabilidad y flexibilidad (SSR), que incluyó un análisis de la manera en que se incorporaron al Marco conceptual y de trabajo para el año fiscal 2012 planteos realizados por la comunidad en respuesta a anteriores Marcos conceptuales y de trabajo sobre SSR. Jeff explicó que, como consecuencia de la retroalimentación recibida en Cartagena, el informe hoy tiene una estructura más clara y establece una distinción más nítida entre las áreas sobre las que la ICANN mantiene control operativo, como las Extensiones de Seguridad para el Sistema de Nombres de Dominio (DNSSEC) y las operaciones de zona raíz, aquéllas en que las cumple la función de ser un ente colaborador y coordinador, y aquéllas en las que se dedica principalmente a observar las actividades conducidas por otros grupos. El Marco conceptual y de trabajo sobre SSR para el año fiscal 2012 fue observado previamente junto con el Comité Asesor de Seguridad y Estabilidad (SSAC), así como con los integrantes de At-Large, y ha sido objeto de comentarios públicos. Posteriormente, el Marco conceptual y de trabajo se analizó con diversas unidades constitutivas en la reunión de Singapur, donde la retroalimentación recibida acerca de los cambios, en general, fue positiva.

    Jeff observó que aún existen inquietudes en la comunidad en el sentido de que la ICANN debe informar mejor a ésta última sobre la manera en que se ejecutaron e implementaron anteriores Marcos conceptuales y de trabajo sobre SSR, así como sobre detalles presupuestarios. La misma inquietud se está analizando con el equipo de revisión de Afirmaciones que se ocupa de la Seguridad y Estabilidad, y ya se está trabajando para dar respuesta a ambas preocupaciones.

    El presidente confirmó que se solicita a la Junta Directiva que acuse recibo del Marco conceptual y de trabajo. Luego, expresó la opinión de que el Marco conceptual y de trabajo para el año fiscal 2012 constituye una mejora respecto de los Marcos conceptuales y de trabajo presentados en ocasiones anteriores y manifestó su agradecimiento a Patrick Jones y al personal por su labor. El presidente también señaló que todo plan debe contener criterios que permitan la evaluación de objetivos cuantificables y que este Marco conceptual y de trabajo suministra bases más sólidas para la realización de informes que Marcos conceptuales y de trabajo previos. El presidente comentó que, con el uso de este Marco conceptual y de trabajo como base, la elaboración de informes que tomen como referencia los parámetros de este Marco, en el futuro, no debería presentar dificultades.

    Jeff confirmó que la transparencia y la capacidad de realizar informes que tomaran como referencia el plan eran una característica muy importante de su diseño. Jeff también interrogó a la Junta Directiva sobre cuál pensaba que debía ser el próximo paso en el desarrollo del plan de SSR.

    Ram Mohan confirmó que Ray Plzak y él, a través de la labor que desarrollan en el Comité de Gobernanza de la Junta Directiva, están a cargo de elaborar una recomendación para la composición de un Grupo de Trabajo para el Sistema de Nombres de Dominio (DNS) que tendrá la facultad de supervisar la ejecución de los planes sobre SSR; la recomendación podría estar lista para que la Junta Directiva la evalúe en su próxima reunión. También deberán definirse el estatuto y el alcance del trabajo de este grupo, en el sentido, por ejemplo, de si se tratará de un grupo permanente.

    El presidente preguntó al CEO cuál era, a su entender, el propósito del grupo de trabajo.

    El CEO confirmó que el grupo de trabajo que se está constituyendo estará a cargo de elaborar un proceso para la revisión y supervisión de un sistema de gestión de riesgo del DNS, y que la supervisión del Marco conceptual y de trabajo sobre SSR forma parte de esa tarea. Asimismo, señaló que cabe esperar que el acotado foco de este nuevo grupo de trabajo conduzca a buenos resultados y avances oportunos sobre estos temas.

    El presidente mencionó las preocupaciones manifestadas anteriormente por el CEO respecto de la modificación del estatuto del SSAC orientadas a desligarlo de la responsabilidad del marco de seguridad sin ninguna actividad compensatoria, cuando una de las principales obligaciones de la ICANN es velar por la seguridad, estabilidad y flexibilidad del DNS. El presidente preguntó al CEO si esta evolución del grupo de trabajo, aún no constituido, le resultaba satisfactoria.

    El CEO confirmó que está complacido con esta evolución, ya que el hecho de que los temas relacionados con la SSR del DNS pasen a ser analizados por las autoridades de la Junta Directiva permitirá que la ICANN adopte una actitud más proactiva a la hora de elaborar medidas rigurosas para la gestión del riesgo y de ejercer su labor de monitoreo. El CEO expresó que expertos externos tienen un creciente interés en forjar relaciones estratégicas con la ICANN a fin de aportar ideas sobre el desarrollo de marcos de riesgo.

    Luego, el presidente propuso que se votara, y la Junta Directiva tomó la siguiente acción:

    Visto y considerando que, el Marco conceptual y de trabajo sobre seguridad, estabilidad y flexibilidad (SSR) para el año fiscal 2012 fue publicado para la recepción de comentarios públicos desde el 2 de mayo hasta el 7 de junio de 2011.

    Que se completó y publicó un resumen y análisis de los comentarios públicos el 8 de junio de 2011.

    Y que el personal realizó una reunión informativa con la comunidad durante la reunión de Singapur y que incorpora la retroalimentación a las prioridades operativas descritas en el Marco conceptual y de trabajo sobre SSR, lo cual incluye parámetros de referencia, objetivos, hitos y un mecanismo para evaluar los resultados de las actividades en materia de SSR.

    Resuélvase (2011.07.28.06): la Junta Directiva acusa recibo del Marco conceptual y de trabajo sobre seguridad, estabilidad y flexibilidad (SSR) para el año fiscal 2012.

    Fundamentos para la Resolución 2011.07.28.06

    De acuerdo con la Afirmación de Compromisos que firmaron la ICANN y el Departamento de Comercio de EE.UU. el 30 de septiembre de 2009, se reconoce como un compromiso esencial la preservación de la seguridad, estabilidad y flexibilidad del DNS.La Afirmación reconoce, en su Sección 9.2, que la ICANN ha adoptado un Plan de Seguridad, Estabilidad y Flexibilidad (SSR) que se actualizará periódicamente a fin de reflejar los peligros que surjan para el DNS, incluidos los identificadores únicos.En 2009 y 2010 se publicaron Planes de SSR previos, que fueron reconocidos por la Junta Directiva de la ICANN en los reuniones públicas internacionales celebradas en Sydney, Australia (Junio de 2009) y Cartagena, Colombia (Diciembre de 2010).

    La versión más reciente del Marco conceptual y de trabajo sobre SSR ha sido actualizada en un formato mejor estructurado, más accesible, y se publicó en mayo de 2011, a fin de que la documentación básica de la ICANN sobre SSR respetara los plazos correspondientes a la publicación del ciclo del Presupuesto y Plan Operativo de la ICANN del año fiscal 2012.Este documento orienta a la comunidad sobre el papel de la ICANN en materia de SSR, describe las áreas en que la ICANN tiene responsabilidad operativa, las áreas en las que actúa como colaboradora, facilitadora y en que brinda aportes, y las áreas en que se dedica a observar las actividades conducidas por otros en el ecosistema.Los comentarios recibidos de la comunidad durante el período de recepción de comentarios públicos, en general, se manifestaron a favor del formato revisado y solicitaron mayor especificidad y precisión en las definiciones. 

    Se han presentado ante la Junta Directiva un documento de la Junta que detalla el Marco conceptual y de trabajo sobre SSR, así como un anexo con información sobre los comentarios recibidos entre el 2 de mayo y el 7 de junio de 2011.

    Este documento no forma parte del Presupuesto y Plan Operativo general de la ICANN, y no se prevé ningún impacto fiscal derivado de esta decisión.El Marco conceptual y de trabajo constituye un documento orientativo de las actividades de la ICANN en materia de SSR para el próximo ano fiscal.

    Todos los miembros presentes de la Junta Directiva aprobaron por unanimidad la resolución 2011.07.28.06. Erika Mann y Mike Silber no estuvieron presentes para votar esta resolución.

  5. Designación de un nuevo defensor del pueblo

  6. John Jeffrey, asesor jurídico y secretario, presentó ante la Junta Directiva un informe sobre el trabajo del Comité de Compensación y la Junta realizado a fin de identificar a un candidato que recomendar para que desempeñara la función de defensor del pueblo de la ICANN. La Junta Directiva había identificado a dos candidatos definitivos y realizado una serie de entrevistas durante la reunión de la ICANN en Singapur. El Comité de Compensación había recomendado la selección de uno de los candidatos. El Comité de Compensación y el asesor jurídico analizaron una estructura de compensación propuesta y, en nombre de la Junta Directiva, el asesor jurídico discutió dicha estructura de compensación con el candidato favorecido.

    Bruce Tonkin confirmó que el Comité de Compensación, compuesto por los integrantes que lo formaban antes de reunirse al término la reunión de Singapur [Peter Dengate Thrush, Rita Rodin Johnston, R. Ramaraj y Bruce] entrevistó a una serie de candidatos, y que luego, las entrevistas con los candidatos definitivos estuvieron abiertas a todos los miembros de la Junta Directiva.

    Bertrand de La Chapelle solicitó que procesos como el descrito se formalizaran o clarificaran para el futuro, a fin de que la Junta Directiva tuviera una comprensión más cabal de la manera en que se realizan este tipo de selecciones.

    Katim Touray sugirió realizar las entrevistas a candidatos utilizando otros formatos que permitieran a un mayor número de miembros de la Junta Directiva efectuar análisis y evaluaciones más generales de estos últimos.

    Se analizaron los méritos de los candidatos y luego, sobre la base de la recomendación del Comité de Compensación, Bruce Tonkin propuso la siguiente moción, y R. Ramaraj apoyó la siguiente resolución:

    Visto y considerando que, el 31 de enero de 2011 el defensor del pueblo de la ICANN pasó a dedicarse a otros proyectos.

    Que desde el 1 de febrero de 2011 un defensor del pueblo interino ha estado cumpliendo todas las funciones y responsabilidades del defensor del pueblo.

    Que la ICANN ha realizado una búsqueda cuidadosa, a escala mundial, de un nuevo defensor del pueblo.

    Y que la Junta Directiva ha identificado a un nuevo defensor del pueblo, el cual ha aceptado el cargo.

    Resuélvase (2011.07.28.07): De conformidad con la Sección 1.2 del Artículo V de los Estatutos de la ICANN, la Junta Directiva, por la presente, designa a Chris LaHatte como defensor del pueblo de la ICANN por un período inicial de dos años que tendrá vigencia desde el 28 de julio de 2011 hasta el 27 de julio de 2013 inclusive, y autoriza al asesor jurídico y secretario a ejecutar un acuerdo con el Sr. LaHatte.

    Fundamentos propuestos para la Resolución 2011.07.28.07:

    Los Estatutos de la ICANN exigen que la ICANN mantenga una Defensoría del Pueblo. Puede consultarse el Artículo V de los Estatutos en http://www.icann.org/es/general/bylaws-es.htm#V. La existencia de un defensor del pueblo de la ICANN repercute positivamente en la transparencia y la responsabilidad de la ICANN, ya que el defensor del pueblo constituye uno de los tres mecanismos principales de responsabilidad dentro de la ICANN.Dado que existe un presupuesto destinado al defensor del pueblo de la ICANN desde 2004, año en que se designó al primer defensor del pueblo, el efecto financiero en la ICANN derivado del reemplazo del actual defensor del pueblo interino será insignificante.La designación de un nuevo defensor del pueblo no tendrá consecuencias negativas para la seguridad, estabilidad y flexibilidad sistémicas del sistema de nombres de dominio.

    Once miembros de la Junta Directiva votaron a favor de la Resolución 2011.07.28.07. Sébastien Bachollet, Bertrand de La Chapelle y Katim Touray se abstuvieron de votar la resolución, y Erika Mann y Mike Silber no estuvieron presentes para votar esta resolución. La resolución se aprobó.

  7. Informe del CEO

  8. El CEO presentó ante la Junta Directiva un informe sobre las actividades y los logros alcanzados por la organización desde la reunión de Singapur. Señalo las productivas visitas de Cherine Chalaby y Ray Plzak a las oficinas de Marina del Rey y los comentarios que aportaron sobre temas financieros, así como la capacitación de la Junta Directiva y otros temas referidos a operaciones. El CEO también mencionó su trabajo con el nuevo presidente sobre una serie de temas en preparación para el próximo taller de la Junta Directiva, así como su labor con el equipo ejecutivo para dotar de métricas y objetivos claros a algunos puntos del plan estratégico.

    El CEO agradeció a los miembros de la Junta Directiva por sus aportes a la respuesta de la ICANN al Departamento de Comercio en relación con el Nuevo Aviso de Consulta (FNOI).

    El CEO también señaló la labor de Jeff Moss para fortalecer el grupo de seguridad y para integrarlo a la organización.

    Luego, el CEO presentó información actualizada sobre la planificación para la reunión programada para Octubre en Dakar, Senegal, incluyendo temas relacionados con la partición remota. El presidente y otros miembros de la Junta Directiva reiteraron su permanente apoyo a la propuesta de celebrar la reunión en Dakar.

    El CEO cerró su informe con información sobre las búsquedas de personal, incluida la situación de la búsqueda de un nuevo director financiero (CFO) y de un vicepresidente (VP) de la región de África, así como de personal que integre el nuevo grupo de dominios genéricos de alto nivel (gTLD). El CEO también mencionó el trabajo que se está realizando en la ICANN para planificar todos los detalles del programa de nuevos gTLD, incluido el respaldo al Grupo de Trabajo Conjunto de Apoyo al Solicitante. Finalmente, el CEO señaló que la información financiera para el año fiscal 2011 es mejor que la esperada.

    Bertrand de La Chapelle hizo algunos comentarios sobre el informe del CEO; entre ellos, la solicitud de que el personal nuevo sea presentado a la Junta Directiva durante el taller de Marina del Rey, y una corrección sobre la situación de un tema relativo al Foro de Gobernanza de Internet (IGF). Bertrand también solicitó más información sobre el estado del rediseño del sitio web icann.org y el plan de comunicaciones sobre los nuevos gTLD, incluido un análisis por el personal de cuál ha sido, a la fecha, el alcance de la comunicación del programa.

    El CEO se refirió al amplio y difícil proceso de planificación necesario para diagramar la logística completa del plan de comunicaciones luego de que la Junta Directiva aprobó el programa en Singapur. Mencionó que en este momento podrían hacer falta asesores externos para que efectúen el análisis solicitado por Bertrand, debido a que el equipo está concentrado en la planificación de conferencias y eventos. Sin embargo, existe la clara necesidad de cuantificar el efecto de los eventos y las comunicaciones como parte del programa. En cuanto al rediseño del sitio web, las meras dimensiones del sitio contribuyen a que la concreción del nuevo diseño requiera un tiempo prolongado. El CEO se ofreció a organizar una consulta informativa para la Junta Directiva sobre este tema.

    Sébastien Bachollet realizó un comentario sobre el tema del Grupo de Trabajo Conjunto de Apoyo al Solicitante (JAS) y agradeció al CEO por la información proporcionada al respecto. También preguntó sobre el programa de comunicación y observó que es importante que los miembros de la Junta Directiva cuenten con mensajes que transmitir a la comunidad. Sébastien solicitó una consulta informativa de la Junta Directiva sobre este tema.

    El CEO confirmó que en una consulta informativa de la Junta podrían cubrirse los tres puntos: el diseño del sitio web, las comunicaciones de la Junta Directiva sobre los nuevos gTLD y el plan general de comunicaciones.

  9. Cualquier otro asunto

  10. El Presidente invitó a los miembros de la Junta Directiva a que plantearan cualquier otro asunto.

    Sébastien Bachollet preguntó acerca del estado del trabajo sobre la recomendación 5 del equipo para la Revisión de Responsabilidad y Transparencia (ATRT) en cuanto a la remuneración de los miembros de la Junta Directiva.

    Bertrand de La Chapelle preguntó sobre el estado de la delegación que asistirá al IGF, que se celebrará en Nairobi.

    El presidente confirmó que se enviarán mensajes a la Junta Directiva para informar del estado de ambas cuestiones.

    Luego, el Presidente declaró cerrada la asamblea.

minutes-28jul11-es.pdf  [165 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."