Skip to main content
Resources

Actas | Reunión Ordinaria del Comité para el Programa de Nuevos gTLD

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/minutes-new-gtld-07oct13-en.htm

 

Nota: El 10 de abril de 2012, la Junta Directiva creó el Comité para el Programa de Nuevos gTLD, integrado por todos los miembros de la Junta Directiva con derecho a voto que no poseen conflictos de intereses en relación con el Programa de Nuevos gTLD. La Junta Directiva otorgó plena potestad al Comité (sujeta a las restricciones establecidas por ley, en las actas constitutivas, en los estatutos, o en la Política de Conflictos de Intereses de la ICANN) para ejercer su autoridad al mismo nivel que la Junta en todas las cuestiones relativas al Programa de Nuevos gTLD. El alcance total de la autoridad del Comité se detalla en la carta orgánica disponible en http://www.icann.org/en/groups/board/new-gTLD.

El Comité para el Programa de Nuevos gTLD de la Junta Directiva de la ICANN celebró una reunión extraordinaria telefónicamente el 7 de octubre de 2013 a las 13:00 UTC.

El presidente del Comité, Cherine Chalaby, declaró abierta la sesión con puntualidad.

Junto al Presidente, los siguientes Directores participaron en forma total o parcial de la reunión: Fadi Chehadé (Presidente y Director Ejecutivo de la ICANN), Chris Disspain, Bill Graham, Olga Madruga-Forti, Erika Mann, Gonzalo Navarro, Ray Plzak, George Sadowsky, Mike Silber y Kuo-Wei Wu.

Jonne Soininen (Coordinador del Grupo de Trabajo en Ingeniería de Internet o IETF) participó de la reunión en carácter de coordinador de enlace sin derecho a voto ante el Comité. Heather Dryden participó de la reunión en carácter de observadora ante el Comité. Francisco da Silva (Coordinador del Grupo de Coordinación Técnica o TLG) presentó sus disculpas por no poder estar presente.

Los siguientes integrantes del personal de la ICANN participaron en forma total o parcial de la reunión: Akram Atallah (Presidente, División de Dominios Genéricos); John Jeffrey (Asesor Jurídico General y Secretario); Megan Bishop; Samantha Eisner; Dan Halloran; Jamie Hedlund; Cyrus Namazi; Karine Perset; Erika Randall; Amy Stathos y Christine Willett.

Paul Mockapetris participó de la reunión en carácter de observador invitado. Ram Mohan participó de la reunión en carácter de observador invitado para el ítem 1 del Orden del Día Principal.

