Skip to main content
Resources

Resoluciones aprobadas por la Junta Directiva | Reunión 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/groups/board/documents/resolutions-27jun13-en.htm

 

  1. Agenda convenida
    1. Aprobación de las minutas de la Junta Directiva
    2. Nombramiento de Ben Butler para integrar el SSAC
    3. Aprobación del acuerdo contractual con AROS
  2. Agenda principal
    1. Actualización sobre la implementación del Proceso de avance acelerado de IDN ccTLD
    2. Aprobación del RAA 2013
  3. Sesión ejecutiva
    1. Resolución Confidencial

 

  1. Agenda convenida:

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

      Queda resuelto (2013.06.27.01), por la presente la Junta Directiva aprueba las minutas de la reunión ordinaria de la Junta Directiva de la ICANN del día 18 de mayo de 2013

    2. Nombramiento de Ben Butler para integrar el SSAC

      Visto y considerando que, ocasionalmente, el Comité Asesor de Seguridad y Estabilidad (SSAC) analiza su membresía y efectúa el reemplazo de sus miembros.

      Que, el Comité de Membresía del SSAC, en representación del SSAC, solicita que la Junta Directiva designe a Ben Butler para integrar dicho comité.

      Queda resuelto (2013.06.27.02), la Junta Directiva asigna a Ben Butler como integrante del SSAC.

      Fundamentos de la Resolución 2013.06.27.02

      El SSAC es un grupo diverso de personas cuyos conocimientos sobre temas específicos permiten que dicho comité cumpla sus estatutos y ejecute su misión. Desde su creación, el SSAC ha invitado a personas con conocimientos profundos y experiencia en áreas técnicas y de seguridad que son críticas para la seguridad y estabilidad del sistema de nombres de dominio de Internet.

      Las operaciones continuas del SSAC como un organismo competente dependen del aporte de expertos talentosos en el tema que hayan aceptado contribuir voluntariamente con su tiempo y energía para ejecutar la misión de dicho organismo. Ben Butler, aporta valiosos conocimientos al SSAC. Específicamente, aporta su experiencia como Director de abuso de redes en GoDaddy, un registro de gran envergadura. Además, el señor Butler aporta experiencia como proveedor de alojamiento y contactos con otros proveedores de alojamiento, ambas adiciones necesarias para el SSAC. Por último, aporta su gran conocimiento sobre cuestiones de abuso en el DNS.

    3. Aprobación del acuerdo contractual con AROS

      Visto y considerando que, la ICANN y Street Solutions han negociado de buena fe los términos de una declaración de trabajo propuesta para el desarrollo del Sistema Automatizado para la Incorporación de Registradores (AROS);

      Que, la Junta Directiva ha revisado los términos de la Declaración de trabajo propuesta para la ICANN;

      Que, se requiere la aprobación de comprometer fondos de la ICANN por el importe de US$ 650.450 (seiscientos cincuenta mil cuatrocientos cincuenta dólares estadounidenses);

      Que, la ejecución del acuerdo permite el desarrollo de esta herramienta para apoyar la acreditación de registros y registradores;

      Queda resuelto (2013.06.27.03), la Junta Directiva autoriza al Presidente y CEO a celebrar el acuerdo propuesto con Street Solutions.

      Queda resuelto (2013.06.27.04), se aprueba la solicitud de aprobar el contrato con Street Soluciones para el desarrollo del Sistema Automatizado para la Incorporación de Registradores (AROS).

      Fundamentos de las resoluciones 2013.06.27.03 — 2013.06.27.04

      La Política de desembolso de la ICANN limita las facultades de los directivos para celebrar contratos o desembolsos superiores a US$ 500.000,00 (quinientos mil dólares estadounidenses) por obligación. Por lo tanto, la ICANN actúa en cumplimiento con dicha política al procurar la aprobación de la Junta Directiva para celebrar obligaciones contractuales que superen el monto de US$500.000 (quinientos mil dólares estadounidenses) por obligación. La ICANN identificó un proveedor para desarrollar el sistema AROS y el contrato con el proveedor se estima en US$ 650.450 (seiscientos cincuenta mil cuatrocientos cincuenta dólares estadounidenses), incluyendo la licencia.

      La solución propuesta es un Sistema Automatizado para la Incorporación de Registradores (AROS) para los registradores acreditados por la ICANN. El sistema descripto en este documento está destinado a ofrecer a los registradores una interfaz de usuario coherente para la gestión de la información sobre su registrador y al solicitar la acreditación de (principalmente) los Registros genéricos de dominio de nivel superior, un espacio de trabajo en el cual los registros pueden gestionar las solicitudes de acreditación de los registradores y una interfaz de administración que permite a un administrador designado por la ICANN gestionar el sistema AROS.

      Los requisitos para el sistema han sido elaborados por el Grupo de trabajo (WG) compuesto por representantes de los grupos de partes interesadas de registros y registradores, el personal de la ICANN y un consultor externo especializado en requisitos. Los representantes de los grupos de registros y registradores (tres cada uno) son voluntarios identificados por los respectivos presidentes del grupo de partes interesadas. Además del equipo de trabajo descripto, el personal ha realizado encuestas con los registros y registradores en dos ocasiones para validar los requisitos.

      La aprobación de la Junta Directiva para efectivar esta obligación contractual tendrá un impacto positivo sobre la comunidad, ya que permitirá contrataciones entre registros y registradores que sean más oportunas y eficientes. Al hacer esto, la ICANN está propiciando un entorno más competitivo y eficiente. Habrá impactos fiscales sobre la ICANN, aunque todos esos impactos han sido anticipados en el presupuesto aprobado para el año fiscal 2013 y el presupuesto preliminar para el año fiscal 2014. No habrá ningún problema de seguridad, estabilidad o flexibilidad en relación con el sistema de nombres de dominio.

  2. Agenda principal:

    1. Actualización sobre la implementación del Proceso de avance acelerado de IDN ccTLD

      Visto y considerando que, el día 30 de octubre de 2009 la Junta Directiva de la ICANN aprobó el Plan de implementación de avance acelerado (http://www.icann.org/en/minutes/resolutions-30oct09-en.htm # 2)

      Que, según el Proceso de avance acelerado de IDN ccTLD (Dominios de Nivel Superior con Código de País de Nombres de Dominio Internacionalizados), un panel independiente lleva a cabo tanto la evaluación técnica como la evaluación de similitud en las cadenas de caracteres (Evaluación de estabilidad del DNS);

      Que, la ccNSO desarrolló y el Consejo de la ccNSO aprobó las recomendaciones para la Política de selección de cadenas de caracteres de IDN ccTLD para incluir un proceso de dos paneles para la evaluación de similitud en las cadenas de caracteres (http://ccnso.icann.org/node/38787) [PDF, 119 KB];

      Que, la ICANN ha recibido múltiples aportes y asesoramiento por parte de la comunidad pidiendo mayor transparencia y coherencia para la evaluación de similitud en las cadenas de caracteres, incluido el asesoramiento del Comité Asesor Gubernamental;

      Que, el presidente de la ccNSO (Organización de Apoyo para Nombres de Dominio con Código de País) envió una solicitud a la Junta Directiva de la ICANN para implementar un proceso de dos paneles para la revisión de similitud en las cadenas de caracteres, dentro del Proceso de avance acelerado de IDN ccTLD;

      Queda resuelto (2013.06.27.05), la Junta Directiva de la ICANN aprueba la enmienda al Plan de implementación de avance acelerado, a fin de instrumentar el proceso de dos paneles de revisión de similitud en las cadenas de caracteres, dentro del Proceso de avance acelerado de IDN ccTLD. Se indica al Presidente y Director ejecutivo (CEO) incorporar la enmienda al Plan de implementación de avance acelerado previamente aprobado por la Junta Directiva de la ICANN, el día 30 de octubre de 2009 (con enmienda del 8 de diciembre de 2011), e implementar la enmienda tan pronto como sea posible.

      Queda resuelto (2013.06.27.06), la Junta Directiva de la ICANN aprueba la enmienda al Plan de Implementación de avance acelerado, a fin de permitir que todas las solicitudes pendientes de cadenas de caracteres de IDN ccTLD bajo el Proceso de avance acelerado tengan la opción de solicitar la evaluación por parte del nuevo Panel de revisión del proceso de similitud extendido (EPSRP) una vez que el mismo sea conformado.

      Fundamentos de las resoluciones 2013.06.27.05 — 2013.06.27.06

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

      El PDP (Proceso de Desarrollo de Políticas) de la ccNSO sobre los IDN ccTLD está llegando a su conclusión. Una de las propuestas de la recomendación de política esperada es la introducción de un mecanismo de dos paneles para la revisión de similitud confusa en cadenas de caracteres de IDN ccTLD solicitadas. Uno de los propósitos de la introducción del Proceso de avance acelerado de IDN ccTLD es experimentar con una metodología para la selección de las cadenas de caracteres de IDN ccTLD e informar, en consecuencia, al Proceso de Desarrollo de Políticas de la ccNSO mientras se responde a la demanda a corto plazo para la introducción de IDN ccTLDs. La introducción del mecanismo de dos paneles, como un banco de pruebas en el Proceso de avance acelerado permite probar y perfeccionar, de ser necesario, el mecanismo de dos paneles y la metodología propuesta. Al modificar el Proceso de avance acelerado de esta manera también se espera lograr el objetivo de satisfacer las demandas a corto plazo para la introducción continua de IDN ccTLDs. Por último, la comunidad siempre ha estado pidiendo una modificación a la revisión de similitud en las cadenas de caracteres dentro del Proceso de avance acelerado, y siguiendo las directrices de la ccNSO se mejorará la responsabilidad de la ICANN a este respecto.

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

      La modificación propuesta al Plan de implementación de avance acelerado introduce un segundo Panel experto independiente para la revisión del Proceso de avance acelerado de IDN ccTLD en relación a la similitud confusa en las cadenas de caracteres. Esto se suma al panel de revisión de similitud en las cadenas de caracteres, ya existente. La propuesta también pide que todas las solicitudes pendientes de cadenas de caracteres de IDN ccTLD del Proceso de avance acelerado ―incluidas aquellas que previamente han fracasado en la revisión de similitud de cadenas―, tengan la opción de pedir que su solicitud sea revisada por el EPSRP. Esto permitirá a todas las solicitudes pendientes y futuras atravesar por evaluaciones consistentes, aunque no tiene impacto alguno sobre aquellas solicitudes que ya han pasado el Proceso de avance acelerado en forma satisfactoria. En cualquier caso, aquellos que han pasado el proceso con éxito nunca hubiesen necesitado utilizar el EPSRP.

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

      El tema de similitud en las cadenas de caracteres fue el centro de los dos revisiones anuales del Proceso de avance acelerado de IDN ccTLD realizadas hasta la fecha. Se ha discutido en las sesiones públicas celebradas durante las reuniones de la ccNSO desde la reunión que la ICANN celebró en San Francisco, en marzo de 2011.

      En el mes de abril de 2013, el Consejo de la ccNSO aprobó el Informe final sobre el Proceso de desarrollo de políticas de IDN con código de país (http://ccnso.icann.org/workinggroups/idn-ccpdp-final-29mar13-en.pdf [PDF, 376 KB]).

      Este informe incluye las propuestas del Grupo de trabajo 1 del Proceso de Desarrollo de Políticas de Códigos de País para Nombres de Dominio Internacionalizados (IDN ccPDP WG 1), las cuales fueron sujetas a amplias consultas públicas. El IDN ccPDP WG 1 se enfocó en el desarrollo de recomendaciones preliminares de política para la selección de IDN ccTLDs asociados a los territorios mencionados en la lista ISO 3166-1, que con el tiempo debería reemplazar a la metodología del Proceso de avance acelerado de IDN ccTLD. Las propuestas incluyen la introducción de dos paneles para la validación de similitud confusa en las cadenas de caracteres, en la cual, el segundo panel ofrece una evaluación final y definitiva respecto a la cadena de caracteres, sobre la base de una investigación científica. Los comentarios públicos recibidos durante las dos revisiones anuales, respaldaron la introducción del segundo panel. Además, el Comité Asesor Gubernamental recomendó —entre otros—, a la Junta directiva de la ICANN:

      • Reconsiderar los IDNs recientemente denegados en virtud del Proceso de avance acelerado, en particular aquellos propuestos por autoridades públicas o nacionales.
      • Crear un mecanismo de apelación que permita cuestionar las decisiones respecto a la capacidad de confusión de los IDN ccTLDs propuestos, sin perjuicio del punto anterior, y por razones de responsabilidad y transparencia.

      Mientras que el EPSRP no constituye un proceso de apelación, el mismo servirá para ofrecer un tipo de evaluación diferente de las cadenas de caracteres, en forma separada al panel de similitud de cadenas de caracteres, ya existente. La introducción del EPSRP también ofrecerá un camino para la revisión de aquellos solicitantes de IDN ccTLD en virtud del Proceso de avance acelerado, que no hayan pasado satisfactoriamente la evaluación del panel de revisión de similitud de cadenas de caracteres. De este modo, esta acción abordará las recomendaciones desarrolladas por la comunidad, así como el asesoramiento del GAC.

      ¿Existen impactos fiscales o ramificaciones sobre la ICANN?

      Esta enmienda tendrá repercusiones presupuestarias en cuanto la ICANN tendrá que conformar un segundo panel con un grupo de expertos para realizar una segunda y última validación de la cadena de caracteres de IDN ccTLD solicitada. No se prevé ningún impacto sobre la seguridad o la estabilidad del DNS como resultado de esta enmienda.

    2. Aprobación del RAA 2013

      Visto y considerando que, desde 2011 la ICANN y un Grupo de partes interesadas de registradores, el Equipo de negociación de registradores, han estado negociando modificaciones al Acuerdo de Acreditación de Registradores (RAA) 2009 de la ICANN.

      Que, las negociaciones han dado lugar al RAA 2013 propuesto, el cual aborda todas las 12 recomendaciones formuladas en 2009 a partir de las evaluaciones del cumplimiento de la ley y otras revisiones.

      Que, la ICANN se compromete a tener el RAA 2013 RAA vigente antes de la delegación de gTLDs en virtud del Programa de nuevos gTLD.

      Que, la ICANN y los registradores requieren de un tiempo de transición suficiente hacia los términos del RAA 2013, y la aprobación de la Junta Directiva ofrecerá la garantía necesaria de los términos aplicables.

      Queda resuelto (2013.06.27.07), la Junta Directiva aprueba la forma del RAA 2013.

      Queda resuelto (2013.06.27.08), se indica al Presidente y CEO tomar todas las medidas necesarias para proceder a la ejecución del RAA 2013, con todos los registradores y solicitantes de registradores que sean elegibles.

      Queda resuelto (2013.06.27.09), la Junta Directiva agradece al Grupo de partes interesadas de registradores y, en particular, a los miembros del Equipo de negociación de registradores por su dedicación, tiempo y esfuerzo en el proceso de negociación.

      Fundamentos de las resoluciones 2013.06.27.07 — 2013.06.27.09

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

      Las negociaciones de larga data sobre el RAA 2013 han llegado exitosamente a su fin y se ha presentado un RAA 2013 propuesto a la Junta Directiva. Es importante que el RAA 2013 sea aprobado en este momento, ya que la Junta Directiva ha aceptado el asesoramiento del GAC suministrado a través del Comunicado de Beijing, recomendando que "el Acuerdo de Acreditación de Registradores 2013 debe finalizarse antes de proceder con la aprobación de cualquier nuevo contrato de gTLD." La aprobación del RAA 2013 ahora permite a la Junta Directiva cumplir con dicha recomendación. En forma adicional, la ICANN ha expuesto en múltiples ocasiones a la comunidad que el RAA 2013 estará vigente antes de la delegación de los nuevos gTLDs. El aprobar ahora el RAA 2013 también brinda a la ICANN y a los registradores la certeza de los nuevos términos que serán aplicables y permite, tanto a la ICANN como a los registradores, avanzar en la labor de implementación de las obligaciones incorporadas. Por último, luego de las negociaciones la comunidad de la ICANN ha estado esperando largamente el nuevo RAA, desde finales de 2011.

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

      El RAA 2013 contiene disposiciones dirigidas a proteger a los registratarios mediante un marco contractual más actualizado. El RAA 2013 refleja concesiones reñidas en muchas de las principales cuestiones planteadas durante las negociaciones, así como las cuestiones planteadas en los comentarios públicos. El RAA 2013 representa una mejora significativa respecto a la versión actual 2009, y aumenta significativamente los requisitos de desempeño para cada registrador acreditado por la ICANN, incorporando de este modo increíbles mejoras dramáticas para el ecosistema de nombres de dominio.

      Los aspectos más destacados del RAA 2013 propuesto incluyen:

      • Las 12 recomendaciones de cumplimiento de la ley que sirvieron de impulso para estas negociaciones están abordadas en esta propuesta preliminar. El cuadro de resumen de cumplimiento de la ley adjunto identifica la sección o especificación del RAA 2013 que abordó cada recomendación. Algunos de los aspectos más destacados incluyen la creación de un punto de contacto para casos de abuso en cada registrador, requisitos de verificación y validación de Whois a nivel del registratario y titular de cuenta, una redacción más fuerte sobre las obligaciones de los registradores para los revendedores y nuevas obligaciones de retención de datos.

      • Herramientas de cumplimiento mejoradas, incluyendo herramientas de suspensión y rescisión, la clarificación de los derechos de auditoría y el acceso a la información para facilitar las investigaciones en curso, y los requisitos de certificación anual.

      • Un documento de Derechos y Responsabilidades del Registratario que establece, mediante una redacción clara y sencilla, los derechos y responsabilidades dispuestos en el RAA 2013, tal como los tipos de información que los registratarios tendrán a su disponibilidad respecto a los términos y condiciones de las registraciones, las tarifas y los procesos de servicio al cliente. El documento también enfatiza el rol del registratario en la provisión de información de contacto precisa y en las responsabilidades de mantener las registraciones de nombres de dominio. Estos derechos y responsabilidades enumeradas no son exhaustivas de todos los derechos y responsabilidades del registratario establecidos en las políticas de consenso, sin embargo, este documento está estrechamente ligado a los términos del RAA 2013.

      • Responsabilidad del registrador para el cumplimiento de revendedores, con todos los términos pertinentes del RAA.

      • Consolidación con el Acuerdo de registro para nuevos gTLD. Cuando corresponda, la ICANN y el Registrador NT acordaron reflejar el lenguaje del Acuerdo de registro, para permitir que los contratos estén mejor alineados. Se prevé que el Acuerdo de registro para nuevos gTLD y el RAA 2013 se complementen entre sí a medida que los registros y registradores avanzan hacia acuerdos que reflejen mejor la transformación del mercado.

      • Requisitos provisionales para los servicios de privacidad y proxy. La ICANN y el Registrador NT han acordado protecciones provisionales que entrarán en vigencia para los servicios de privacidad y proxy ofrecidos a través de los registradores. Estas medidas de protección provisionales, requerirán que la información esté disponible respecto a elementos como los procesos de servicio al cliente y cuando un proveedor confiará información sobre el usuario subyacente correspondiente a la registración del nombre de dominio. Si bien estas medidas no abarcan las protecciones que algunos han solicitado poner en vigencia para los proveedores de servicios de privacidad y proxy, estas protecciones provisionales proporcionarán un mercado más responsable hasta que se desarrolle un programa de acreditación formal.

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

      Las negociaciones del RAA fueron iniciadas debido a las propuestas planteadas por la comunidad del orden público. A lo largo de las negociaciones, la ICANN y el Registrador NT consultaron con los representantes del orden público y con el Comité Asesor Gubernamental (GAC) sobre cómo se habían implementado las 12 recomendaciones de cumplimiento de la ley. Un resumen de cómo las recomendaciones de cumplimiento de la ley fueron integradas al RAA 2013 está disponible en http://www.icann.org/en/news/public-comment/proposed-raa-22apr13-en.htm. El GAC expresó su agradecimiento por las mejoras al RAA que incorporan las Recomendaciones 2009 del GAC para el cumplimiento de la ley y también señaló que está satisfecho con el progreso en la prestación de la verificación y la mejora de la precisión de los datos del registratario, y respalda los esfuerzos continuos para identificar mecanismos preventivos que ayuden a disuadir la actividad ilícita penal o de otro tipo.

      En forma adicional a las consultas con los agentes de orden público y el GAC, la ICANN ha realizado sesiones públicas e interactivas sobre las negociaciones del RAA en las reuniones celebradas en Costa Rica, Praga, Toronto y Beijing. A petición, los representantes del personal de la ICANN también ofrecieron presentaciones ante el Consejo de la GNSO, grupos de trabajo de At-Large, diversas unidades constitutivas y grupos de partes interesadas ​​en la GNSO y representantes del orden público. Además, la ICANN ha publicado tres versiones del RAA públicamente, sobre las cuales se solicitaron comentarios públicos en los meses de marzo y abril de 2013. El día 22 de abril 2013 se cerró el período de comentarios públicos sobre la propuesta final del RAA 2013, que incluyó todos los acuerdos entre la ICANN y Registrador NT. Diecinueve comentarios participaron el 22 de abril de 2013 en el foro de comentarios públicos, incluyendo a los representantes del Grupo de partes interesadas de registradores, el ALAC, el Grupo de propiedad intelectual y la unidad constitutiva empresarial. En apoyo a la publicación de la propuesta final del RAA 2013, en el mes de mayo de 2013, la ICANN celebró un seminario web interactivo al que asistieron más de 100 participantes conectados telefónicamente y a través de Adobe Connect.

      Luego de la revisión de los comentarios públicos, la ICANN también consultó nuevamente al Equipo de negociación de registradores para confirmar el apoyo de los registradores a los cambios identificados.

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

      A lo largo de las negociaciones, se han planteado preocupaciones sobre diversos temas dentro del RAA propuesto, las cuales fueron tenidas en cuenta en las negociaciones. Por ejemplo, existía una importante preocupación en algunas partes de la comunidad en relación con el desarrollo excesivo de los estándares de servicio de privacidad y proxy, fuera del proceso de desarrollo de políticas. Como resultado, la ICANN y el Registrador NT identificaron una solución que establece normas mínimas para que los registradores impongan sobre los servicios de privacidad y proxy que se ofrecen al momento de la registración, mientras que establece un camino para la participación de la comunidad en el desarrollo de un Programa de Acreditación de Proxy/Privacidad. Sin embargo, esto no alivió todas las preocupaciones en esta área ni tampoco todas las inquietudes podían ser tratadas de esta manera.

      Con esta última publicación del RAA 2013 propuesto, las principales áreas de preocupación planteadas fueron las siguientes:

      • Respecto a la precisión de Whois, la IPC (Unidad Constitutiva de Propiedad Intelectual), la BC (Unidad Constitutiva Empresarial) y otros comentadores respaldaron el uso de la verificación previa a la resolución, en contraposición a permitir una ventana de 15 días posteriores a la resolución dentro de la cual podría producirse la verificación. Esta solicitud de verificación previa a la resolución ha sido anteriormente planteada en las negociaciones, y debido a la posibilidad de grandes cambios en el proceso de registración de nombres de dominio, así como a los trabajos en curso para crear un nuevo método de tratar con los datos de registración de gTLD, se determinó —y se explicó a la comunidad— que la verificación previa a la resolución no era viable para ser introducida en este momento, sin realizar trabajos y desarrollos adicionales por parte de la comunidad.

      • Del mismo modo hubo solicitudes para verificar ambos la dirección de correo electrónico y el número de teléfono, pero los registradores y otras partes plantearon inquietudes de que el realizar una verificación telefónica no es siempre posible —y en algunos lugares del mundo es casi imposible—. Cambios adicionales en estas áreas también fueron diferidos a favor de la labor en curso sobre los datos de registración de gTLD.

      • Para las registraciones realizadas a través de proveedores de servicios de privacidad y proxy, varios comentadores pidieron (como lo habían estado pidiendo durante todo el proceso de desarrollo del RAA) la verificación de los datos del cliente subyacente. Como ya hemos explicado a la comunidad, se pondrá en marcha un próximo trabajo de políticas para un Programa de acreditación de privacidad y proxy, que será el espacio donde se desarrollarán este tipo de requisitos, ya que las líneas de aplicación estarán más claras en esa situación. Además, muchos en la comunidad se opusieron a la introducción de este tipo de exigencia en este momento. Del mismo modo, la comunidad no tiene consenso actual sobre el mecanismo para requisitos más explícitos de revelación y relevo de los datos subyacentes de los clientes; y aunque muchos han comentado que la ICANN debería poner ahora en vigencia ese tipo de requisitos, esa labor también ha sido postergada al trabajo de políticas sobre acreditación, basadas en la comunidad. Una preocupación común planteada recientemente en lo que respecta a las obligaciones de privacidad y proxy establecidas en el RAA 2013 fue que teníamos que ser más claros acerca del ámbito de aplicación de los revendedores y la ICANN ha asumido ese cambio en, el cual se refleja en el RAA 2013 aprobado por la Junta Directiva.

      • Algunos comentadores expresaron su preocupación acerca del nuevo documento de Derechos y responsabilidades del registratario, sugiriendo que no va lo suficientemente lejos en el reconocimiento de los derechos y responsabilidades de carácter más general. Debido al propósito específico de la especificación de los Derechos y responsabilidades del registratario —que es hacer un seguimiento de los términos del RAA 2013— hemos clarificado el título del documento. Si la comunidad quiere generar una declaración más amplia de los derechos y responsabilidades, nada dentro del RAA 2013 impediría esa labor.

      • Algunos comentadores señalaron su preocupación de que los procesos de enmienda establecidos eran demasiado onerosos para la ICANN en caso de que desease establecer una modificación sobre la objeción de los registradores. Sin embargo, la ICANN considera que el proceso de enmienda aprobado por la Junta Directiva y reflejado en el RAA 2013 constituye un equilibrio que reconoce el rol del desarrollo de políticas en el modelo de múltiples partes interesadas y que, aunque complejo, proporciona un poderoso mecanismo ante la eventualidad de necesitar invocarlo.

      • Mientras que, en general, los comentadores respaldaron el RAA 2013 y los avances que ofrece, muchos de esos mismos comentadores señalaron su insatisfacción con el proceso que condujo a la elaboración del RAA 2013. Muchos estaban insatisfechos de que las negociaciones fueron bilaterales, sin siquiera una oportunidad de observación por parte de la comunidad en las sesiones de negociación, y mucho menos la posibilidad de proponer un texto durante las negociaciones. Mientras que es demasiado tarde para modificar el proceso utilizado anteriormente, es importante recordar que el propio RAA no incluyó ninguna ruta a la negociación; el proceso a ser utilizado no estaba claro. Para ayudar a garantizar que la comunidad tenga una voz en futuras modificaciones del RAA, el RAA ahora incorpora requisitos específicos de comentarios públicos, cuando las enmiendas estén siendo estudiadas o cuando se hayan iniciado negociaciones.

      Aquí se incluye un resumen de algunas de las principales preocupaciones planteadas. Un listado completo y el análisis de los comentarios sobre la propuesta final del RAA (publicado en [insertar enlace]) también ha sido considerado como parte de la decisión sobre el RAA. Ese resumen y el análisis también identificaron áreas en las que el RAA 2013 refleja modificaciones en respuesta a los comentarios recibidos.

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

      La Junta Directiva examinó:

      • El RAA 2013 y las Especificaciones incorporadas
      • El resumen de los cambios entre el RAA 2013 y la versión del 22 de abril 2013
      • Aclaraciones finales al RAA luego de consultar a los registradores
      • Resumen y análisis de los comentarios públicos del 22 de abril de 2013.
      • Resumen y análisis de los comentarios públicos del mes de marzo de 2013
      • Resumen de recomendaciones para abordar el cumplimiento de la ley
      • El Comunicado de Beijing del GAC

      ¿Qué factores considera importantes la Junta Directiva?

      La Junta Directiva determinó muchos factores importantes para llegar a esta decisión. En primer lugar,  la intensa participación del Registrador NT y las declaraciones de apoyo realizadas por la comunidad de registradores para este RAA 2013. En segundo lugar, el hecho de que el RAA 2013 incorpora las 12 recomendaciones de cumplimiento de la ley del GAC, sirviendo de base para la apertura de las negociaciones, así como el apoyo del GAC a los resultados de las negociaciones constituye un factor importante en el apoyo al RAA 2013. Además, aunque existen áreas sobre las cuales la comunidad de la ICANN desearía ver cambios en el RAA 2013, las declaraciones de la comunidad son abrumadoramente a favor de los avances logrados en este nuevo RAA. El hecho de que existan caminos para continuar con la labor en las áreas principales que la comunidad ha identificado preocupantes —incluido el Grupo de trabajo de expertos sobre los datos de registración de gTLD y el trabajo hacia un Programa de acreditación de privacidad/Proxy—, permite el debate en la comunidad para continuar trabajando en algunas de las cuestiones más difíciles planteadas dentro de esta negociación y que no han sido resueltas al nivel que algunos miembros de la comunidad lo desean. Las mejoras en el RAA 2013 —incluyendo las herramientas de cumplimiento mejoradas, los avances en Whois, las obligaciones más claras de los revendedores—, son oportunas y deben estar vigentes en forma previa a la delegación de los nuevos gTLDs, de modo que todos los gTLDs introducidos a través del Programa de nuevos gTLD serán alcanzados por estos términos.

      Por último, la Junta Directiva consideró importante que el Grupo de partes interesadas de registradores apoye el RAA 2013.

      ¿Qué alternativas fueron consideradas por la Junta?

      Debido a la ruta que tomó el RAA 2013 para llegar a la Junta Directiva, la Junta no ha considerado otras alternativas distintas a la alternativa de retrasar la aprobación del acuerdo. Sin embargo, la Junta Directiva examinó las recomendaciones de la comunidad sobre los elementos que se deben agregar o quitar del RAA 2013, como alternativas.

      ¿Existen impactos positivos o negativos para la comunidad?

      Se espera que la introducción del RAA 2013 tenga efectos positivos, ya que los cambios que entrarán en vigencia con obligaciones incorporadas se espera que den lugar a la maduración del rol de los registradores dentro del DNS. El RAA 2013 brindará herramientas para la ICANN, los registradores y los registratarios que conllevarán a una comprensión más clara de las obligaciones, los derechos y el acceso a la información. El mayor riesgo para el desarrollo de los impactos negativos vendrá de la falta de entendimiento de las nuevas obligaciones, ya que registratarios y registradores por igual enfrentarán nuevos requisitos. Los esfuerzos educativos pueden ayudar a contrarrestar tales impactos negativos.

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

      Las nuevas obligaciones en virtud del RAA 2013 impondrán ramificaciones fiscales sobre los registradores, ya que tienen nuevas obligaciones operativas que cumplir bajo el marco del acuerdo, y necesitarán revisar los sistemas y procesos para cumplir con tales obligaciones. El RAA 2013 incluye un término transitorio para dar tiempo a la implementación. De igual modo, la ICANN tendrá que revisar sus tareas de cumplimiento contractual, las cuales podrían tener un impacto fiscal mínimo ya que el crecimiento del Equipo de cumplimiento contractual ya ha sido incluido en el presupuesto. La extensión educativa necesaria para ayudar a garantizar que tanto registradores como registratarios por igual entiendan estas nuevas obligaciones, también impondrán la necesidad de recursos fiscales por parte de la ICANN. Existe la posibilidad de que los aumentos en los costos operacionales resulten en un aumento de precios para los consumidores, pero no hay documentación disponible en este momento como para respaldar que esto ocurrirá.

      ¿Existe alguna cuestión de seguridad, estabilidad o flexibilidad en relación al DNS?

      El RAA 2013, que incluye requisitos técnicos tales como el apoyo de IDNs y DNSSEC (Extensiones de Seguridad para el Sistema de Nombres de Dominio), contribuirá al mantenimiento de la seguridad, estabilidad y flexibilidad del DNS.

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

  3. Sesión ejecutiva

    1. Resolución Confidencial

      [Resoluciones ocultas]

      Queda resuelto (2013.06.27.13), los elementos específicos de  esta resolución se mantendrán en absoluta confidencialidad por tratarse de una "acción relativa al personal o a cuestiones laborales", de conformidad con la Sección 5.2 del Artículo III de los Estatutos de la ICANN, y toda la resolución tendrá carácter confidencial conforme a esta misma disposición estatutaria, hasta que el Presidente y CEO determine que la parte no confidencial puede ser divulgada públicamente.

      Fundamento de las resoluciones 2013.06.27.10—  2013.06.27.13

      [Fundamentos ocultos]

resolutions-27jun13-es.pdf  [260 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."