Skip to main content
Resources

Actas | Reunión ordinaria de la Junta Directiva de la ICANN

Esta página está disponible en:

El 9 de septiembre de 2014, a las 16:15 hora local, se realizó una reunión ordinaria de la Junta Directiva de la Corporación para la Asignación de Nombres y Números en Internet (ICANN) en Estambul, Turquía.

Steve Crocker, Presidente de la Junta Directiva, declaró abierta la sesión.

Los siguientes directores participaron en forma total o parcial de la reunión: Sébastien Bachollet, Cherine Chalaby, Fadi Chehadé (Presidente y Director Ejecutivo), Chris Disspain, Bill Graham, Wolfgang Kleinwächter, Bruce Tonkin (Vicepresidente), Mike Silber, Gonzalo Navarro, George Sadowsky, Olga Madruga-Forti, Bruno Lanvin, Erika Mann y Kuo-Wei Wu.

Los siguientes directores presentaron sus disculpas por no poder estar presentes: Ray Plzak.

Los siguientes coordinadores de enlace de la Junta Directiva participaron en forma total o parcial de la reunión: Heather Dryden (Coordinadora de Enlace del Comité Asesor Gubernamental —GAC—), Ram Mohan (Coordinador de Enlace del Comité Asesor de Seguridad y Estabilidad —SSAC—), Thomas Narten (Coordinador de Enlace de la Fuerza del Trabajo en Ingeniería de Internet —IETF—) y Suzanne Woolf (Coordinadora de Enlace del Comité Asesor del Sistema de Servidores Raíz —RSSAC—).

Secretario: John Jeffrey (Asesor Jurídico y Secretario)

Asistentes invitados: Rinalia Abdul Rahim, Markus Kummer y Asha Hemrajani