Estas son las Actas de la Reunión del Comité para el Programa de Nuevos gTLD realizada el 7 de Octubre del 2013.

  1. Orden del Día Principal
    1. Gestión de colisiones de nuevos gTLD

 

  1. Orden del Día Principal:

    1. Gestión de colisiones de nuevos gTLD

      A solicitud del Presidente, Paul Mockapetris brindó aportes al Comité en relación al tema de colisión de nombres. Paul ofreció una perspectiva histórica sobre el uso de los nombres de dominio que no están totalmente calificados, y citó problemas de colisión en el pasado con los correos electrónicos y las introducciones de algunos códigos de país. Paul señaló que la ambigüedad está inherentemente en contra de la seguridad del DNS, y sugirió que la ICANN debe, hasta el límite de sus posibilidades, tratar de reducir la ambigüedad conforme se introducen nuevos dominios. Paul está de acuerdo en que el Plan de Gestión de Colisiones para los Nuevos gTLD propuesto logra esto y recomendó que la ICANN debería controlar la velocidad con la que se implementan los TLD.

      A petición del Presidente, Ram Mohan proporcionó al Comité orientación técnica adicional con respecto al Plan de Gestión de Colisiones. Ram indicó su apoyo total al plan y recomendó que el Comité considerase si el plan: (1) es técnicamente sólido, (2) estará apto para un control estricto, (3) resuelve los problemas que pretende abordar y (4) necesita elementos adicionales.

      Ram concordó en que el plan es técnicamente sólido, y señaló, por ejemplo, que corrige algunas limitaciones del análisis anterior, ya que el nuevo plan aborda la gravedad de las colisiones y elimina la categorización de riesgo (que muchos en la comunidad sugirieron eran distinciones arbitrarias).

      Ram recomendó que el Comité debería establecer un límite claro respecto del nivel apropiado de difusión exigido por el plan. Erika Mann y Jonne Soininen coincidieron en que los parámetros deben definirse con mayor claridad.

      Ram señaló que el plan propuesto incluye parámetros que permitirán estar a la altura de un control estricto, pero es probable queque la comunidad se focalice sobre los detalles de cómo estudiar la gravedad de los sucesos de colisión.

      Ram señaló que resevar colisiones conocidas de dominios de segundo nivel es una buena idea y que el análisis de cada cadena de caracteres, como se propone en el plan, cuenta con un fuerte apoyo de la comunidad técnica y de seguridad.

      Ram sugirió elementos adicionales que el plan debería abordar, que incluyen, visto desde una perspectiva de la creación de medidas a largo plazo para reducir el uso público de las cadenas de caracteres de TLD no asignados, la creación de un plan con el IAB y el IETF para reservar cadenas de caracteres para uso privado, considerando las implicancias respecto de las delegaciones de ccTLD y la creación de un plan para la medición de datos de servidores raíz a ser utilizados a fin de realizar nuevas recomendaciones. Ray Plzak sugirió que las medidas de recopilación de datos deben ser más amplias que simplemente los nombres, y que deben tener en cuenta IN-ADDR.ARPA, el dominio ARPA, y los números.

      Muchos miembros del Comité concordaron en que el plan tiene que incluir estos elementos adicionales.

      Ram sugirió que el tema de colisión de nombres probablemente debería ser supervisado por un comité de la Junta Directiva ya que la cuestión excede los nuevos gTLD y Mike Silber preguntó si el Comité de Riesgos de la Junta Directiva era el comité adecuado para supervisar el tema. Ray y el Presidente concordaron en que esta cuestión debe ser supervisada por el Comité de Riesgos de la Junta Directiva.

      Olga Madruga-Forti preguntó si la ICANN podía efectuar delegaciones condicionales cuando fuese necesario como una manera abordar la cuestión de los sucesos de colisiones. Olga aclaró las diferencias entre de una delegación condicional versus una delegación de prueba. Ram cuestionó el valor de las delegaciones de prueba y citó preocupaciones con respecto a si el tener más datos que podrían derivar de una delegación de prueba proporcionaría información que hiciera que la decisión sobre una delegación fuese más fácil, y si las pruebas reducirían la estabilidad de algún componente del DNS .

      El Presidente, GDD, observó que las delegaciones de prueba no pudieron mitigar adecuadamente el riesgo debido a que el daño no se produce inicialmente al delegar el TLD, sino que el posible daño surge cuando se activan los dominios de segundo nivel, lo que podría ocurrir en cualquier momento.

      George Sadowsky preguntó si la propuesta presentada en la comunidad con respecto a un método de cuidadosa delegación es un abordaje técnico sólido. El Presidente, GDD, notó que muchos de los planes de mitigación que se están discutiendo en la comunidad, como por ejemplo la delegación de prueba y el informe de Kolkman del IAB, podrían potencialmente ser herramientas utilizadas en los planes de mitigación que se desarrollarán como parte de la propuesta.

      Mike Silber recomendó que es necesario que el tono de la propuesta comunique que se están considerando seriamente los comentarios de la comunidad y que no son dejados de lado. Erika estuvo de acuerdo.

      El Comité discutió las modificaciones a la resolución para hacer frente a los puntos adicionales recomendados para su inclusión en la propuesta y analizó la resolución revisada. Gonzalo Navarro expresó su preocupación respecto de que se necesitaba más tiempo para evaluar la resolución.

      Chris Disspain presentó la moción y Mike Silber apoyó la resolución.

      Luego, el Comité adoptó la siguiente acción:

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

      Visto y considerando que, en respuesta a las cuestiones generales destacadas en el documento SAC057, la Junta Directiva de la ICANN impartió instrucciones al Presidente y Director Ejecutivo, previa consulta con el SSAC, para que encomendara un estudio sobre el uso de dominios de alto nivel (TLD) que actualmente no se encuentran delegados a nivel de la zona raíz del DNS público (Estudio sobre colisión de nombres).

      Visto y considerando que, el Estudio sobre Colisión de Nombres, junto con una propuesta para la gestión de los riesgos identificados en dicho estudio (la "Propuesta"), fue publicado para comentario público entre el 5 de agosto y el 17 de septiembre. La Propuesta ha sido modificada en función de los comentarios recibidos.

      Visto y considerando que, el NGPC está adoptando esta acción de conformidad con la autoridad que le fue concedida por la Junta Directiva el 10 de Abril de 2012 para ejercer la autoridad de la Junta Directiva de la ICANN respecto de todas y cada una de las cuestiones que pudieran surgir en relación con el Programa de Nuevos gTLD.

      Resuélvase (2013.10.07.NG01): El Comité para el Programa de Nuevos gTLD (NGPC) solicita al Presidente de la División de Dominios Genéricos que implemente la propuesta para gestionar las colisiones entre nuevos gTLD y los usos privados existentes de las mismas cadenas de caracteres, según se presenta en el "Plan para la gestión de colisiones de nuevos gTLD" adjunto como Anexo 1 [PDF, 844 KB], y que, al hacerlo, tenga en cuenta todo asesoramiento que pudiera brindar el SSAC y demás expertos y partes interesadas.

      Resuélvase (2013.10.07.NG02): El NGPC solicita al Presidente y Director Ejecutivo de la ICANN –y, según sea conveniente, a este a través del Presidente de la División de Dominios Genéricos– que oriente adecuadamente la campaña de difusión planificada. Asimismo, el NGPC recomienda a la Junta Directiva lo siguiente: (1) que el Comité de Riesgos de la Junta Directiva de la ICANN examine expresamente este asunto y presente un informe ante la Junta Directiva, y que examine la cuestión y presente informes en forma periódica; (2) que la Junta Directiva solicite al Presidente y Director Ejecutivo de la ICANN que elabore un plan a largo plazo para gestionar la colisión de nombres en la zona raíz; y (3) que la Junta Directiva solicite al Presidente y Director Ejecutivo de la ICANN que trabaje en forma conjunta con la comunidad a fin de elaborar un plan a largo plazo para retener y cuantificar los datos de los servidores raíz.

      Nueve miembros de la Junta Directiva votaron a favor de las resoluciones 2013.10.07.NG01 – 2013.10.07.NG02. Gonzalo Navarro y Ray Plzak se abstuvieron de votar. Las Resoluciones se aprobaron.

      Al abstenerse en la votación de las resoluciones, Gonzalo Navarro señaló que dada la importancia de la resolución, en tanto que el Comité parece estar de acuerdo con el contenido de la propuesta, la redacción específica es compleja e importante y requiere un tiempo adicional para su consideración. Ray Plzak señaló que su abstención se basa en los mismos fundamentos. Olga Madruga-Forti también estuvo de acuerdo con los comentarios de Gonzalo con respecto a la complejidad de las cuestiones en la resolución.

      Fundamentos de las resoluciones 2013.10.07.NG01 – 2013.10.07.NG02

      ¿Por qué el NGPC está abordando la cuestión ahora?

      En el documento SAC057: Asesoramiento del SSAC sobre certificados de nombres internos, el SSAC identificó una práctica de las entidades de certificación que, de ser explotada en forma generalizada, podría no sólo implicar riesgos para la privacidad e integridad de las comunicaciones seguras en Internet, sino también afectar el Programa de Nuevos gTLD. Por lo tanto, el SSAC aconsejó a la ICANN que tomara medidas inmediatas para mitigar los riesgos. Los problemas identificados en el documento SAC057forman parte de una categoría más general de problemas que engloba la siguiente práctica: una entidad utiliza un nombre de dominio en una red privada que incluye un TLD no delegado, el cual posteriormente es delegado en la zona raíz como parte del Programa de Nuevos gTLD.

      Hace un tiempo, la Junta Directiva de la ICANN solicitó al Presidente y Director Ejecutivo que encomendara un estudio sobre el uso de dominios de alto nivel (TLD) que no habían sido delegados a nivel de la zona raíz del DNS público. En el estudio, también se considerarían los impactos potenciales en materia de seguridad de las cadenas de caracteres solicitadas para nuevos gTLD en relación con este uso.

      El estudio requerido fue encargado y publicado el 5 de agosto de 2013 (Estudio sobre colisión de nombres). Paralelamente, una propuesta para la gestión de los riesgos identificados en dicho estudio (la "Propuesta") fue publicada para comentario público hasta el 17 de septiembre. En este momento, el NGPC está considerando adoptar la Propuesta, la cual fue modificada en función de los comentarios públicos recibidos. La adopción e implementación de la Propuesta permitirá a la ICANN seguir avanzando en la delegación de nuevos gTLD en forma segura y estable.

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

      La Propuesta bajo consideración del NGPC (adjunta a esta resolución como Anexo 1) presenta un plan para la gestión de colisiones entre nuevos gTLD y los usos privados existentes de las mismas cadenas de caracteres. La Propuesta ha sido actualizada en función de la retroalimentación recibida de la comunidad durante el foro de comentarios públicos. Un aspecto central de la Propuesta actualizada constituye la realización de un estudio adicional con miras a elaborar un marco para la gestión de colisiones de nombres. Este marco incluirá parámetros y procesos apropiados para evaluar la probabilidad de daño resultante de la colisión de nombres así como también su gravedad. Algunos de los parámetros podrían ser: cantidad de solicitudes al DNS, tipo de solicitudes al DNS, tipo de consultas, diversidad de fuentes de consulta y aparición en certificados de nombres internos. El marco deberá especificar un conjunto de evaluaciones de colisión y las correspondientes medidas de mitigación, si correspondiesen, que la ICANN o los solicitantes de TLD podrían tener que implementar por nombre de dominio de segundo nivel (SLD) visto en el conjunto de datos de Un día en la vida de Internet (DITL).

      La Propuesta brinda a los operadores de registro la opción de proceder con la delegación antes de recibir su informe de evaluación de colisión de SLD (sujeto a procesos y procedimientos establecidos). Si el operador de registro opta por esta vía alternativa para la delegación, debe bloquear inicialmente todos los SLD que aparecen en el conjunto de datos de DITL mientras se realiza la evaluación.

      Asimismo, la Propuesta recomienda la implementación de un proceso que permita a las partes afectadas presentar un informe y solicitar el bloqueo de un SLD que esté causando daños graves demostrables como consecuencia de una colisión de nombres. El proceso tiene por objetivo mitigar el riesgo de impacto grave que pudieran presentar colisiones no observadas en el conjunto de datos del estudio.

      Por último, la Propuesta describe una campaña de difusión orientada a posibles afectados con el fin de ayudarlos a identificar y gestionar las fuentes (causas) de las colisiones de nombres en sus redes. Como parte de la campaña de difusión externa, la ICANN invitaría, para trabajar junto a ellos, a terceros y a otros miembros de la comunidad que estén interesados en avanzar en este tema. El NGPC está resolviendo solicitar al Presidente y Director Ejecutivo de la ICANN que oriente apropiadamente esta campaña de difusión propuesta.

      La Propuesta completa puede consultarse en el Anexo 1 [PDF, 844 KB].

      El NGPC también está recomendando a la Junta Directiva de la ICANN que solicite al Presidente y Director Ejecutivo de esta corporación, por un lado, que elabore un plan a largo plazo para gestionar los riesgos de colisión de nombres relacionados con la delegación de nuevos TLD y, por el otro, que trabaje con la comunidad en la elaboración de un plan a largo plazo para retener y cuantificar los datos de los servidores raíz.

      Asimismo, el NGPC recomienda a la Junta Directiva de la ICANN que el Comité de Riesgo analice expresamente este asunto en forma periódica e informe al respecto a la Junta.

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

      La ICANN presentó los resultados del Estudio sobre colisión de nombres durante la reunión que esta corporación llevó a cabo en Durban, Sudáfrica. Además, la ICANN abrió un foro de consulta pública desde el 5 de agosto hasta el 17 de septiembre de 2013 e invitó a la comunidad a brindar retroalimentación sobre el Estudio sobre colisión de nombres y sobre la Propuesta. Durante el período de comentario público, se recibieron 75 comentarios. El informe que resume los comentarios recibidos así como los comentarios en su totalidad pueden consultarse en http://forum.icann.org/lists/comments-name-collision-05aug13/. En respuesta a los comentarios públicos, el personal actualizó la Propuesta bajo consideración del NGPC a fin de incorporar mejoras adicionales al plan para la gestión de colisiones de nombres.

      ¿Qué inquietudes o cuestiones mencionó la comunidad?

      Algunos miembros de la comunidad señalaron preocupación general por el hecho de que el tema de la colisión de nombres se esté tratando en una etapa tan tardía del proceso de nuevos gTLD y preguntaron por qué la ICANN no se había ocupado del asunto antes. Los comentarios que mencionaban preocupación por los tiempos manejados también solicitaron que se extendiera el período de comentarios a fin de brindar más tiempo a la comunidad para analizar estas cuestiones y hacer comentarios significativos.

      Algunos miembros de la comunidad sugirieron que los riesgos identificados en el Estudio sobre colisión de nombres tal vez fueron sobrestimados y señalaron que solo el 3% del total de solicitudes a los servidores de TLD del DNS entra en conflicto con cadenas de caracteres que están siendo consideradas en el marco del Programa de Nuevos gTLD. Algunos sugirieron que, dado el alcance del problema, una demora de entre tres y seis meses no garantiza la mitigación.

      Otros señalaron que en incorporaciones anteriores de nuevos TLD (por ejemplo, .xxx, .asia) no hubo problemas conocidos, y afirmaron que estas delegaciones exitosas demostraban que no había necesidad de demorar las cadenas de caracteres salvo las dos más riesgosas. Algunos comentarios plantearon que no había ningún motivo comprobado para demorar la delegación de los TLD solicitados que actualmente se encuentran categorizados como de "bajo riesgo" y de "riesgo no calculado".

      Varios miembros de la comunidad comentaron sobre la validez o la aplicabilidad de los datos de muestra utilizados en el Estudio sobre colisión de nombres, o sobre la metodología empleada para evaluar los riesgos. Estos comentarios indicaron que contar la cantidad de solicitudes de cada cadena de caracteres solamente no bastaba a la hora de evaluar riesgo, y señalaron que debía considerarse la gravedad de las consecuencias así como también la frecuencia. Los comentarios también sugirieron que el Estudio sobre colisión de nombres carecía de datos críticos, a saber: tráfico de dominios inexistentes (NXD) en TLD existentes o subdominios específicos que reciben tráfico de NXD en TLD clasificados como de "riesgo no calculado". Asimismo, los comentaristas que mostraron preocupación respecto de la metodología argumentaron que el umbral establecido para dividir las cadenas de caracteres en las categorías de "bajo riesgo" y "riesgo no calculado" (80%/20%) era arbitrario.

      Algunos comentaristas recomendaron que la ICANN lanzara una campaña agresiva para educar a las empresas de todo el mundo respecto de cómo prepararse bien para la colisión de nombres.

      Otros comentaristas sugirieron que la ICANN debía estar preparada para aplazar la introducción al DNS de nuevos gTLD que sean identificados como posible amenaza de colisión en futuros estudios detallados de dicha corporación. Estos aplazamientos deberían permanecer en efecto para cada cadena de caracteres de un gTLD identificada hasta tanto las amenazas relacionadas con esa cadena puedan eliminarse sustancialmente.

      ¿Qué materiales significativos revisó la Junta Directiva?

      ¿Qué factores consideró importantes la Junta Directiva?

      El NGPC consideró varios factores significativos durante sus deliberaciones sobre la adopción de la Propuesta para la gestión de riesgos asociados a la colisión de nombres. Los siguientes factores fueron considerados importantes por el NGPC:

      • El NGPC analizó las recomendaciones del SSAC plasmadas en el documento SAC057.

      • Diversos comentaristas señalaron que basarse solamente en la frecuencia de solicitudes al DNS para evaluar los riesgos no era suficiente y que la ICANN debía considerar una serie de parámetros adicionales (por ejemplo, frecuencia de solicitudes, tipo de consulta, tipo de solicitud, etc.) para definir el nivel de riesgo. Algunos comentarios sostienen que la ICANN utilizó métodos arbitrarios para dividir las cadenas de caracteres en categorías de riesgo. La ICANN está de acuerdo en que deberían considerarse otros parámetros, además de la frecuencia de solicitudes, a la hora de evaluar el riesgo, en particular los posibles daños resultantes de la colisión de nombres. Asimismo, tendrá en cuenta el asesoramiento referente al uso de los otros parámetros propuestos cuando realice el estudio para establecer la probabilidad y el impacto (por ejemplo, daño) producto de la colisión de nombres.

      • Varios comentaristas propusieron nuevas ideas para gestionar los riesgos asociados a la colisión de nombres. Por ejemplo, algunos miembros de la comunidad propusieron bloquear temporalmente determinados dominios de segundo nivel (SLD) a fin de lograr un equilibrio entre avanzar con la delegación de nuevos gTLD y preservar el comportamiento del DNS esperado por los resolutores de DNS correspondientes a entidades que utilizan nombres bajo nuevos gTLD en redes privadas que filtran al DNS público. El personal de la ICANN está de acuerdo en que bloquear temporalmente los SLD que aparecieron en los datos de DITL (es decir, prohibir que estos nombres resuelvan en los nuevos TLD delegados) debería garantizar que las correspondientes solicitudes al DNS que actualmente filtran al DNS público seguirán siendo respondidas con el mensaje name error (NXDOMAIN) [error de nombre (DOMINIO INEXISTENTE)], y que esta medida minimizará la posibilidad de daño mientras el bloqueo esté vigente. La Propuesta adopta esta recomendación.

      • Varios miembros de la comunidad solicitaron que se extendiera el período de comentarios públicos a fin de conceder a la comunidad más tiempo para estudiar los riesgos en sus redes. Dadas las revisiones efectuadas a la Propuesta, incluida la adopción del bloqueo temporal de determinados SLD, la ICANN considera que las partes potencialmente afectadas tendrán más tiempo para estudiar los problemas en sus redes sin resultar afectadas por la delegación de nuevos gTLD. Asimismo, a fin de abordar los efectos de SLD que no hayan sido temporalmente bloqueados pero que generen daño significativo, los operadores de registro implementarán un proceso que permita a las partes afectadas informar la situación y solicitar la suspensión de un nombre de dominio que esté causando daño significativo debido a una colisión de nombres.

      • Varios comentaristas opinaron que la ICANN debía implementar una campaña de difusión externa para educar a posibles afectados sobre la colisión de nombres y su potencial impacto. La ICANN acusó recibo de la solicitud y modificó la Propuesta a fin de incluir una campaña de difusión como parte de la propuesta actualizada para la gestión de colisiones de nombres.

      ¿Se observan impactos positivos o negativos en la comunidad? ¿Se observan ramificaciones o impactos fiscales en la ICANN (plan estratégico, plan operativo, presupuesto), la comunidad y/o el público? ¿Se observa alguna cuestión de seguridad, estabilidad o flexibilidad relacionada con el DNS?

      En el documento SAC057 y en el Estudio sobre colisión de nombres, se han identificado varios riesgos en materia de seguridad para el DNS. La Propuesta, modificada en respuesta a los comentarios de la comunidad, proporciona un curso de acción a seguir para la delegación segura y estable de nuevos gTLD. La acción adoptada por el NGPC de solicitar a la Presidencia de la División de Dominios Genéricos que avance con la implementación de la Propuesta tendrá un impacto positivo para la comunidad, ya que permitirá a la ICANN delegar nuevos gTLD cuando el daño potencial resultante de la delegación de un TLD solicitado sea considerado pequeño.

      Es posible que la Propuesta genere un impacto fiscal sobre la ICANN, la comunidad o el público, ya que habrá costos adicionales asociados a la implementación de las medidas de mitigación detalladas en la Propuesta, las cuales podrían incluir recursos adicionales para desarrollar una campaña de difusión orientada a posibles afectados con el fin de ayudarlos a identificar y gestionar las colisiones de nombres en sus redes.

      Como parte de su función organizacional y administrativa, la ICANN publicó para comentario público el Estudio sobre colisión de nombresy la propuesta para la gestión de los riesgos por colisión de nombres identificados. El informe sobre los comentarios recibidos se encuentra disponible en el siguiente enlace: http://forum.icann.org/lists/comments-name-collision-05aug13/.

      El Presidente dio por concluida la reunión.

minutes-new-gtld-07oct13-es.pdf  [205 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."