Los siguientes ejecutivos e integrantes del personal de la ICANN participaron en forma total o parcial de la reunión: Akram Atallah (Presidente de la División Global de Dominios); Susanna Bennett (Directora Operativa); Megan Bishop (Coordinadora de Apoyo para la Junta Directiva); David Olive (Vicepresidente de Desarrollo de Políticas); Xavier Calvez (Director Financiero); Samantha Eisner (Asesora Sénior); Vinciane Koenigsfeld (Gerenta de Contenido de Apoyo para la Junta Directiva); Erika Randall (Asesora); Ashwin Rangan (Director de Innovación e Información); Amy Stathos (Asesora Jurídica Adjunta); y Theresa Swinehart (Asesora Sénior del Presidente en materia de Estrategia Global).

  1. Orden del día principal
    1. Designación del Presidente y Presidente Electo del Comité de Nominaciones para 2015
  2. Orden del día convenido:
    1. Aprobación de las actas de las reuniones de la Junta Directiva
    2. Designación de Benedict Addis como integrante del Comité Asesor de Seguridad y Estabilidad (SSAC)
    3. Agradecimiento del Comité Asesor de Seguridad y Estabilidad (SSAC) a David Conrad
  3. 3. Orden del día principal
    1. Informe del Informe del Panel de Evaluación Técnica de Servicios de Registro (RSTEP) sobre la solicitud del Registro de Interés Público para implementar la vinculación técnica en .NGO y .ONG
    2. Planificación de rondas futuras de solicitudes de gTLD
    3. Plan Operativo y Presupuesto para el Año Fiscal 2015 (FY15)
    4. Versión preliminar final del Plan estratégico de cinco años de la ICANN (FY16-FY20)
    5. Reconocimiento de la declaración de la Segunda Cumbre de At-Large
    6. Otros temas a tratar

 

  1. Orden del día principal

    1. Designación del Presidente y Presidente Electo del Comité de Nominaciones para 2015

      Cherine Chalaby presentó la resolución propuesta y Chris Disspain la secundó.

      Bruce Tonkin presentó el tema del orden del día y destacó que el Comité de Gobernanza de la Junta Directiva recomienda a la Junta Directiva que Stephane Van Gelder sea designado como el Presidente del Comité de Nominaciones para el año 2015. El BGC brindará una recomendación respecto del Presidente Electo del Comité de Nominaciones para el año 2015 en otro momento.

      El Presidente llamó a votación y la Junta directiva tomó la siguiente medida:

      Visto y considerando que, el BGC analizó las manifestaciones de interés de los candidatos para el Presidente y Presidente Electo del Comité de Nominaciones ("NomCom") de 2014, consideró los resultados de una evaluación de 360 grados del liderazgo de NomCom de 2014 y evaluó la respuesta a las preguntas formuladas por el BGC a cada candidato.

      Visto y considerando que, el BGC ha recomendado que Stephane Van Gelder sea designado como el Presidente del NomCom para el año 2015.

      Resuélvase (2014.09.09.01), la Junta Directiva por el presente designa a Stephane Van Gelder como el Presidente del Comité de Nominaciones para el año 2015.

      Trece miembros de la Junta Directiva votaron a favor de la resolución 2014.09.09.01. Fadi Chehadé, Sébastien Bachollet y Ray Plzak no estuvieron disponibles para votar sobre la resolución. La Resolución se aprobó.

      Fundamento de la resolución 2014.09.09.01

      De conformidad con los Estatutos de la ICANN, la Junta Directiva debe designar al Presidente y Presidente Electo del Comité de Nominaciones (NomCom). Consulte el artículo VII, secciones 2.1 y 2.2 en http://www.icann.org/en/general/bylaws.htm#VII. La Junta Directiva ha delegado la responsabilidad de recomendar el Presidente y el Presidente Electo del NomCom para la aprobación de la Junta Directiva al Comité de Gobernanza de la Junta Directiva. Consulte la carta orgánica del BGC en http://www.icann.org/en/committees/board-governance/charter.htm. El BGC publicó dos veces una convocatoria de manifestaciones de interés (EOI) (consultehttps://www.icann.org/news/announcement-2-2014-07-01-en), recibió y analizó las EOI recibidas, supervisó una evaluación de 360 grados del liderazgo del NomCom de 2014 y planea realizar entrevistas con algunos de los candidatos antes de formular su recomendación sobre el Presidente Electo del NomCom para 2015. La Junta Directiva ha considerado y está de acuerdo con la recomendación del BGC del Presidente del NomCom para 2015 y espera la recomendación del BGC respecto del Presidente Electo del NomCom para 2015. Asimismo, la Junta Directiva desea agradecerles a todos los que manifestaron su interés en formar parte del liderazgo del NomCom.

      La designación de un Presidente y un Presidente Electo del NomCom identificados mediante un proceso público de EOI afecta positivamente la transparencia y la responsabilidad de la ICANN, y respalda el interés público. La adopción de la recomendación del BGC no tiene un impacto económico en la ICANN que no se haya previsto y no se observará un impacto negativo en la seguridad, la estabilidad ni la flexibilidad del sistema de nombres de dominio.

  2. Orden del día convenido:

    TEl Presidente brindó una breve descripción general de los temas del orden del día convenido. Luego, el Presidente llamó a votación y la Junta Directiva tomó la siguiente medida:

    Resuélvase, se aprueban las siguientes resoluciones de este orden del día convenido:

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

      Resuélvase (2014.09.09.02), la Junta Directiva de la ICANN aprueba las actas de sus reuniones del día 30 de julio de 2014.

    2. Designación de Benedict Addis como integrante del Comité Asesor de Seguridad y Estabilidad (SSAC)

      Visto y considerando que, el Comité Asesor de Seguridad y Estabilidad (SSAC) analiza su composición ocasionalmente y efectúa las modificaciones que considera pertinentes.

      Visto y considerando que el Comité de Membresía del SSAC, en representación del SSAC, solicita que la Junta Directiva designe a Benedict Addis para integrar dicho comité.

      Resuélvase (2014.09.09.03), la Junta Directiva designa a Benedict Addis como integrante del SSAC.

      Fundamento de la resolución 2014.09.09.03

      El SSAC es un grupo diverso de personas cuyos conocimientos sobre temas específicos permiten que el comité cumpla con su carta orgánica y lleve a cabo su misión. Desde su creación, el SSAC ha invitado a personas con amplios conocimientos y gran experiencia en áreas técnicas y de seguridad que son fundamentales para la seguridad y la estabilidad del sistema de direcciones y nombres de dominio de Internet.

      Las operaciones continuas del SSAC como organismo competente dependen del aporte y el talento de expertos que han aceptado contribuir voluntariamente con su tiempo y energía para llevar a cabo la misión del comité. Benedict Addis es un funcionario técnico del Departamento contra Delitos Informáticos de la Agencia del Crimen Organizado (SOCA), un organismo de aplicación de la ley del Reino Unido. Tiene sólidos conocimientos en seguridad de redes y ciencias informáticas, lo que constituye una parte integral de sus responsabilidades de aplicación de la ley. Ha trabajado activamente en actividades delictivas de internet y de abuso de Internet durante muchos años. El Sr. Addis ofrece una valiosa perspectiva al SSAC respecto de la intersección de la política gubernamental y la aplicación de la ley.

    3. Agradecimiento del Comité Asesor de Seguridad y Estabilidad (SSAC) a David Conrad

      Visto y considerando que, la Junta Directiva designó a David Conrad como integrante del SSAC el 18 de marzo de 2011.

      Visto y considerando que, el Sr. Conrad renunció al SSAC el día 01 de agosto de 2014.

      Visto y considerando que, la ICANN desea expresar su reconocimiento y agradecimiento al Sr. Conrad por su servicio a la comunidad mediante su participación en el SSAC.

      Resuélvase (2014.09.09.04), David Conrad se ha ganado el profundo agradecimiento de la Junta Directiva por su servicio a la ICANN mediante su participación en el SSAC, y la Junta Directiva le desea lo mejor en todos sus emprendimientos futuros.

      Fundamento de la resolución 2014.09.09.04

      Es práctica habitual del SSAC promover el reconocimiento de la Junta Directiva al servicio de los miembros del Comité en el momento de su retiro.

    4. Todos los miembros de la Junta Directiva que estaban presentes votaron a favor de las resoluciones 2014.09.09.02, 2014.09.09.03, 2014.09.09.04. Fadi Chehadé, Sébastien Bachollet y Ray Plzak no estuvieron disponibles para votar sobre las resoluciones. Las Resoluciones se aprobaron.

  3. Orden del día principal

    1. Informe del Panel de Evaluación Técnica de Servicios de Registro (RSTEP) sobre la solicitud del Registro de Interés Público para implementar la vinculación técnica en .NGO y .ONG

      Antes de considerar esta cuestión, Ram Mohan identificó que tiene un conflicto de interés en este tema debido a su empleo. Ram fue invitado a participar en la discusión debido a su experiencia en este área.

      George Sadowsky presentó la resolución propuesta, la cual fue secundada por Bruce Tonkin.

      El Presidente presentó el tema del orden del día y brindó información contextual respecto del Panel de Evaluación de Servicios de Registro (RSEP) y el Panel de Evaluación Técnica de Servicios de Registro (RSTEP). El Presidente explicó que se trata de un proceso de dos niveles. El RSEP aborda los cambios contractuales solicitados y son manejados por el personal. Luego, si el cambio contractual solicitado incluye un cambio técnico que puede tener implicancias en la seguridad, hay una evaluación secundaria del RSTEP que implica un panel de expertos. Una vez que el RSTEP presenta el informe, la Junta Directiva tiene 30 días para tomar una determinación. El Presidente indicó que hay una cuestión respecto de si las reglas de RSEP/RSTEP son adecuadas o si deben adaptarse, pero ese no es el tema de discusión en este punto.

      El Presidente luego brindó una breve descripción general del Informe de RSTEP respecto de la solicitud del Registro de Interés Público (PIR) sobre la vinculación técnica obligatoria de los dominios de segundo nivel para .NGO y .ONG (Las formulaciones de TLD anglófonos y francófonos). Indicó que, de acuerdo con el Informe, no hay cuestiones relacionadas con la seguridad y la estabilidad respecto de la solicitud pero tampoco hay garantía de que la sincronía se mantenga de manera indefinida, y el Informe recomienda de se definan ciertos detalles durante el proceso de contratación.

      Rinalia Abdul Rahim formuló la pregunta de si una decisión por parte de la Junta Directiva de permitir al PIR requerir la vinculación técnica de dominios de segundo nivel para .NGO y .ONG afectaría el manejo de variantes de Nombres de Dominio Internacionalizados (IDN). Ram Mohan explicó que existen precedentes para la vinculación del lado de ccTLD. En el caso de China, Hong Kong y Taiwán, por ejemplo, varios TLD se han asignado y se están administrando de manera conjunta por política en lugar de por maniobras técnicas. Ram también explicó que, con respecto al caso del PIR específicamente, los TLD .NGO y ONG no son visiblemente similares ni son similares en significado a menos que se haya entendido que uno era francófono y el otro anglófono. Asimismo, si se aplican las reglas que se han generado hasta ahora para variantes de IDN, los TLD del PIR aún califican dado que ambos son nombres ASCII que ya han sido aceptados en el repertorio mínimo de cadenas de caracteres para un TLD. Asimismo, Ram destacó que, generalmente en el esquema de variantes de IDN, es una cuestión sobre palabras tener una variante; mientras que, en este caso, los TLD tienen dos abreviaturas distintas. Suzanne Woolf comentó que está de acuerdo con la explicaciones que brindó Ram sobre las realidades, pero aún cree que la Junta Directiva debe estar preparada para la expectativa de que la decisión de permitir la solicitud de vinculación del PIR sea vista como un precedente para forzar algunos de los procesos continuos respecto de las variantes y la vinculación de IDN. Mike Silber destacó que estaba de acuerdo con el punto de Suzanne y sugirió que el fundamento deje en claro que esto no tiene la intención de crear un precedente y cada circunstancia debe evaluarse por sus propios méritos.

      El Presidente llamó a votación y la Junta directiva tomó la siguiente medida:

      Visto y considerando que, el 12 de marzo de 2014, el Registro de Interés Público (PIR) presentó una solicitud de Política de Evaluación de Servicios de Registro (RSEP) [PDF, 25 KB] para ofrecer la vinculación técnica obligatoria de los nombres de dominio de segundo nivel para .NGO y .ONG según el Anexo A de cada acuerdo de registro respectivo.

      Visto y considerando que, el 21 de mayo de 2014, el personal de la ICANN posted la solicitud de RSEP para información pública y realizó su revisión de la solicitud conforme a RSEP.

      Visto y considerando que, el 4 de junio de 2014, la determinación preliminar del personal de la ICANN no identificó ninguna cuestión significativa relativa a la competencia. De manera independiente, el personal de la ICANN determinó que el servicio de registro propuesto puede presentar cuestiones significativas relativas a la estabilidad o seguridad, e informó [PDF, 317 KB] al PIR de la necesidad de remitir la propuesta al Panel de Evaluación Técnica de Servicios de Registro (RSTEP) para su mayor evaluación.

      Visto y considerando que, el 6 de junio de 2014, la ICANN remitió la solicitud de RSEP del PIR [PDF, 949 KB] al RSTEP para su mayor evaluación.

      Visto y considerando que, el 10 de junio de 2014, la ICANN publicó la solicitud de RSEP del PIR para comentarios públicos. El período de comentarios públicos finalizó el 30 de julio de 2014 y no se recibió ningún comentario público.

      Visto y considerando que, el 29 de julio de 2014, el informe de RSTEP fue publicado para comentarios públicos. El período de comentarios públicos finalizó el 13 de agosto de 2014 y no se recibió ningún comentario público.

      Visto y considerando que, el informe de RSTEP llegó a la conclusión de que, desde una perspectiva de evaluación técnica, la propuesta no crea "un riesgo razonable de un efecto adverso significativo sobre la estabilidad o la seguridad" como se define en la política de RSEP relativa a la incorporación del servicio de registro para apoyar la vinculación técnica obligatoria de nombres de dominio de segundo nivel para .NGO y .ONG. Asimismo, el personal y el informe de RSTEP identificaron varias posibles preguntas técnicas y de implementación asociadas con la incorporación del servicio de registro nuevo propuesto al DNS, entre ellas: implicancias de la desvinculación de .NGO y .ONG; posible confusión del usuario final o registratario; cuestiones de equivalencia analizadas dentro del contexto de variantes de IDN; y otras inquietudes operativas.

      Resuélvase (2014.09.09.05), la Junta Directiva adopta las conclusiones contenidas en el informe de RSTEP de que la propuesta no crea "un riesgo razonable de un efecto adverso significativo sobre la estabilidad o la seguridad" y aprueba la solicitud del PIR relativa a la incorporación del servicio de registro para apoyar la vinculación técnica obligatoria de nombres de dominio de segundo nivel para .NGO y .ONG.

      Resuélvase (2014.09.09.06), la Junta Directiva autoriza al Presidente y Director Ejecutivo, o a quien éste designe, a desarrollar una enmienda para implementar el nuevo servicio de registro que tome en cuenta y aborde adecuadamente las cuestiones pendientes relacionadas con los aspectos técnicos y de implementación.

      Catorce miembros de la Junta Directiva votaron a favor de las resoluciones 2014.09.09.05 y 2014.09.09.06. Fadi Chehadé y Ray Plzak no estuvieron disponibles para votar sobre las resoluciones. Las Resoluciones se aprobaron.

      Fundamentos de las resoluciones 2014.09.09.05 y 2014.09.09.06

      ¿Por qué la Junta Directiva está abordando el tema?

      El 12 de marzo de 2014, el Registro de Interés Público (PIR), operador del registro de los TLD .NGO y .ONG, presentó una solicitud para brindar un nuevo servicio de registro con el fin de brindar el apoyo correspondiente a la vinculación técnica obligatoria para los dominios de segundo nivel de .NGO y .ONG. La propuesta brinda una explicación de la vinculación técnica propuesta, la implementación de comandos de EPP, el manejo de las DNSSEC, el manejo de variantes de IDN de segundo nivel y el servicio del WHOIS. La propuesta, que se presentó mediante el proceso de Política de Evaluación de Servicios de Registro (RSEP), fue remitida al Panel de Evaluación Técnica de Servicios de Registro (RSTEP); tanto dicha propuesta como el informe de RSTEP fueron abiertos respetuosamente para comentarios públicos como lo requiere RSEP.

      De conformidad con la sección 2.7 de la Política de Evaluación de Servicios de Registro (RSEP), la Junta Directiva tuvo 30 días calendario posteriores a la recepción del informe del Panel de Evaluación Técnica de Servicios de Registro el 24 de julio de 2014 para tomar una decisión. La Junta Directiva puede decidir 1) aprobar la solicitud, 2) rechazar la solicitud, o 3) postergar la solicitud para obtener más información.

      ¿Cuál es la propuesta que está siendo considerada?

      La acción de la Junta Directiva de hoy es tomar medidas sobre el informe de RSTEP, que evaluó las cuestiones relativas a la seguridad y la estabilidad que pueden asociarse con la solicitud de RSEP del PIR para implementar un nuevo servicio de registro a fin de permitir la "vinculación técnica" obligatoria de nombres de dominio de segundo nivel. La solicitud del PIR estipula, "[a] La vinculación técnica es un conjunto de dos nombres de dominio en diferentes TLD, con etiquetas de segundo nivel idénticas que comparten los siguientes parámetros:

      • Titularidad del registrador
      • Fechas de registración y vencimientos
      • Contactos técnicos, de registrador, administración y facturación
      • Asociación de servidores de nombres
      • Estado del dominio
      • Períodos de gracia aplicables (período de gracia adicional, período de gracia renovable, período de gracia con renovación automática, período de gracia de transferencia y período de gracia de redención)
      • Y para los que al menos los siguientes parámetros son únicos: registros de DS como se requieren en función de RFC 5910".

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

      El personal de la ICANN realizó un foro de comentarios públicos del 10 de junio de 2014 al 8 de julio de 2014, el cual invitaba a la comunidad a brindar comentarios sobre la propuesta de RSEP del PIR. Durante el período de comentarios públicos, no se recibieron comentarios. El informe final de comentarios públicos está disponible en: https://www.icann.org/public-comments/tech-bundling-2014-06-10-en.

      Además, el equipo de revisión de RSTEP fue consultado para realizar una evaluación técnica del servicio de registro propuesto con respecto a la probabilidad y la importancia de los efectos en la seguridad y la estabilidad, incluso si el servicio de registro propuesto crearía un riesgo razonable de un efecto adverso significativo en la seguridad o la estabilidad. El 24 de julio de 2014, el informe de RSTEP [PDF, 1.02 MB] fue entregado a la comunidad de la ICANN. La ICANN realizó un foro de comentarios públicos del 29 de julio de 2014 al 5 de agosto de 2014, el cual invitaba a la comunidad a brindar comentarios sobre el informe de RSTEP. Durante el período de comentarios públicos, no se recibieron comentarios. El informe final de comentarios públicos está disponible en: https://www.icann.org/public-comments/rstep-technical-bundling-2014-07-29-en.

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

      No se formularon comentarios durante el período de comentarios públicos para la propuesta de RSEP ni durante el período de comentarios públicos para el informe de RSTEP. Sin embargo, las siguientes cuestiones técnicas y de implementación fueron identificadas en el informe de RSTEP y por la ICANN, que deberán ser abordadas por el PIR [o la comunidad] como parte del desarrollo de una enmienda a los acuerdos de registro de .NGO y .ONG para implementar el nuevo servicio de registro:

      • Análisis sobre las implicancias de la "desvinculación", es decir, si en algún momento futuro, la decisión es tomada por el PIR (o un registro sucesor) de eliminar la asociación explícita entre .NGO y .ONG.

      • La propuesta del PIR tiene implícita una afirmación de que el contenido de los dominios .NGO y .ONG es "el mismo" (por ello, están vinculados); sin embargo, no hay ningún mecanismo por el cual se pueda aplicar esta similitud en todos los niveles del DNS, ni las aplicaciones como servidores web, servidores de correo, etc., comprenderán que los dominios .NGO y .ONG deben ser tratados de manera idéntica sin configuración explícita. Esto puede generar una confusión para los usuarios finales clientes (por ejemplo, "¿por qué EJEMPLO.ALGO.ONG se resuelve cuando EJEMPLO.ALGO.NGO no lo hace?") y para los registratarios ("¿por qué tengo que configurar mi servidor web para comprender cada dominio de tercer nivel para mi dominio de segundo nivel en .NGO y .ONG?"). Se precisa información adicional para abordar esta posible confusión dentro de la propuesta del PIR;

      • La cuestión de similitud de etiquetas; específicamente dos etiquetas son interpretadas como "iguales" aunque las cadenas que las conforman son diferentes, cuestión implícita en la propuesta del PIR, para las cuales la vinculación es una posible solución, probablemente puedan considerarse como equivalentes funcionalmente a un componente de la cuestión de "variantes de IDN". La comunidad ha estado trabajando en soluciones para la cuestión de las variantes durante varios años y aún no se ha llegado a una resolución total. Es posible que la comunidad que trabaja sobre la cuestión de las variantes consideren una aceptación de la vinculación técnica de .NGO y .ONG como una "maniobra de evasión" inapropiada en torno a las políticas y los procesos que se establecen para el manejo de las variantes; y

      • La vinculación técnica está siendo considerada como una posible solución para abordar las variantes de IDN; sin embargo, la comunidad no ha desarrollado un marco para su uso ni aprobado este enfoque para su implementación. La aceptación de la propuesta del PIR, y avanzar sin mayores aportes de la comunidad sobre la vinculación técnica, puede plantear inquietudes con los solicitantes de variantes de IDN y otros miembros interesados de la comunidad que desearían analizar este tema para la implementación de TLD con variantes de IDN.

      ¿Qué materiales significativos fueron examinados por la Junta Directiva? ¿Qué factores consideró importantes la Junta Directiva?

      La Junta Directiva analizó varios materiales para tomar esta medida hoy. Asimismo, consideró varios factores importantes durante sus deliberaciones sobre si aprobar o no la solicitud. Los materiales y factores importantes que la Junta Directiva consideró como parte de sus deliberaciones, incluyeron, a modo de ejemplo, los siguientes:

      ¿Existen impactos positivos o negativos para la comunidad? ¿Se observan impactos fiscales o ramificaciones en la ICANN (plan estratégico, plan operativo, presupuesto), la comunidad o el público? ¿Se observan cuestiones sobre seguridad, estabilidad o flexibilidad relacionadas con el DNS?

      El PIR identificó que los beneficios de incorporar la vinculación técnica obligatoria serían dos: (1) elimina la probabilidad de confusión pública que razonablemente puede resultar si entidades de gTLD diferentes pudieron registrar el mismo dominio de segundo nivel y (2) proporciona al registratario una registración defensiva a fin de garantizar que el gTLD pueda centrarse en su misión y difusión de manera transparente y eficaz. Sin embargo, se requiere más información para comprender los posibles impactos adicionales sobre la comunidad en relación con las implicancias generales de este servicio cuando se incorpora al DNS.

      La eventual implementación de este servicio de registro puede tener un impacto fiscal sobre la ICANN, la comunidad o el público, ya que pueden existir costos adicionales asociados con las implicancias generales de este servicio de registro.

      El informe de RSTEP identificó la evaluación técnica de este servicio de registro propuesto respecto de la probabilidad e importancia de los efectos sobre las seguridad y la estabilidad, y llega a la conclusión de que no se genera un riesgo razonable de un efecto adverso significativo sobre la seguridad y la estabilidad.

      Varias comunidades, en particular aquellas interesadas en variantes de IDN, han estado trabajando en soluciones a las cuestiones de similitud de etiquetas, de las cuales la vinculación técnica de .NGO y .ONG es un ejemplo, durante varios años y aún no se ha llegado a una resolución total. Es posible que dichas comunidades puedan ofrecer conocimientos en la resolución de cuestiones de similitud y las consultas con dichas comunidades pueden resultar pertinentes. La medida de la Junta directiva no tiene el objetivo de crear un precedente ni un requisito para el tratamiento de cuestiones relativas a las variantes de IDN y cada circunstancia debe ser evaluada según sus propios méritos.

      ¿Este es un proceso de políticas definido dentro de la organización de apoyo de la ICANN o una decisión comprendida por la función organizacional y administrativa de la ICANN que requiere comentario público o que no lo requiere?

    2. La Política de Evaluación de Servicios de Registro es una política consensuada de la ICANN, en vigencia desde el 15 de agosto de 2006. De conformidad con la política del 29 de julio de 2014, el informe de RSTEP fue publicado para comentarios públicos. El período de comentarios públicos finalizó el 13 de agosto de 2014 y no se presentó ningún comentario público. Además, el 10 de junio de 2014, la ICANN publicó la solicitud de RSEP del PIR para comentarios públicos. El período de comentarios públicos finalizó el 30 de julio de 2014 y no se presentó ningún comentario público.

    3. Planificación de rondas futuras de solicitudes de gTLD

      El Presidente presentó el tema del orden del día y comenzó una conversación respecto de cómo y si la Junta Directiva iniciaría estudios y procesos organizacionales que condujeran a otra ronda de solicitudes en el programa de nuevos gTLD. Akram Atallah destacó que desea asegurarse de que cualquier resolución sobre este tema no sea indefinida sino que enmarque el trabajo específico que debe realizarse antes de que se inicie otra ronda de solicitudes. Rinalia Abdul Rahim estuvo de acuerdo con el comentario de Akram y que cualquier resolución debe ser exacta.

      Heather Dryden destacó que cualquier resolución debe ser muy clara en lo que exactamente se está ordenando como próximos pasos que deben tomarse antes del comienzo de otra ronda de solicitudes.

      Mike Silber expresó su inquietud de que una resolución puede ser susceptible de ser circular respecto del trabajo que debe realizarse ante del inicio de otra ronda de solicitudes de gTLD cuando dicha fecha no ha sido establecida aún y no puede ser establecida hasta que se complete el trabajo previo necesario.

      Sébastien Bachollet expresó su inquietud respecto del uso de la nomenclatura "primera" y "segunda" para describir las rondas de solicitudes de gTLD y comentó que no se adapta a la realidad de la organización de la ICANN. Steve Crocker comentó que puede ser confuso volver a redactar los documentos que ya incluyen esa nomenclatura. Bruce Tonkin estuvo de acuerdo con Sébastien, destacó que ha habido varias rondas de solicitudes de gTLD durante los últimos catorce años y sugirió que se haga referencia a las rondas por año (por ejemplo, ronda de 2000, ronda de 2004 y ronda de 2012).

      Ram Mohan destacó que si la Junta Directiva debe tomar una resolución, puede interpretarse como que la Junta Directiva autoriza la próxima ronda de solicitudes y expresó su inquietud respecto de las posibles reacciones en la comunidad y la posible impresión de que la Junta Directiva se está apresurando para tomar una decisión. Ram indicó que una resolución debe conferir la ponderación del trabajo que la Junta Directiva tiene intención de realizar y la profundidad del análisis que tendrá lugar antes del inicio de otra ronda de solicitudes de gTLD.

      Wolfgang Kleinwächter reconoció las inquietudes que planteó Ram. Luego, Wolfgang preguntó si existía una estimación del tiempo necesario para la finalización del trabajo previo necesario y para el inicio de la próxima ronda de solicitudes. Akram respondió que esto depende del plazo y el trabajo que la Junta Directiva decida que debe completarse antes del inicio de la próxima ronda.

      Chris Disspain respaldó las inquietudes de Ram y propuso que la Junta Directiva eliminara la consideración de este tema en este momento, trabajara en la redacción de la resolución y luego lo debatiera durante la reunión n.° 51 de la ICANN en Los Ángeles. Akram comentó que hubo numerosas preguntas de la comunidad respecto del plazo y el procedimiento del proceso de revisión.

      La Junta Directiva acordó que se necesitaba mayor consideración y postergó este tema para su mayor análisis durante la reunión n.° 51 de la ICANN en Los Ángeles.

      No se adoptó ninguna resolución.

    4. Plan Operativo y Presupuesto para el Año Fiscal 2015 (FY15)

      George Sadowsky presentó la resolución propuesta, la cual fue secundada por Mike Silber.

      Cherine Chalaby presentó el tema del orden del día y brindó una breve descripción general de la revisión del Plan Operativo y Presupuesto para el Año Fiscal 2015 (FY15). La versión preliminar del Plan Operativo y Presupuesto para el Año Fiscal 2015 (FY15) que se publicó para comentarios públicos el 8 de mayo de 2014 previó un ingreso de USD114 millones y costos operativos de USD117 millones. Se recibieron numerosos comentarios respecto de los ingresos y los costos operativos propuestos. Una vez finalizado el período de comentarios públicos, el Comité Financiero de la Junta Directiva (BFC) consideró todos los comentarios públicos, revisó varias de las suposiciones sobre ingresos y el análisis de sensibilidad, y luego modificó el presupuesto. La versión revisada del Plan Operativo y Presupuesto para el Año Fiscal 2015 (FY15) ahora prevé un ingreso de USD14 millones y costos operativos de USD108 millones. Cherine indicó que a fin de lograr estas cifras reducidas, el BFC revisó cada una de las suposiciones sobre ingresos, una por una; y el Director Ejecutivo y el equipo de administración analizaron los costos operativos en detalle y realizaron reducciones en contratación de personal, costos de viajes, servicios profesionales, costos administrativos y gastos de capital. Asimismo, Cherine también indicó que, a fin de reducir costos, no habrá una gala en ICANN 51 en Los Ángeles ya que no hay un anfitrión local para el evento.

      Erika Mann preguntó qué tipo de reducciones en contratación de personal se propusieron. Susanna Bennett respondió y explicó que no habrá nuevas contrataciones en el año calendario 2014; todas las nuevas contrataciones se pospondrán para el año 2015. Susanna también explicó que, si es necesario, hay un proceso de excepción que puede implementarse según ciertos lineamientos. Cherine comentó que esto proporciona un reducción en costos para FY15 dado que los costos de personal se distribuyen en varios años.

      Jonne Soininen preguntó cuáles eran las reducciones en viajes que se propusieron. Susanna respondió y explicó que se le solicitó a cada miembro del Equipo Global de Liderazgo que redujera su presupuesto en viajes en un 10 % y que depende de cada departamento la forma en que se logre la reducción.

      Jonne Soininen también preguntó cuáles eran las reducciones en servicios profesionales que se propusieron. Akram respondió y explicó que, por ejemplo, su equipo ha revisado su lista de tareas, determinó qué podía realizarse internamente en vez de externamente e identificó ciertos temas que podían cancelarse o posponerse. Ashwin Rangan también respondió e indicó que el Departamento de TI se encuentra en el proceso de aprovechar los recursos como un medio para reducir cosos sin causar ningún impacto negativo en la calidad de servicio. Chris Disspain destacó que se le solicita que el uso de servicios profesionales sea asumido por el BFC y que se le pregunta en qué la ICANN está gastando dinero.

      Gonzalo Navarro formuló una pregunta respecto de por qué la Junta Directiva se centraba en la reducción de costos y no en la reasignación de ahorros. Xavier Calvez y Gonzalo acordaron mantener más discusiones sobre este tema en particular.

      Luego, Cherine leyó la resolución propuesta a la Junta Directiva.

      El Presidente llamó a votación y la Junta directiva tomó la siguiente medida:

      Visto y considerando que, la versión preliminar del Plan Operativo y Presupuesto para el Año Fiscal 2015 (FY15) fue publicada para comentarios públicos de conformidad con los Estatutos el 8 de mayo de 2014, lo que se basó en las consultas de la comunidad y las consultas al personal de la ICANN y el Comité Financiero de la Junta Directiva, durante el año fiscal pasado.

      Visto y considerando que, las actividades intervinientes y los comentarios recibidos del foro de comentarios públicos se tomaron en cuenta para determinar las revisiones importantes a la versión preliminar del Plan Operativo y Presupuesto para el Año Fiscal 2015 (FY15) el 8 de mayo de 2014.

      Visto y considerando que, además del foro de comentarios públicos, la ICANN activamente solicitó comentarios de la comunidad y consultas con la comunidad de la ICANN por otros medios, incluidas teleconferencias en línea, reuniones en Singapur y Londres. y comunicaciones por correo electrónico.

      Visto y considerando que, el Comité Financiero de la Junta Directiva ha analizado y guiado al personal en relación con el desarrollo del Plan Operativo y Presupuesto para el Año Fiscal 2015 (FY15) en cada una de sus recientes reuniones programadas regularmente.

      Visto y considerando que, el Comité Financiero de la Junta Directiva se reunió el 19 de agosto de 2014 para analizar la versión preliminar final del Plan Operativo y Presupuesto para FY15 y recomendó que la Junta Directiva adopte dicho plan.

      Visto y considerando que, en virtud de la sección 3.9 de los acuerdos de acreditación de registradores de los años 2001, 2009 y 2013, respectivamente, la Junta Directiva debe establecer tarifas variables de acreditación del registrador, las cuales deben definirse a fin de desarrollar el presupuesto anual.

      Visto y considerando que, la descripción de las tarifas del registrador, incluidas las tarifas variables de acreditación del registrador recomendadas, para el año fiscal 2015 han sido incluidas en el Plan Operativo y Presupuesto para FY15.

      Resuélvase (2014.09.09.07), la Junta Directiva adopta el Plan Operativo y Presupuesto para el Año Fiscal 2015 (FY15) y, al hacerlo, define las tarifas variables de acreditación (por registrador y transacción) como se establece en dicho plan.

      Catorce miembros de la Junta Directiva votaron a favor de la resolución 2014.09.09.07. Ray Plzak y Bruce Tonkin no estuvieron disponibles para votar sobre la resolución. La Resolución se aprobó.

      Fundamento de la resolución 2014.09.09.07

      De conformidad con el artículo XVI, sección 4 de los Estatutos de la ICANN, la Junta Directiva debe adoptar un presupuesto anual y publicarlo en el sitio web de la ICANN. El 8 de mayo de 2014, se publicó una versión preliminar del Plan Operativo y Presupuesto para el Año Fiscal 2015 (FY15) para la recepción de comentarios públicos. Esta versión se basó en numerosos debates con los miembros del equipo ejecutivo y extensas consultas con las organizaciones de apoyo y los comités asesores de la ICANN, así como con otros grupos de partes interesadas a lo largo de los meses anteriores. Las actividades intervinientes y los comentarios recibidos del foro de comentarios públicos resultaron en algunas revisiones limitadas pero importantes a la versión preliminar del Plan Operativo y Presupuesto para FY15 del 8 de mayo de 2014.

      Todos los comentarios recibidos de todas las maneras fueron considerados al elaborar la versión final del Plan Operativo y Presupuesto para el Año Fiscal 2015 (FY15), y donde los factibles y pertinentes se han adoptado.

      Además de los requisitos operativos diarios, el Plan Operativo y Presupuesto para FY15 incluye los elementos y montos del presupuesto de nuevos gTLD asignados a varias solicitudes de presupuesto para FY15 recibidas de líderes de la comunidad. El presupuesto anual también revela los impactos del programa de nuevos gTLD. Asimismo, debido a que la tarifa variable de acreditación del registrador es fundamental para el desarrollo del presupuesto, el Plan Operativo y Presupuesto para el Año Fiscal 2015 (FY15) define y establece dichas tarifas, las cuales están en consonancia con los años recientes y serán revisadas por los registradores para su aprobación.

      Este Plan Operativo y Presupuesto para FY15 tendrá un impacto positivo ya que proporciona un marco adecuado mediante el cual la ICANN será administrada y operada. Asimismo, proporciona la base para que la organización sea responsable de manera transparente. Esto tendrá un impacto fiscal en la ICANN y la comunidad de la manera prevista. Esto debería tener un impacto positivo en la seguridad, la estabilidad y la flexibilidad del sistema de nombres de dominio (DNS) respecto de cualquier financiamiento dedicado a dichos aspectos del DNS.

    5. Versión preliminar final del Plan estratégico de cinco años de la ICANN (FY16-FY20)

      Punto eliminado del orden del día.

    6. Reconocimiento de la declaración de la Segunda Cumbre de At-Large

      Sébastien Bachollet presentó el tema del orden del día y brindó una breve descripción general de la Segunda Cumbre de At-Large (ATLAS II) celebrada en Londres en junio de 2014, la presentación de la declaración final de ATLAS II a la Junta Directiva y las ediciones propuestas a la resolución que reconocen dichos esfuerzos. La Junta Directiva consideró las posibles revisiones al texto de la resolución. Mike Silber comentó que él no se sentía cómodo con la redacción de las resoluciones durante las reuniones pero que desea seguir con el debate para determinar si la Junta Directiva puede alcanzar un consenso respecto de la resolución. Mike también destacó que, dado que el ALAC aun debe indicar qué parte de la declaración de ATLAS II constituye asesoramiento, es prematuro para que la Junta Directiva analice seguir el asesoramiento del ALAC cuando aún no se ha presentado. Steve Crocker estuvo de acuerdo con Mike y destacó que la resolución debería reflejar que la Junta Directiva desea reunirse con el ALAC para analizar la declaración.

      Wolfgang Kleinwächter expresó su opinión de que toda la ICANN necesita un sólido movimiento de At-Large y el Comité Asesor de At-Large. En consonancia con eso, Wolfgang recomendó que la Junta Directiva continúe colaborando con el ALAC y avance en este proceso al próximo nivel, aunque los próximos pasos aún no están bien definidos. Por ejemplo, los próximos pasos pueden incluir otra cumbre o cumbres regionales incorporadas en las reuniones públicas de la ICANN. La cumbre en ICANN 50 no debe ser el fin de la historia. Wolfgang preguntó si debe existir una oportunidad para la recepción de comentarios públicos sobre la declaración.

      Sébastien comentó que la Junta Directiva debe hacer más que simplemente agradecer al ALAC por su trabajo; en cambio, la Junta Directiva debe indicar que seguirá en contacto con el ALAC respecto de los aportes en la declaración y la consideración de planes para cumbres celebradas regularmente. El Presidente destacó la importancia de la recepción del asesoramiento del ALAC como una estructura para la participación entre la Junta Directiva y el ALAC.

      Chris Disspain destacó que, como él lo entendió, el ALAC ahora tomará la declaración de ATLAS II y determinará qué se presentará a la Junta Directiva como asesoramiento u otra comunicación. Chris también destacó que, en principio, no está en contra de la idea de celebrar la cumbre en forma regular, pero preguntó si era adecuado realizar una indicación al respecto dado que no se ha debatido sobre el tema.

      Rinalia sugirió que la Junta Directiva debe indicar que desea participar con el ALAC o la comunidad de At-Large en Los Ángeles respecto del asesoramiento brindado. Chris aclaró que la palabra "asesoramiento" tiene un significado particular según los Estatutos y que la Junta Directiva no recibe asesoramiento de la comunidad de At-Large; en cambio, recibe asesoramiento del ALAC.

      Olga Madruga Forti respaldó el mensaje de Rinalia.

      Chris destacó que hubo desacuerdo entre los miembros de la Junta Directiva respecto de si la Junta Directiva estudiará posibles planes para que la cumbre de At-Large sea un evento regular. Mike comentó que la declaración de ATLAS II no hace referencia a la existencia continua de la cumbre y preguntó por qué era el lenguaje de la resolución. Bill destacó que la Junta Directiva no ha analizado aún si desea estudiar posibles planes para que las cumbres de At-Large sean eventos regulares y recomendó la postergación del debate de esta resolución hasta la reunión de la Junta Directiva en Los Ángeles, momento en el cual la Junta Directiva puede llevar a cabo el debate y aprobar la resolución de una forma u otra.

      El Presidente explicó que esta resolución tiene el fin de ser un agradecimiento al ALAC por su trabajo y acordó que incluir lenguaje que sugiera que la cumbre puede ser un evento regular es demasiado y la conversación puede continuar respecto a este tema incluso si no se refleja en la resolución. Resulta importante centrarse en el sentido de agradecimiento que la Junta Directiva está intentando reflejar.

      Steve Crocker presentó la resolución propuesta, la cual fue secundada por George Sadowsky.

      El Presidente llamó a votación y la Junta directiva tomó la siguiente medida:

      Visto y considerando que, la Segunda Cumbre de At-Large (ATLAS II) se celebró en la reunión n.° 50 de la ICANN en Londres, Reino Unido, en junio de 2014.

      Visto y considerando que, ATLAS II se ha basado en la primera cumbre organizada en marzo de 2009 en la reunión n.° 34 de la ICANN en México.

      Visto y considerando que, la Junta Directiva ha recibido la declaración final de ATLAS II (https://community.icann.org/download/attachments/48338039/ATLAS-II-Declaration-with-appendix-RC9.pdf?version=1&modificationDate=1407420726000&api=v2 [PDF, 201 KB]).

      Visto y considerando que, la comunidad de At-Large sigue el espíritu de participación y entusiasmo de la cumbre mediante diversas actividades de implementación posteriores a ATLAS II.

      Resuélvase (2014.09.09.08), la Junta Directiva reconoce la declaración final de ATLAS II y extiende sus felicitaciones por la exitosa cumbre celebrada durante ICANN 50 en Londres.

      Resuélvase (2014.09.09.09), la Junta Directiva afirma la importancia de la cumbre ATLAS II y sus resultados como aportes valiosos de la comunidad At-Large de usuarios individuales de Internet hacia el fortalecimiento de la ICANN.

      Resuélvase (2014.09.09.10), la Junta Directiva expresa su agradecimiento por el esfuerzo increíble que realizó la comunidad de At-Large en la realización de la cumbre de At-Large, la declaración final de ATLAS II y las actividades de implementación posteriores a ATLAS II.

      Resuélvase (2014.09.09.11), la Junta Directiva desea seguir en contacto con el ALAC respecto de los aportes proporcionados a la Junta Directiva resultantes de la declaración final de ATLAS II.s

      Once miembros de la Junta Directiva votaron a favor de las resoluciones 2014.09.09.08, 2014.09.09.09, 2014.09.09.10 y 2014.09.09.11. Fadi Chehadé, Wolfgang Kleinwächter y Sébastien Bachollet se abstuvieron. Ray Plzak y Bruce Tonkin no estuvieron disponibles para votar sobre las resoluciones. Las Resoluciones se aprobaron.

      Sebastien destacó que su abstención se basa en su preferencia de que la resolución incluya lenguaje que haga referencia al "estudio de posible planes para que la cumbre de At-Large sea un evento regular". La abstención de Wolfgang se basó en su opinión de que la idea de hacer que la cumbre sea un evento regular fue en el espíritu de la declaración de ATLAS II y debe incluirse referencia a ello en la resolución. Fadi también se abstuvo por los mismos motivos que expresó Wolfgang.

      Fundamentos de las resoluciones 2014.09.09.08 y 2014.09.09.11

      La Segunda Cumbre de At-Large (ATLAS II), que fue posible gracias a que la Junta Directiva aprobó un presupuesto especial para el evento, dio como resultado la elaboración de la declaración de ATLAS II. Esta declaración fue enviada a Steve Crocker por Olivier Crépin-Leblond el 7 de agosto de 2014.

      Este documento es el resultado del trabajo de aproximadamente 150 estructuras At-Large de 70 países que se reunieron presencialmente en Londres en junio de 2014.

      La declaración incluye el trabajo de los cinco grupos de trabajo temáticos de ATLAS II:

      • Grupo temático 1 (TG1): el futuro de los modelos de múltiples partes interesadas
      • Grupo temático 2 (TG2): la globalización de la ICANN
      • Grupo temático 3 (TG3): Internet global: la perspectiva del usuario
      • Grupo temático 4 (TG4): transparencia y responsabilidad de la ICANN
      • Grupo temático 5 (TG5): participación de la comunidad At-Large en la ICANN

      Contiene 43 recomendaciones a la Junta Directiva de la ICANN, a la ICANN y al ALAC, a las que se hace referencia como R-1 a R-43. También contiene 10 observaciones para la comunidad de Internet en general, a las que se hace referencia como O-1 a O-10.

      En la actualidad, la comunidad de At-Large está comenzando a trabajar en la implementación de las recomendaciones y observaciones a través de un grupo de tareas especial.

      El ALAC desea comentarios sobre la declaración de la comunidad de la ICANN en general.

      Esta medida forma parte de las funciones administrativas y organizacionales que no requieren de comentario público.

    7. Otros temas a tratar

      Ram Mohan planteó la cuestión de modificar los procedimientos de los procesos del Panel de Evaluación de Servicios de Registro (RSEP) y del Panel de Evaluación Técnica de Servicios de Registro (RSTEP). Como contexto, Ram explicó que varias cuestiones pueden impulsar un RSEP, incluido un cambio en el lenguaje realizado por un registro, y si se requiere más análisis, entonces la solicitud de traslada a un RSTEP, que luego requiere la aprobación de la Junta Directiva dentro del plazo definido de 30 días. Ram comentó que este proceso podía manejarse cuando cada ronda de nuevos gTLD implicaba menos de diez TLD; sin embargo, la ronda de 1300 nuevos TLD del año 2012 hará que los procesos de RSEP/RSTEP sean imposibles de manejar según las pautas procesales actuales. En función de esto, Ram solicitó que la Junta Directiva solicite al personal que revise y analice el proceso existente de RSEP/RSTEP, incluida la participación de la Junta Directiva en dicho proceso, y proporcione recomendaciones sobre cómo optimizar el proceso. A modo de aclaración, Ram explicó que él trabaja para un registro, que ha presentado varios RSEP y RSTEP ante la ICANN, por lo que está muy familiarizado con los detalles de este proceso. Además, Ram también formó parte de la GNSO cuando se desarrolló y adoptó el proceso de RSEP/RSTEP como un requisito de política consensuado.

      El Presidente comentó que cuando se desarrolló el proceso de RSEP/RSTEP, existió precaución considerable respecto de todo lo relativo a la seguridad y la estabilidad y, con el objeto de extremar las precauciones, se le encargó a la Junta Directiva que supervisara dichos cambios solicitados. El Presidente estuvo de acuerdo con Ram y sugirió que el personal proporcione un procedimiento recomendado que incluya un nivel suficiente de profundidad técnica y garantía de independencia de manera que cada solicitud implique una verdadera investigación en cuanto a las cuestiones de seguridad y estabilidad que puedan ser pertinentes.

      Jonne Soininen planteó la cuestión del rol que la GNSO debe tener en la modificación del proceso de RSEP/RSTEP. El Asesor Jurídico y Secretario explicó que el procedimiento fue desarrollado inicialmente porque era difícil que los registros agregaran nuevos servicios de registro, lo que creaba conflicto entre los registros, la GNSO, y la Junta Directiva y el personal de la ICANN. El proceso actual ha sido muy útil hasta la fecha, pero el Asesor Jurídico acuerda que con más de mil nuevos gTLD, será difícil administrar los cambios solicitados de la misma manera. Comentó que los cambios al procedimiento deben realizarse con precaución y con consideración de cómo funciona el proceso y si se requiere trabajo adicional de la GNSO antes de la implementación de algún cambio.

      Akram Atallah indicó que el personal preparará recomendaciones respecto del proceso de RSEP/RSTEP para su revisión durante ICANN 51 en Los Ángeles.

      No se adoptó ninguna resolución.

Publicado el 17 de octubre de 2014

minutes-09sep14-es.pdf  [154 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."