Borrador de la Guía del solicitante, v4€¦ · Corporación para la Asignación de Números y...

31 de mayo de 2010

Borrador de la Guía del solicitante, v4 Módulo 1

Tenga en cuenta se trata sólo de una versión preliminar del debate. Los aspirantes no deben confiar en ninguno de los detalles propuestos del nuevo programa de gTLD, ya que éste continúa siendo objeto de más consultas y revisiones.

Se ha traducido este documento de la versión en inglés con el objeto de llegar a una mayor cantidad de público. Si bien la Corporación para la Asignación de Números y Nombres en Internet (ICANN) ha tomado las medidas necesarias para verificar la exactitud de la traducción, el inglés es el idioma de trabajo de ICANN y la versión original de este documento en inglés constituye el único texto oficial y autorizado.

Borrador de la Guía del postulante, v3 - v4 – Sólo para discusión 1-1

Módulo 1 Introducción al proceso de solicitud de gTLD

Este módulo ofrece a los postulantes una descripción general del proceso de solicitud de un dominio genérico de primer nivel, e incluye instrucciones sobre cómo completar y enviar una solicitud, los comprobantes que el postulante debe enviar junto con la solicitud, las tarifas, y cuándo y cómo enviarlas.

En este módulo, también se describen las condiciones de los distintos tipos de solicitudes y las etapas de la duración de las solicitudes.

Para obtener más información acerca de los orígenes, la historia y los detalles de los antecedentes del desarrollo de la política relativos al programa de nuevos gTLD, visite http://gnso.icann.org/issues/new-gtlds/.

Se incluye un glosario de términos importantes al final de este borrador de la Guía del postulante.

Los aspirantes deben leer y familiarizarse con el contenido de este módulo completo, así como con los restantes, antes de iniciar el proceso de solicitud, a fin de comprender lo que se espera de ellos y lo que pueden esperar en cada una de las etapas del proceso de evaluación de solicitudes.

Para obtener un conjunto completo de los comprobantes y más información acerca de los orígenes, la historia y los detalles de los antecedentes del desarrollo de la política relativos al programa de nuevos gTLD, visite http://gnso.icann.org/issues/new-gtlds/.

1.1 Duración y cronograma de la solicitud En esta sección, se describen las etapas que atraviesa una solicitud una vez presentada. Algunas etapas serán comunes a todas las solicitudes enviadas; mientras que otras sólo se darán en ciertas circunstancias. Los postulantes deben conocer las etapas y los pasos que lleva el procesamiento de las solicitudes recibidas.

1.1.1 Fechas de envío de solicitudes


Borrador de la Guía del postulante v4 – Sólo para discusión 1-2

El período de presentación de solicitudes se inicia a las [hora] UTC [fecha].

El período de presentación de solicitudes cierra a las [hora] UTC [fecha].

Para ser consideradas, todas las solicitudes deben ser enviadas por vía electrónica a través del sistema de solicitudes en línea antes del cierre del período de presentación.

No se tomará en consideración una solicitud, excepto si existen circunstancias excepcionales, si:

• Se recibe con posterioridad al cierre del período de presentación de solicitudes.

• El formulario de solicitud está incompleto (las preguntas no se han respondido íntegramente o faltan los comprobantes requeridos). Normalmente, los postulantes no podrán complementar sus solicitudes después de enviarlas.

• No se hubiera abonado la tarifa de evaluación dentro del plazo estipulado. Consulte la sección 1.5 para conocer la información sobre tarifas.

ICANN ha hecho todo lo posible para garantizar que el sistema de solicitudes en línea esté disponible durante todo el período de presentación de solicitudes. Si el sistema de solicitudes en línea no está disponible, ICANN ofrecerá instrucciones alternativas para presentar las solicitudes.

1.1.2 Etapas del proceso de solicitudes

En esta subsección se ofrece una descripción general de las etapas implicadas en el proceso de una solicitud enviada a ICANN. En la figura 1-1, el recorrido más corto y directo se ha marcado con líneas en negrita, aunque también se muestran ciertas etapas que pueden aplicarse o no a un caso determinado. Sigue una breve descripción de cada etapa.



Application Submission

Period

Initial Evaluation

Transition to Delegation

Extended Evaluation

Dispute Resolution

String Contention

Administrative Completeness

Check

Objection Filing

Figura 1-1: una vez enviadas las solicitudes a ICANN, pasarán por una serie de etapas del proceso.

1.1.2.1 Período de presentación de solicitudes Al momento que se inicia el período de presentación de solicitudes, o previo al inicio de dicho período, los postulantes quequienes deseen solicitar un presentar solicitudes de gTLD nuevonuevos pueden registrarse como usuarios del sistema de solicitudes en línea. La información suministrada en el proceso de registro se utilizará para validar la identidad del usuario registrado.de TLD (TAS).

A través del sistema de solicitudes, los postulantesUna vez completado el registro, los usuarios del TAS entregarán un depósito parcial para cada vacante o “ranura” de las solicitudes realizadas; luego, recibirán códigos de acceso que los habilitarán para completar el formulario de solicitud completo. Para completar la solicitud, los usuarios responderán a una serie de preguntas para proporcionar información general, demostrar su capacidad financiera y demostrar su capacidad técnica y operativa. Los comprobantes detallados en la subsección 1.2.32 del presente módulo también deben enviarse a través del sistema de solicitudes al responder las preguntas pertinentes.

Los postulantes también deben enviar las tarifas de evaluación durante este período. Consulte la sección 1.5 de este módulo para conocer información adicional sobre tarifas y pagos.



Luego del cierre del período de presentación de solicitudes, ICANN enviará a los postulantes actualizaciones de estado periódicas relativas al avance de sus solicitudes. 1.1.2.2 Comprobación administrativa Inmediatamente después del cierre del período de presentación de solicitudes, ICANN revisará que todas las solicitudes estén debidamente completadas. Esta comprobación garantiza que:

• Se han respondido todas las preguntas obligatorias,.

• Se proporcionan los comprobantes necesarios en formato adecuado y

• Se han recibido las tarifas de evaluación.

ICANN hará una publicación conpublicará todas las solicitudes que se consideran completas y aptas para la evaluación lo antes posible, luego del cierre del transcurrido el período de presentación de solicitudes. ICANN considera que determinadas preguntas, como lasciertas preguntas relativas a las finanzas, la arquitectura y la seguridad, son confidenciales: no se publicarán las respuestas de los postulantes a estas preguntas. Las preguntas confidenciales se identifican como tales en el formulario de solicitud. El resto de la solicitud sísegún sea enviada por el postulante se publicará en el sitio web de ICANN. Se espera que la comprobación administrativa de todas las solicitudes esté finalizada en aproximadamente 4 semanas, aunque esto depende del volumen de solicitudes recibidas. Si no se pudieran procesar todas las solicitudes dentro del período de 4 semanas, ICANN publicará información actualizada sobre el proceso y un cronograma estimado.

1.1.2.3 Evaluación inicial La evaluación inicial comenzará inmediatamente después de que finalice la comprobación administrativa. Todas las solicitudes completas serán revisadas durante la evaluación inicial. Al comienzo de este período, se realizarán verificaciones de antecedentes de la entidad que hizo la solicitud y de las personas cuyos nombres



aparecen en la solicitud. Las solicitudes deben recibir la aprobación en este paso para que luego puedan llevarse a cabo las revisiones de la evaluación inicial.

Esta evaluación consta de dos puntos principales:

1. Revisiones de las cadenas (relativas a la cadena de gTLD solicitada). Las revisiones de las cadenas incluyen determinar si es probable que la cadena de gTLD genere problemas de seguridad o estabilidad en el DNS, incluidos problemas a raíz de una similitud con TLD existentes o nombres reservados.

2. Revisiones del postulante (relativas a la entidad que solicita el gTLD y sus servicios de registro propuestos). Las revisiones del postulante incluyen determinar si el postulante tiene capacidad técnica, operativa y financiera para operar un registro.

Al finalizar el período de evaluación inicial, ICANN publicará un aviso con todos los resultados de la evaluación inicial. Según el volumen de solicitudes recibidas, ICANN puede publicar tales avisos pueden publicarse en lotes durante el transcurso del período de evaluación inicial.

Se espera finalizar la evaluación inicial de todas las solicitudes en aproximadamente 5 meses. Si son alrededor de 400 a 500 solicitudes, este plazo se incrementaría enentre 1 a y 3 meses. Si así fuera, ICANN En caso de que el volumen excediera esta cantidad, se implementará un método para procesar las solicitudes en lotes, lo que extenderá los plazos implicados. Las solicitudes se seleccionarán al azar para cada lote; sin embargo, se tomarán medidas para garantizar que todas las cadenas en disputa estén dentro del mismo lote. En este caso, ICANN publicará información actualizada sobre el proceso y un cronograma estimado.

1.1.2.4 Presentación de objeciones Las partes con derecho a objetar pueden presentar objeciones formales a las solicitudes sobre cualquiera de los cuatro motivos enumerados. El período de presentación de objeciones se abrirá después de que ICANN publique la lista de solicitudes completas, según se



describe en la subsección 1.1.2.2.., y durará cinco meses y medio aproximadamente.

Los objetantes deberán presentar las objeciones formales directamente a los proveedores de servicios de resolución de disputas (DRSP), no a ICANN. Consulte el módulo 3, Procedimientos de la resolución de disputas, para conocer más detalles.

El período de presentación de objeciones se cerrará luego de finalizado el período de evaluación inicial (consulte la subsección 1.1.2.3), con un lapso de dos semanas entre la publicación de los resultados de la evaluación inicial y el cierre del período de presentación de objeciones. Las objeciones que se hayan presentado durante el período de presentación de objeciones se abordarán en la etapa de resolución de disputas, que se indica en la subsección 1.1.2.67 y se explica con detalle en el módulo 3.

Todos los postulantes deben tener en cuenta que los terceros tienen la oportunidad de presentar objeciones a cualquier solicitud durante el período de presentación de objeciones. Los postulantes cuyas solicitudes estén sujetas a una objeción formal tendrán la oportunidad de presentar una respuesta en conformidad con las reglas y procedimientos estipulados por el proveedor de servicios de resolución de disputas (consulte el módulo 3).

. Un postulante que desee presentar una objeción formal a otra solicitud que haya sido presentada, deberá hacerlo dentro del período de presentación de objeciones, siguiendo los procedimientos de presentación de objeciones del módulo 3.

1.1.2.5 Comentarios públicos Los mecanismos de comentarios públicos forman parte de los procesos de desarrollo e implementación de políticas y de los procesos operativos de ICANN. Como asociación pública y privada, ICANN se ocupa de: preservar la estabilidad y seguridad operativa de Internet, promover la competencia, lograr una amplia representación de las comunidades globales de Internet y elaborar políticas adecuadas para su misión a través de procesos participativos y consensuados. Esto necesariamente implica la participación de numerosos grupos de partes interesadas en un debate público.



En el proceso de solicitud de gTLD nuevos, todos los postulantes deben saber que los foros de comentarios públicos oficiarán de mecanismo para que el público acerque información y cuestiones relevantes para que las analicen quienes están a cargo de administrar las solicitudes de gTLD nuevos. Cualquiera puede presentar un comentario en el foro de comentarios públicos.

ICANN abrirá un período para comentarios públicos cuando se publiquen las solicitudes en el sitio web de ICANN (consulte la subsección 1.1.2.2), que permanecerá abierto durante 45 días calendario. Este período permitirá que la comunidad cuente con el tiempo para revisar y enviar comentarios acerca de los materiales publicados que acompañan a la solicitud, para la consolidación de los comentarios recibidos y su distribución a los paneles a cargo de realizar las revisiones y para que los examinadores efectúen un análisis dentro del plazo establecido para la evaluación inicial. Este período para comentarios públicos está sujeto a una extensión, de acuerdo con el tiempo establecido para el período de evaluación inicial, si así lo exigieran el volumen de solicitudes u otras circunstancias.

Los comentarios recibidos durante el período de comentarios públicos se etiquetarán para una solicitud específica. Los examinadores realizarán las diligencias necesarias relativas a los comentarios (por ejemplo, determinar su importancia respecto de la evaluación, verificar la exactitud de las reclamaciones, analizar la significación de las referencias citadas) y tendrán en cuenta la información vertida a través de estos comentarios. La consideración de la aplicación de la información enviada a través de comentarios públicos se incluirá en los informes de los examinadores.

El foro de comentarios públicos permanecerá abierto durante las etapas posteriores del proceso de evaluación, a fin de proporcionar un medio para que el público ponga en consideración de ICANN cualquier otra información o cuestiones importantes.

Se debe realizar una distinción entre comentarios públicos, que podrían ser relevantes para la tarea de ICANN de determinar si las solicitudes cumplen los criterios establecidos, y las objeciones formales que conciernen a asuntos ajenos a esos criterios de evaluación. El proceso de objeción formal fue creado para permitir una



consideración completa y cabal de las objeciones basadas en áreas limitadas, ajenas a la evaluación de solicitudes de ICANN en lo relativo al mérito. Durante la evaluación inicial, los paneles no tendrán en cuenta los comentarios públicos asociados con objeciones formales; no obstante, un panel de expertos podrá considerarlos posteriormente en un proceso de resolución de disputas (consulte la subsección 1.1.2.7).

1.1.2.65 Extensión de la evaluación Este tipo de evaluación se aplica solamente a determinados postulantes que no aprueben la evaluación inicial.

Los postulantes que no pasen determinados puntos de la evaluación inicial pueden solicitar una extensión de la evaluación. Si el postulante no aprueba la evaluación inicial y no solicita expresamente una extensión de la evaluación, no se le dará más curso. El período de extensión de la evaluación permite un intercambio de información adicional entre el postulante y los examinadores para aclarar información de la solicitud. Las revisiones realizadas en la extensión de la evaluación no presentan más criterios de examen.

Además del hecho de no pasar ciertos puntos de la evaluación,También se puede requerir la extensión de la evaluación para una solicitud si la cadena de gTLD solicitada o uno o más servicios de registro propuestos plantean cuestiones técnicas que podrían afectar negativamente a la seguridad y la estabilidad del DNS. El período de extensión de la evaluación contempla un plazo para investigar estas cuestiones. Los postulantes serán informados si se requieren tales revisionesrequiere tal revisión al final del período de evaluación inicial.

Los examinadores y los expertos correspondientes consultados comunicarán las conclusiones a las que hayan llegado mediante la revisión adicional al finalizar el período de extensión de la evaluación.

Al finalizar el período de extensión de la evaluación, ICANN publicará todos los informes de los examinadores correspondientes a los períodos de la evaluación inicial y de extensión de la evaluación.

Si una solicitud pasa la extensión de la evaluación, podrá dársele curso para continuar con la etapa siguiente. Si la



solicitud no aprueba la extensión de la evaluación, no se le dará más curso.

Se espera que la extensión de la evaluación de todas las solicitudes se realice en aproximadamente 5 meses, aunque este plazo podría ser mayor según el volumen de solicitudes. En este caso, ICANN publicará información actualizada sobre el proceso y un cronograma estimado.

1.1.2.67 Resolución de disputas La resolución de disputas se aplica solamente a postulantes cuyas solicitudes están sujetas a una objeción formal.

En el caso de que se presenten objeciones formales y se paguen las tarifas de presentación durante el período de presentación de objeciones, los proveedores de servicios de resolución de disputas (DRSP) iniciarán y finalizarán los procesos según las objeciones recibidas. La finalidad del procedimiento relativo a las objeciones formales es brindar una vía para aquellos que desean objetar una solicitud presentada a ICANN. Los proveedores de servicios de resolución de disputas se desempeñan como foros para arbitrar en los procesos en función del tema en cuestión y de la pericia necesaria. La consolidación de las objeciones presentadas se realizará cuando corresponda, a criterio del DRSP.

Los comentarios públicos también pueden ser relevantes para uno o más fundamentos de objeción. Consulte el módulo 3, Procedimientos de resolución de disputas, para conocer los motivos de objeción. Los DRSP tendrán acceso a todos los comentarios públicos recibidos y los podrán considerar a su discreción.

Como resultado de un proceso de resolución de disputas, puede tener éxito el postulante (en cuyo caso la solicitud continuará con la etapa siguiente) o bien el objetante (en cuyo caso la solicitud no continuará o deberá someterse a un procedimiento de resolución de disputas). Si hubiera varias objeciones, el postulante debe tener éxito en todos los procesos de resolución de disputas relativos a la solicitud a fin de continuar con la etapa siguiente. Los DRSP notificarán a los postulantes el resultado del procesode los procesos de resolución de disputas. Consulte el módulo 3, Procedimientos de resolución de disputas, para conocer más detalles.



Se espera que los procesos de resolución de disputas, en los casos que corresponda, se completen para todas las solicitudes en aproximadamente 5 meses. Si el volumen de solicitudes impidiera cumplir con este período, ICANN trabajará con los proveedores de servicios de resolución de disputas para crear procedimientos de procesamiento y publicar información actualizada sobre el cronograma.

1.1.2.7 8 Disputa por cadenas La disputa por cadenas sólo se aplica cuando hay más de una solicitud calificada para la misma cadena de gTLD o una similar.

La disputa por cadenas se refiere a un escenario donde hay más de una solicitud calificada para la misma cadena de gTLD o para cadenas de gTLD que son tan similares que podrían generar una confusión en detrimento del usuario si se delegara más de una. LosSe insta a los postulantes a que resuelvan los casos de disputa por cadenas entre ellos antes de la etapa de resolución de disputas por cadenas. Ante la falta de una resolución por parte de los solicitantes en disputa, los casos de disputas por cadenas se resuelven a través de una evaluación (comparativa) con prioridad de la comunidad (si un postulante comunitario así lo elige) o por medio de una subasta.

En caso de disputa entre cadenas de gTLD solicitadas que representan nombres geográficos, se puede solicitar a las partes que sigan un proceso diferente para resolver la disputa. Consulte la subsección 2.12.1.4 del módulo 2 para obtener más información.

Los grupos de cadenas solicitadas que son idénticas o lo suficientemente similares para causar confusión se denominan grupos en disputa. Todos los postulantes deben saber que si se identifica una solicitud como parte de un grupo en disputa, los procedimientos para la resolución no comenzarán hasta que todas las solicitudes del grupo en disputa hayan cumplimentado todos los aspectos de la evaluación, incluso la resolución de disputas, si corresponde.

Para ilustrarlo, en la figura 1-2, los postulantes A, B y C solicitan .EJEMPLO y se identifican como un grupo en disputa. Los postulantes A y C aprueban la evaluación inicial, pero el postulante B no. El postulante B solicita una



extensión de la evaluación. Un tercero presenta una objeción a la solicitud del postulante C, y este postulante ejecuta el proceso de resolución de disputas. El postulante A debe esperar hasta ver si los postulantes B y C completan satisfactoriamente las fases de extensión de la evaluación y de resolución de disputas, respectivamente, antes de poder pasar a la etapa de resolución de disputas por cadenas. En este ejemplo, el postulante B aprueba la extensión de la evaluación, pero el postulante C no tiene éxito en el proceso de resolución de disputas. Entonces se pasa a la resolución de disputas por cadenas entre el postulante A y el B.

Figura 1-2: todas las solicitudes de un grupo en disputa deben completar todas las etapas previas de evaluación y de resolución de disputas antes de poder

comenzar la resolución de disputas por cadenas.

Los postulantes que tengan éxito en el procedimiento de resolución de disputas por cadenas continuarán con la delegación de los gTLD solicitados.

En caso de una evaluación con prioridad de la comunidad (consulte el módulo 4, Procedimientos de disputa por cadenas), ICANN suministrará los comentarios recibidos durante el período de comentarios públicos a los examinadores con instrucciones para que tomen en cuenta la información relevante al momento de definir las conclusiones.

Se estima que la resolución de disputas por cadenas de un grupo en disputa insume de 2 meses y medio a 6 meses. El tiempo que demore variará según el caso, ya que algunos



casos de disputa se pueden resolver con una evaluación (comparativa) con prioridad de la comunidad o con una subasta, mientras que otros requieren ambos procesos.

1.1.2.89 Transición hacia la delegación Los postulantes que completen satisfactoriamente todas las etapas correspondientes descritas en la subsección 1.1.2 deberán realizar una serie de pasos finales antes de la delegación del gTLD solicitado a la zona raíz. Estos pasos comprenden la ejecución de un acuerdo de registro con ICANN y la realización de una prueba técnica previa a la delegación a fin de validar la información provista en la solicitud.

Tras la celebración de un acuerdo de registro, el operador de registro potencial debe completar la instalación técnica y tener un desempeño satisfactorio en una serie de pruebas técnicas antes de concretar la delegación del gTLD a la zona raíz. Si no se satisfacen los requisitos de puesta en marcha inicialesla prueba previa a la delegación para poder delegar el gTLD a la zona raíz dentro del período de tiempo especificado en el acuerdo de registro, ICANN puede a su sola y absoluta discreción optar por rescindir el acuerdo de registro.

Una vez que todos los pasos hayan sido cumplimentados satisfactoriamente, el postulante reúne las condiciones para la delegación del gTLD solicitado a la zona raíz del DNS.

Se espera que la transición a los pasos de delegación se complete en aproximadamente 2 meses, aunque podría insumir más tiempo según el nivel de preparación del postulante para las pruebas previas a la delegación y el volumen de solicitudes sometidas a estos pasos simultáneamente. 1.1.2.93 Cronograma del ciclo

Según los cálculos para cada etapa descrita en esta sección, el ciclo de una solicitud sin complicaciones podría insumir alrededor de 8 meses, como se ejemplifica a continuación:



Figura 1-3: una solicitud sin complicaciones podría tener un ciclo aproximado de 8 meses.

El ciclo de una solicitud muy compleja podría ser mucho más largo, de hasta 19 meses, como se muestra en el siguiente ejemplo:

Figura 1-4: una solicitud compleja podría tener un ciclo aproximado de 19 meses.

1.1.3 La función de los comentarios públicos en la evaluación de Postulantes

Los mecanismos de comentario público forman parte de los procesos de desarrollo e implementación de políticas de ICANN. Como asociación pública y privada, ICANN se ocupa de preservar la estabilidad y seguridad operativa de Internet, promover la competencia, lograr una amplia



representación de las comunidades globales de Internet y elaborar políticas adecuadas para su misión a través de procesos participativos y consensuados. Lo cual necesariamente implica la participación de numerosos grupos de partes interesadas en un debate público.

En el proceso de solicitud de gTLD nuevos, los comentarios públicos oficiarán de mecanismo para que el público acerque información y cuestiones relevantes para que las analicen quienes están a cargo de administrar las solicitudes de gTLD nuevos. ICANN abrirá un foro de comentarios públicos cuando se den a conocer públicamente las solicitudes en su sitio web (consulte la subsección 1.1.2.2). El foro permanecerá abierto durante las etapas de evaluación descritas en la subsección 1.1.2. Cualquiera puede agregar un comentario en el foro de comentarios públicos. Toda parte que se ponga en contacto con ICANN con el fin de elevar una objeción será referida a los canales de objeción formales específicamente diseñados para resolver estos asuntos en el proceso de solicitud de gTLD nuevos. En el módulo 3, encontrará más información sobre los procesos de objeción y de resolución de disputas. Los comentarios públicos recibidos se entregarán a los examinadores durante los períodos de evaluación inicial y de extensión de la evaluación. Los examinadores tomarán en cuenta la información provista en estos comentarios.

ICANN entregará todos los comentarios públicos recibidos a los proveedores de servicio de resolución de disputas, quienes los podrán considerar a su discreción.

En caso de una evaluación (comparativa) con prioridad de la comunidad (consulte el módulo 4, Procedimientos de disputa por cadenas), ICANN suministrará los comentarios recibidos a los examinadores con instrucciones para que tomen en cuenta la información relevante al momento de definir las conclusiones. Dado que la evaluación (comparativa) con prioridad de la comunidad incluye el análisis de apoyo y oposición relevantes, dichos comentarios son relevantes para la tarea en cuestión.



1.1.4 Períodos de publicación

Los resultados de las revisiones de las solicitudes se pondrán a disposición del público en diversas etapas del proceso, como se muestra a continuación.

Período Publicación del contenido

Final de la comprobación administrativa

Se publican todas las solicitudes que han aprobado la comprobación administrativa (se eliminan las partes confidenciales).

Durante la evaluación inicial

El estado de la solicitud se actualiza con los resultados de la verificación de antecedentes y de la revisión de la estabilidad del DNS a medida que se completan. Se publicarán los resultados de la revisión de la similitud de cadenas, incluidos los grupos en disputa por cadenas.

Fin de la evaluación inicial El estado de la solicitud se actualiza con todos los resultados de la evaluación inicial.

Fin de la extensión de la evaluación

El estado de la solicitud se actualiza con todos los resultados de la extensión de la evaluación. Se publican los informes resumidos realizados por los panelistas de evaluación sobre los períodos de evaluación inicial y extensión de la evaluación.

Durante la presentación de objeciones/la resolución de disputas

Las actualizaciones de las objeciones presentadas y del estado se ponen a disposición a través del sitio web del proveedor de servicios de resolución de disputas. ICANN publica el aviso de todas las objeciones después del cierre del período de presentación de objeciones.

Durante la resolución de disputas (evaluación con prioridad de la comunidad)

Se publican los resultados de cada evaluación con prioridad de la comunidad a medida que se completan.

Durante la resolución de disputas (subasta)

Los resultados de una subasta se publicarán a medida que se completen.

Transición hacia la delegación

Los acuerdos de registro se publicarán cuando se ejecuten. Se proporcionará el estado de las pruebas previas a la delegación.



1.1.45 Escenarios de solicitudes ilustrativos

Los siguientes escenarios muestran brevemente una variedad de modos en que puede darse curso a una solicitud en el proceso de evaluación. El cuadro que se muestra a continuación ejemplifica diversos procesos y resultados. No pretende ser una lista exhaustiva de todas las posibilidades. Hay otras combinaciones posibles de vías que podría seguir una solicitud.

También se incluyen plazos aproximados para cada escenario, en base a la información disponible. Los plazos reales pueden variar según diversos factores, como la cantidad total de solicitudes recibidas por ICANN durante el período de presentación de solicitudes. Cabe resaltar que se espera que la mayoría de las solicitudes atraviesen este proceso en el menor tiempo posible, es decir, sin necesidad de someterlas a los procesos de extensión de la evaluación, resolución de disputas o resolución de disputas por cadenas. Si bien la mayor parte de los escenarios que se presentan a continuación representan procesos que superan los 8ocho meses, se espera que la mayoría de las solicitudes se completen el proceso dentro del plazo de 8ocho meses.

Número de

escenario Evaluación

inicial

Extensión de la

evaluación

Presentación de

objeciones

Disputa por

cadenas

Aprobación para los pasos de

delegación Tiempo

estimado

1 Se aprueba N/C Ninguna No Sí 8 meses

2 Se desaprueba Se aprueba Ninguna No Sí 13 meses

3 Se aprueba N/C Ninguna Sí Sí De

10 meses y medio a 14 meses

4 Se aprueba N/C Tiene éxito el postulante No Sí 13 meses

5 Se aprueba N/C Tiene éxito el objetante N/C No 11 meses

6 Se desaprueba

Se abandona N/C N/C No 6 meses

7 Se desaprueba

Se desaprueba N/C N/C No 11 meses

8 Se desaprueba Se aprueba Tiene éxito el

postulante Sí Sí De


9 Se desaprueba Se aprueba Tiene éxito el

postulante Sí No De




Escenario 1 – Se aprueba la evaluación inicial, Sin objeciones, Sin disputas – En el caso más sencillo, la solicitud pasa la evaluación inicial y no hay necesidad de una extensión de la evaluación. No se presentan objeciones durante el período correspondiente, de modo que no hay ninguna disputa que resolver. Puesto que no hay disputas por la cadena de gTLD solicitada, el postulante puede celebrar el acuerdo de registro y la solicitud puede seguir hacia la delegación del gTLD solicitado. Se espera que la mayoría de las solicitudes finalicen el proceso dentro de este plazo.

Escenario 2 – Extensión de la evaluación, Sin objeciones, Sin disputas – En este caso, la solicitud desaprueba uno o más puntos de la evaluación inicial. El postulante puede optar por una extensión de la evaluación para los puntos pertinentes y la solicita. En este punto, la solicitud aprueba la extensión de la evaluación. Al igual que en el escenario 1, no se presentan objeciones durante el período correspondiente, de modo que no hay ninguna disputa que resolver. Puesto que no hay disputas por la cadena de gTLD, el postulante puede celebrar el acuerdo de registro y la solicitud puede seguir hacia la delegación del gTLD solicitado.

Escenario 3 – Se aprueba la evaluación inicial, Sin objeciones, Con disputa – En este caso, la solicitud pasa la evaluación inicial por lo cual no hay necesidad de una extensión de la evaluación. No se presentan objeciones durante el período correspondiente, de modo que no hay ninguna disputa que resolver. Sin embargo, hay otras solicitudes para la misma cadena de gTLD o una similar, por lo que se presenta una disputa. En este caso, la solicitud ganatiene éxito en la resolución de disputas y se rechazan las solicitudes de los demás competidores, por lo cual el postulante ganador puede celebrar el acuerdo de registro y la solicitud puede seguir hacia la delegación del gTLD solicitado.

Escenario 4 – Se aprueba la evaluación inicial, Se tiene éxito en la objeción, Sin disputa – En este caso, la solicitud pasa la evaluación inicial por lo cual no hay necesidad de una extensión de la evaluación. Durante el período de presentación de objeciones, un objetante con derecho presenta una objeción basada en uno de los cuatro motivos enumerados (consulte el módulo 3, Procedimientos



de resolución de disputas). Un panel proveedor de servicios de resolución de disputas atiende la objeción y se pronuncia a favor del postulante. El postulante puede celebrar el acuerdo de registro y la solicitud puede seguir hacia la delegación del gTLD solicitado.

Escenario 5 – Se aprueba la evaluación inicial, Se pierde la objeción – En este caso, la solicitud pasa la evaluación inicial por lo cual no hay necesidad de una extensión de la evaluación. Durante el período correspondiente, uno o más objetantes presentan varias objeciones basadas en uno o más de los cuatro motivos enumerados. Cada objeción es atendida por un panel proveedor de servicios de resolución de disputas. En este caso, los paneles se pronuncian a favor del postulante para la mayoría de las objeciones, pero se pronuncian a favor del objetante para una. Como se da lugar a una de las objeciones, no se puede dar curso a la solicitud.

Escenario 6 – Se desaprueba la evaluación inicial, Postulante se retira – En este caso, la solicitud desaprueba uno o más puntos de la evaluación inicial. El postulante decide retirar la solicitud en lugar de pasar a la extensión de la evaluación. No se le da curso a la solicitud.

Escenario 7 – Se desaprueba la evaluación inicial, Se desaprueba la extensión de la evaluación – En este caso, la solicitud desaprueba uno o más aspectos de la evaluación inicial. El postulante solicita una extensión de la evaluación de los puntos pertinentes. Sin embargo, la solicitud tampoco aprueba la extensión de la evaluación. No se le da curso a la solicitud.

Escenario 8 – Extensión de la evaluación, Se tiene éxito en la objeción, Se tiene éxito en disputa – En este caso, la solicitud desaprueba uno o más puntos de la evaluación inicial. El postulante puede optar por una extensión de la evaluación para los puntos pertinentes y la solicita. En este punto, la solicitud aprueba la extensión de la evaluación. Durante el período de presentación de objeciones, un objetante con derecho presenta una objeción basada en uno de los cuatro motivos enumerados. Un panel proveedor de servicios de resolución de disputas atiende la objeción y se pronuncia a favor del postulante. Sin embargo, hay otras solicitudes para la misma cadena de gTLD o una similar, por lo que se presenta una disputa. En este caso, el postulante tiene éxito con respecto a las demás solicitudes en el procedimiento de resolución de



disputas, y el postulante puede celebrar el acuerdo de registro, y se le da curso a la solicitud para la delegación del gTLD solicitado.

Escenario 9 – Extensión de la evaluación, Con objeciones, Se pierde la disputa – En este caso, la solicitud desaprueba uno o más puntos de la evaluación inicial. El postulante puede optar por una extensión de la evaluación para los puntos pertinentes y la solicita. En este punto, la solicitud aprueba la extensión de la evaluación. Durante el período de presentación de objeciones, un objetante con derecho presenta una objeción basada en uno de los cuatro motivos enumerados. Un proveedor de servicioservicios de resolución de disputas atiende la objeción y se pronuncia a favor del postulante. Sin embargo, hay otras solicitudes para la misma cadena de gTLD o una similar, por lo que se presenta una disputa. En este caso, otro postulante tiene éxito en el procedimiento de resolución de disputas, y no se le da curso a la solicitud.

Transición hacia la delegación – Una vez que la solicitud ha completado satisfactoriamente la evaluación inicial y otras etapas que correspondan, el postulante debe completar una serie de pasos para la delegación del gTLD, entre ellos, la celebración de un acuerdo de registro con ICANN y la realización de una prueba previa a la delegación. Consulte el módulo 5 para obtener una descripción de los pasos requeridos en esta etapa.

1.1.56 Series de solicitudes subsiguientes

El objetivo de ICANN es iniciar la serie siguiente de solicitudes de gTLD lo antes posible. El cronograma exacto estará basado en la experiencia ganada y en los cambios requeridos una vez finalizada esta serie. El objetivo es que la siguiente serie de solicitudes comience dentro del término de un año desde la fecha de cierre del período de presentación de solicitudes para esta serie.

1.2 Información para todos los postulantes 1.2.1 Elegibilidad

Toda empresa, organizaciónLas empresas, organizaciones o institucióninstituciones con una buena reputación puedepueden solicitar un gTLD nuevo. No se considerarán



las solicitudes de sujetos individuales o de titulares de empresas unipersonales. Tenga en cuenta que todos los postulantes se someterán a un proceso de verificación de antecedentes. La verificación de antecedentes se realiza para proteger el interés público en la asignación de recursos de Internet fundamentales; asimismo, ICANN se reserva el derecho de rechazar una solicitud que de otra forma se consideraría calificada o de comunicarse con el postulante para hacerle preguntas adicionales, en función de la información obtenida en la verificación de antecedentes. Las circunstancias en las que ICANN puede rechazar una solicitud que de otra forma se consideraría calificada si: a. Elincluyen, entre otros, los siguientes casos en los que puede hallarse el postulante, o cualquier otro socio, funcionario, director o administrador, u otra persona o entidad propietaria (o beneficiaria) del quince por ciento o más del postulante:

i. En los últimos diez años, ha sido condenado por felonía o delito menor relacionado con actividades financieras o de gestión corporativa o ha sido juzgado por un tribunal por haber cometido fraude o incumplimiento de deber fiduciario, o es objeto de una resolución judicial que ICANN considere razonablemente equivalente sustantivo de alguno de dichos delitos;.

ii. En los últimos diez años, ha sido objeto de un expediente disciplinario por parte de un gobierno u organismo regulador de la industria por deshonestidad o uso ilícito de fondos de terceros;.

iii. En la actualidad está involucrado en un proceso judicial o de regulación que podría derivar en una condena, juicio, resolución o sanción disciplinaria de los tipos especificados en (ai) o (b);ii).

iv. Está sujeto a una descalificación impuesta por ICANN, en vigencia al momento de evaluarse la solicitud; o bien.



v. No presenta a ICANN la información de identificación necesaria para confirmar la identidad al momento de presentar la solicitud.

b. El postulante, o cualquier otro socio, funcionario, director o administrador, u otra persona o entidad propietaria (o beneficiaria) del quince por ciento o más del postulante está involucrada

vi. Está involucrado en decisiones que indican responsabilidad o prácticas reiteradas de mala fe en relación con registros de nombres de dominio, lo que incluye:

a) adquirir nombres de dominio con el propósito fundamental de vender, alquilar o de otra forma transferir los registros de nombres de dominio al propietario de una marca comercial o marca de servicio o a un competidor a título oneroso por una suma superior a los gastos erogados documentados, directamente relacionados con el nombre de dominio; o

b) registrar nombres de dominio para impedir que el propietario de la marca comercial o marca de servicio refleje la marca en un nombre de dominio correspondiente; o

c) registrar nombres de dominio con el propósito fundamental de interrumpir la actividad comercial de un competidor; o

d) usar nombres de dominio con la intención de atraer, para lograr un beneficio comercial, a usuarios de Internet a un sitio web u otra ubicación en línea, generando la posibilidad de confusión con una marca comercial o marca de servicio en lo referente a la fuente, el patrocinio, la afiliación o el aval del sitio web o ubicación o de un producto o servicio en el sitio web o ubicación.



Todos los postulantes deben hacer declaraciones específicas respecto de las circunstancias antes mencionadas.

Restricciones sobre la titularidad cruzada del registrador 1 – No se tomarán en consideración las solicitudes de cualquiera de las siguientes personas:

1. los registradores acreditados por ICANN o sus afiliados;

2. las entidades que controlan o que son beneficiarias de más del 2% de cualquier clase de títulos o acciones de un registrador acreditado por ICANN o de cualquiera de sus afiliados; o

3. las entidades en las que el 2% o más de las acciones con derecho a voto tengan como beneficiario (es decir, que posee la titularidad efectiva) a un registrador acreditado por ICANN o cualquiera de sus afiliados.

Asimismo, no se aprobarán las solicitudes en las que el postulante haya involucrado un registrador acreditado por ICANN, un revendedor o cualquier otro tipo de distribuidor, o bien cualquiera de sus afiliados (o la persona o entidad que actúe en nombre de ellos) para que proporcione servicios de registro para los TLD (dominios de primer nivel).

“Afiliado” es una persona o entidad que, directa o indirectamente, a través de uno o más intermediarios, controla, es controlada por, o está bajo control común con la persona o entidad especificada.

“Control” (incluidas las formas en que se utiliza en los términos “controlada por” y “bajo control común con”) significa la posesión, directa o indirecta, del poder de determinar o influenciar las decisiones de la gerencia o las políticas de una persona o entidad, ya sea mediante la

1 Nota: El texto de esta sección representa el posible lenguaje de implementación surgido de las resoluciones de la Junta Directiva de ICANN (adoptado en la reunión de ICANN de Nairobi) con respecto a la separación de las funciones y titularidad de los registros y los registradores <http://www.icann.org/en/minutes/resolutions-12mar10-en.htm#5>. Durante la reciente reunión ordinaria de la Junta Directiva realizada en Dublín en mayo de 2010, la Junta revisó posibles temas que podrían surgir de una interpretación estricta de las resoluciones de la Junta. El razonamiento de la Junta fue que: 1) las limitaciones más estrictas propuestas en el borrador sobre la titularidad cruzada representan una “posición en rebeldía” y siguen instando a la GNSO a que cree una política basada en la parte interesada en relación con estos problemas; 2) una interpretación muy estricta de las resoluciones podría dar lugar a consecuencias no previstas; 3) el personal debería producir un lenguaje en el acuerdo que coincida con un enfoque “de minimus” aceptable (2% del lenguaje) mientras se mantenga, en términos generales, coherente con las resoluciones; 4) la Junta promueve el aporte de la comunidad y emite comentarios acerca del correcto enfoque de estos problemas ante la ausencia de una política de la GNSO; y 5) la Junta revisará nuevamente este asunto si no se consigue una política de la GNSO con respecto a estos temas.



propiedad de acciones con derecho a voto, como fideicomisario o ejecutor, en cumplimiento de su función como miembro de una junta de directores o cuerpo directivo equivalente, por contrato, acuerdo de crédito u otro medio.

Una persona o entidad que posee “titularidad efectiva” de títulos o acciones hace referencia a toda persona que, directa o indirectamente, a través de un contrato, acuerdo, pacto, relación u otro medio, tiene o comparte (A) el poder de voto, el cual incluye la facultad de votar, o de influenciar el voto, de tales acciones; y/o (B) el poder de inversión que incluye la facultad para disponer o para determinar la disposición de tales acciones.

1.2.2 Documentación necesaria Todos los postulantes deben estar preparados para presentar la siguiente documentación, la cual debe acompañar cada solicitud:2:

1. Prueba de establecimiento legal: . Documentación del establecimiento del postulante como un tipo específico de entidad de acuerdo con las leyes aplicables de su jurisdicción.

2. Prueba de buena reputación: documentación del organismo correspondiente de la jurisdicción del postulante que certifique la buena reputación del postulante. En virtud de ciertas leyes o en determinadas jurisdicciones, podría ser posible demostrar la constitución y la buena reputación con un solo documento. En otras palabras, el mismo documento abarcaría los puntos 1 y 2.

Los documentos provistos como prueba de establecimiento y buena reputación deben constituir una respuesta coherente para la jurisdicción del postulante.

3.2. Declaraciones financieras. Los postulantes deben presentar declaraciones financieras auditadas o certificadas de forma independiente del año fiscal finalizado más reciente del postulante. En algunos

2 La prueba de buena reputación se ha eliminado como requisito de la documentación puesto que se la tratará durante la verificación de antecedentes (consulte el módulo 2). Esto también ayuda a eliminar la complejidad para los postulantes en cuanto a la obtención de tipos particulares de documentación que cumplan con los requisitos de pruebas de buena reputación, dado que las prácticas de tal documentación varían ampliamente entre las regiones del mundo.



casos, se pueden presentar declaraciones financieras no auditadas.

Los comprobantes deben presentarse en el idioma original, no es necesario presentar traducciones al inglés.

Todos los documentos deben tener validez en el momento de la presentación. Consulte los criterios de evaluación, anexados al módulo 2, para obtener más detalles sobre los requisitos para estos documentos.

Todos los documentos deben tener validez en el momento de la presentación.

Los comprobantes deben presentarse en el idioma original, no es necesario presentar traducciones al inglés.

Algunos tipos de comprobantes se requieren sólo en ciertos casos:

1. Respaldo de la comunidad – Si el postulante ha designado su solicitud como comunitaria (consulte la sección 1.2.3), deberá presentar un aval a su solicitud por escrito, emitido por una o más instituciones establecidas que representen a la comunidad que ha designado. Un postulante puede presentar avales por escrito de varias instituciones. Si corresponde, se colocará en la sección de la solicitud relacionada con la designación comunitaria.

2. Respaldo gubernamental o declaración de no objeción – Si el postulante ha solicitado una cadena de gTLD que representa un nombre geográfico, deberá presentar una declaración de respaldo de la solicitud o de no objeción, emitida por los gobiernos competentes o autoridades públicas. Consulte la subsección 2.12.1.4 para obtener más información sobre los requisitos para nombres geográficos.

3. Documentación de obligaciones de financiación de terceros – Si un postulante indica fuentes de financiación de terceros en su solicitud, debe proporcionar pruebas del compromiso de la parte que se ha comprometido a la financiación. Si corresponde, se colocará en la sección financiera de la solicitud.



1.2.3 Designación comunitaria

Todos los postulantes deben designar si su solicitud es comunitaria.

1.2.3.1 Definiciones A los fines de esta Guía del postulante, un gTLD comunitario es un gTLD que se opera en beneficio de una comunidad claramente definida. La designación o la no designación de una solicitud como comunitaria queda a criterio absoluto del postulante. Todo postulante puede designar su solicitud como comunitaria; no obstante, cada postulante que haga esta designación debe demostrar su condición de representante de la comunidad que menciona en la solicitud. mediante la presentación de un aval por escrito como comprobante de la solicitud. Se puede solicitar información adicional si hubiera una evaluación (comparativa) con prioridad de la comunidad (consulte la sección 4.2 del módulo 4). Se espera que un postulante de un gTLD comunitario:

1. Demuestre una relación continua con una comunidad claramente definida.

2. Haya solicitado de manera fehaciente una cadena de gTLD específicamente relacionada con la comunidad que se especifica en la solicitud.

3. Haya propuesto políticas de uso y de registro exclusivas para los registrantes de su gTLD propuesto, conforme al propósito comunitario que ha designado.

4. Cuente con un aval de la solicitud por escrito emanado por una o más instituciones establecidas que representen a la comunidad que ha designado.

A efectos de establecer una diferencia, una solicitud que no haya sido designada como comunitaria, en lo sucesivo, en este documento, se denominará solicitud estándar. Un gTLD estándar se puede utilizar para cualquier propósito coherente con los requisitos de los criterios de solicitud y de evaluación, y con el acuerdo de registro. Un postulante estándar puede o no tener una relación formal con un registrante exclusivo o conjunto de usuarios. Puede o no emplear requisitos de calificación y utilizar restricciones.



Estándar aquí sólo significa que el postulante no ha designado la solicitud como comunitaria.3.

1.2.3.2 Implicaciones de la designación de la solicitud

Los postulantes deben comprender qué efectos tiene designar su solicitud como comunitaria o estándar en determinadas etapas del procesamiento de la solicitud y, si la solicitud tiene éxito, la celebración del acuerdo de registro y las posteriores obligaciones como un operador de registro de gTLD, como se describe en los párrafos a continuación.

Objeciones y resolución de disputas – Todos los postulantes deberán comprender que se puede presentar una objeción a cualquier solicitud por motivos de una comunidad, aun cuando el postulante no se hubiera designado como comunitario o no hubiera declarado que el gTLD está orientado a una comunidad en particular. Consulte el módulo 3, Procedimientos de resolución de disputas.

Disputa por cadenas – La resolución de disputas por cadenas puede incluir uno o más componentes, de acuerdo con la composición del grupo en disputa y las elecciones hechas por los postulantes comunitarios.

• Se puede producir un acuerdo entre las partes en cualquier momento luego de identificada la disputa. Se alentará a las partes para que se reúnan con miras a resolver la disputa. Los postulantes en disputa siempre pueden resolver el conflicto en forma voluntaria, lo que genera el retiro de una solicitud o más, antes de pasar a la etapa de resolución de disputas.

• Se producirá una evaluación (comparativa) con prioridad de la comunidad sólo si un postulante comunitario en un grupo en disputa elige esta opción. Todos los postulantes comunitarios en un grupo en disputa tendrán esta opción llegado el caso de que continúe una disputa luego de que las solicitudes hayan completado con éxito todas las etapas de evaluación previas.

3 El término “estándar” reemplaza a “abierta”, término antes empleado para solicitudes que no eran designadas como comunitarias. En general, “abierta” se prestaba a confusión, ya que una solicitud “abierta” de hecho podía implicar grandes restricciones en el registro de TLD.



• Tendrá lugar una subasta en caso de que no se logre resolver una disputa con una evaluación (comparativa) con prioridad de la comunidad ni con un acuerdo entre las partes. La subasta es el último recurso para resolver disputas. Si se realiza una evaluación (comparativa) con prioridad de la comunidad, pero no se logra establecer un claro ganador, se producirá una subasta para resolver la disputa.

Consulte el módulo 4, ProcedimientoProcedimientos de la disputa por cadenas, para conocer un análisis detallado de los procedimientos de resolución de disputas.

Celebración del contrato y procedimientos posteriores a la delegación – Los postulantes de gTLD comunitarios quedarán sujetos a determinadas obligaciones contractuales posteriores a la delegación para operar el gTLD en conformidad con las restricciones asociadas a la designación comunitaria. ICANN deberá aprobar los cambios importantes en el contrato, incluidos cambios en la naturaleza comunitaria del gTLD y toda disposición asociada.

Las solicitudes comunitarias pretenden ser una categoría limitada, para solicitudes que tienen asociaciones marcadasno ambiguas entre el postulante, la comunidad implicada y la cadena de gTLD solicitada. La evaluación de la designación de un postulante como comunitario se llevará a cabo sólo en caso de una situación de disputa que genere una evaluación (comparativa) con prioridad de la comunidad. No obstante, todo postulante que designe su solicitud como comunitaria estará obligado, si la solicitud se aprueba, por el acuerdo de registro a implementar las restricciones comunitarias especificadas en la solicitud. Esto sucede incluso cuando no hay postulantes en disputa.

1.2.3.3 Cambios en la designación de la solicitud Los postulantes no pueden cambiar la designación de estándar a comunitaria una vez que hayan presentado la solicitud de gTLD.

1.2.4 Aviso relativo a temas de aceptación técnica en gTLD nuevos



Todos los postulantes deben tener en cuenta que la aprobación de una solicitud y la celebración de un acuerdo de registro con ICANN no garantizan que el gTLD nuevo funcionará inmediatamente en la red. La experiencia pasada indica que los operadores de redes tal vez no tengan compatibilidad total e inmediata con nuevos dominios de primer nivel, incluso cuando estos dominios se hayan delegado a la zona raíz del DNS, ya que es posible que se necesiten modificaciones de software de terceros, y esto puede no suceder inmediatamente.

Del mismo modo, las aplicaciones de software a veces intentan validar nombres de dominio y tal vez no reconozcan dominios de primer nivel nuevos o desconocidos. Si bien ICANN no tiene autoridad ni capacidad para requerir que el software acepte nuevos dominios de primer nivel, hace públicos claramente qué dominios de primer nivel son válidos, y ha desarrollado una herramienta básica para asistir a los proveedores de aplicaciones en el uso de datos actuales de la zona raíz.

ICANN aconseja a los postulantes que se familiaricen con estos temas y los tengan en cuenta en los planes de inicio y de lanzamiento. Es posible que los postulantes que tengan éxito deban destinar grandes esfuerzos al trabajo con los proveedores para conseguir la aceptación de sus nuevos dominios de primer nivel.

Los postulantes deben consultar http://www.icann.org/en/topics/TLD-acceptance/ para tener información básica. Además, los postulantes de IDN deben consultar el material relativo a las experiencias con cadenas de prueba de IDN en la zona raíz, (consulte http://idn.icann.org/).

1.2.5 Aviso relativo a las delegaciones de TLD

ICANN sólo puede crear TLD como delegaciones en la zona raíz del DNS, expresadas mediante registros NS con cualquier registro de DS y registros de interconexión correspondientes. No existe una política que permita a ICANN aplicar los TLD como otro tipo de registro del DNS (por ejemplo, registros A, MS o DNAME) en la zona raíz.

1.2.6 Términos y condiciones



Todos los postulantes deben aceptar una serie estándar de términos y condiciones para el proceso de solicitud. Los términos y condiciones están disponibles en el módulo 6 de esta guía.

1.2.67 Aviso de cambios en la información

Si en cualquier momento durante el proceso de evaluación, la información enviada previamente por un postulante pasa a ser incorrecta o imprecisa, el postulante debe notificarlo de inmediato a ICANN, presentando los formularios correspondientes. Esto incluye información específica del solicitantepostulante, como cambios en los datos financieros y en la propiedad o control del solicitante.postulante. ICANN se reserva el derecho de solicitar una nueva evaluación de la solicitud si hubiera cambios sustanciales. El hecho de no notificar a ICANN sobre todo cambio en circunstancias que puedan ocasionar que la información provista en la solicitud se convierta en falsa o engañosa puede tener como consecuencia el rechazo de la solicitud.

1.2.8 Verificación8 Designación voluntaria

para zonas de seguridad alta4

ICANN y las partes interesadas actualmente están desarrollando una designación especial para “dominios de primer nivel para zonas de seguridad alta” (“HSTLD”), a través de un programa de HSTLD independiente. Esta designación voluntaria es para dominios de primer nivel que demuestran y cumplen con prácticas y políticas mejoradas orientadas hacia la seguridad. Si bien cualquier operador de registro, incluidos los postulantes de nuevos gTLD que tengan éxito, será elegible para participar en este programa, el desarrollo y funcionamiento de éste quedan fuera del alcance de la presente guía. La elección de un postulante de aspirar a una designación de HSTLD es totalmente independiente del proceso de evaluación y exigirá el cumplimiento de un conjunto adicional de requisitos.

Para obtener más información sobre el programa HSTLD, que incluye material sobre el desarrollo y actividades del programa

4 Esta es una sección nueva de la guía, para comentarios, a la que posteriormente se agregarán detalles adicionales.



actual, consulte http://www.icann.org/en/topics/new-gtlds/hstld-program-en.htm. Un postulante para un nuevo gTLD puede seguir determinados pasos para acceder al estado “verificado” si cumple con una serie de requisitos adicionales a los ya vigentes para todos los postulantes. De cumplir con los requisitos, este estado le permite al operador del registro del nuevo gTLD mostrar un sello para indicar que está verificado como una zona de seguridad alta y así brindar más información al usuario y aumentar su confianza. Esta alternativa de verificación es totalmente opcional. La opción de no solicitar la verificación al momento de presentar la solicitud no perjudica al postulante ni influye en la puntuación del proceso de evaluación. El proceso de verificación es totalmente independiente del proceso de evaluación y requiere la presentación de una solicitud por separado con información adicional. Para obtener la verificación, las operaciones del registro deben concordar con los siguientes principios: 1. El registro aplica controles eficaces para garantizar

en forma razonable que se mantiene la seguridad, disponibilidad y confidencialidad de los activos de información y sistemas que respaldan las funciones críticas de registro (es decir, servicios de registro, bases de datos de registro, administración de zonas y provisión de servicios de resolución de nombres de dominio) y las operaciones comerciales.

2. El registro aplica controles eficaces para garantizar

en forma razonable que el procesamiento de funciones de registro centrales está autorizado, es preciso, íntegro y se realiza en forma oportuna de acuerdo con normas y políticas establecidas. Se determina y autentica la identidad de las entidades participantes.

3. El registro aplica controles eficaces para garantizar

en forma razonable que el procesamiento de funciones centrales del registrador por parte de sus registradores está autorizado, es preciso, íntegro y se realiza en forma oportuna de acuerdo con normas y políticas establecidas. Se determina y autentica la identidad de las entidades participantes.



Los procesos requeridos para lograr este estado de seguridad alta incluyen la verificación de las operaciones de registro y las operaciones de apoyo de los registradores. La evaluación de verificación es realizada por un organismo independiente, externo al proceso de evaluación de los gTLD. Si un postulante desea solicitar la verificación, participa en un proceso de dos etapas. (1) Previo a la delegación del nuevo gTLD, el postulante

participa en una evaluación (Etapa 1) para determinar que el operador de TLD haya designado y establecido controles técnicos y procedimentales apropiados para las operaciones, acorde a los requisitos.

(2) Una vez delegado el nuevo gTLD y luego de que

comienzan las operaciones, se estipula un período determinado para que el operador del registro implemente todos los procesos y controles aprobados previamente. Luego hay una segunda evaluación de verificación (Etapa 2) con la cual se comprueban los procesos, controles y procedimientos documentados en la Etapa 1 a fin de validar que ese registro esté operando como se planificó. Si la agencia a cargo de la evaluación independiente identifica deficiencias, se las comunicará al operador del registro. El operador del registro dispondrá de un tiempo limitado para resolver el problema antes de que se rechace la solicitud de verificación. El operador del registro posteriormente puede volver a solicitar la verificación.

Si una solicitud de un nuevo gTLD completa la evaluación y se delega el TLD, el operador del registro puede optar por solicitar la verificación en otro momento, y entonces deberá realizar las pruebas mencionadas arriba en un paso. Es decir, un postulante puede decidir proceder con los pasos para obtener la verificación luego de haber completado el proceso de evaluación, cuando ya está operando su nuevo gTLD, en lugar de hacerlo en forma simultánea con el proceso de evaluación. Los controles necesarios para respaldar la verificación se evalúan con auditorías periódicas para conservar el estado de verificado del gTLD.



El postulante deberá abonar tarifas adicionales para ambas etapas del proceso de verificación. Las tarifas no afectarán los ingresos y es posible que se abonen a un tercero directamente. Consulte el memorando explicativo Modelo para un programa de verificación para zonas de seguridad alta para conocer un análisis detallado sobre la opción de verificación para zonas de seguridad alta.

1.3 Información para postulantes de nombres de dominio internacionalizados (IDN)

Se espera que algunas cadenas de gTLD solicitadas sean nombres de dominio internacionalizados (IDN) que requieren la inserción de etiquetas A con codificación IDN en la zona raíz del DNS.). Los IDN son nombres de dominio que incluyen caracteres utilizados en la representación local de idiomas que no emplean el alfabeto latino básico (a - z), dígitos árabe-europeos (0 - 9) y el guión (-). Según se describe a continuación, los nombres de IDN requieren la inserción de etiquetas A en la zona raíz del DNS.

1.3.1 Requisitos específicos de los IDN

Los postulantes de una cadena de IDN deben suministrar información adicional que indique el cumplimiento del protocolo IDNA y otros requisitos. En la actualidad, se está revisando el técnicos. El protocolo IDNA y lasu documentación respectiva se encuentra disponiblepueden encontrarse en http://tools.ietf.org/wg/idnabis/.http://icann.org/en/topics/idn/rfcs.htm.

Los postulantes deben suministrar las cadenas de gTLD solicitadas en el formato de etiqueta U (los TLD de IDN en caracteres locales) y de etiqueta A.

Una etiqueta A es el formato ASCII de una etiqueta IDN. Cada etiqueta A de un IDN comienza con el prefijo ACE IDNA, “xn--”, seguido de una cadena que es un resultado válido del algoritmo Punycode y, por lo tanto, tiene una longitud máxima de 5963 caracteres ASCII en total. El prefijo y la cadena en conjunto deben cumplir con todos los requisitos para una etiqueta que se pueda almacenar en el DNS, incluido el cumplimiento con la regla de letras,



dígitos o guiones (nombre de host) que se describe en RFC 1034, RFC 1123 y en otros lugares.

Una etiqueta U es el formato Unicode de una etiqueta IDN, que el usuario espera ver en las solicitudes.

Por ejemplo, si se utiliza la cadena de prueba de IDN actual en caracteres cirílicos, la etiqueta U será <испытание> y la etiqueta A será <xn--80akhbyknj4f>. La etiqueta A debe poder generarse por conversión a partir de una etiqueta U y viceversa.

En el momento de presentar la solicitud, también se requerirá a los postulantes de gTLD de IDN que proporcionen la siguiente información:

1. Forma cortaSignificado o reformulación de la cadena (en inglés).. El postulante debe presentar una descripción breve de lo que significaría o representaría la cadena en inglés.

2. Idioma de la etiqueta (ISO 639-1). El postulante debe especificar el idioma de la cadena de TLD solicitada, según los códigos ISO para la representación de los nombres de idiomas y en inglés.

3. Escritura de la etiqueta (ISO 15924). El postulante debe especificar la escritura de la cadena de gTLD solicitada, según los códigos ISO para la representación de nombres de escrituras y en inglés.

4. Puntos de código Unicode. El postulante debe enumerar todos los puntos de código que contiene la etiqueta U según el formato Unicode respectivo.

Tablas de IDN. Una tabla de IDN incluye la lista de los caracteres habilitados para el registro en nombres de dominio conforme con la política de registro. Incluirá cualquier caracter múltiple que se pueda considerar “el mismo” en los registros del segundo nivel (“variantes de caracteres”). Una vez que estén en uso en un registro de TLD activo, las tablas se alojan en el Repositorio de prácticas IDN de IANA. Para obtener más información, consulte las tablas existentes en http://iana.org/domains/idn-tables/ y las pautas de presentación en http://iana.org/procedures/idn-repository.html.

5. Los postulantes también deben demostrar que han tomado las medidas necesarias para asegurar que la



cadena de IDN codificada no genera problemas de representación ni de funcionamiento. Por ejemplo, se han detectado problemas en las cadenas que incluyen caracteres con direccionalidad combinada de derecha a izquierda y de izquierda a derecha cuando hay numerales al lado del separador de ruta (es decir, unel punto). 5

Si el postulante solicita una cadena con problemas conocidos, debe documentar las medidas que tomará para atenuar estos problemas. Si bien no se pueden evitar todos los problemas de representación, es importante que se identifique la mayor cantidad y lo más pronto posible, y que el potencial operador del registro esté al tanto de estos problemas. Los postulantes pueden familiarizarse con estos problemas familiarizándose con el protocolo IDNA y, en particular, la nueva versión propuesta de dicho protocolo (consulte http://www.icann.org/en/topics/idn/rfcs.htm), además de participar en forma activa en el wiki de IDN (consulte http://idn.icann.org/) donde se demuestran algunos problemas de representación.

5.6. [Opcional] Representación de la etiqueta en alfabeto fonético. El postulante puede suministrar su cadena de gTLD solicitada según el alfabeto fonético internacional (http://www.langsci.ucl.ac.uk/ipa/).). Tenga en cuenta que esta información no será evaluada ni calificada. Si se suministra, la información se utilizará como guía para que ICANN responda consultas o hable sobre la solicitud en presentaciones públicas.

1.3.2 Tablas de IDN

Identifica cualquier carácter múltiple que se considere equivalente a los efectos del registro de nombres de dominio (“variantes de caracteres”). Las variantes de caracteres (tal como se las define en RFC 3743) tienen lugar cuando un único carácter conceptual tiene dos o más representaciones gráficas, que pueden, o no, ser visualmente similares.

Pueden encontrarse ejemplos de tablas de IDN en el Repositorio de IDN de IANA en http://www.iana.org/procedures/idn-repository.html.

5 Consulte ejemplos en http://stupid.domain.name/node/683



Cuando se trata de una solicitud de un gTLD de IDN, las tablas de IDN deben enviarse para el idioma o alfabeto de la cadena de gTLD solicitada (las “tablas de primer nivel”). Las tablas de IDN también deben enviarse para cada idioma o alfabeto en el cual el postulante desea ofrecer los registros de IDN en el segundo nivel o niveles inferiores.

Cada postulante es responsable de la elaboración de sus tablas de IDN, incluida la especificación de cualesquiera variantes de caracteres6. Las tablas deben respetar las pautas de IDN de ICANN y toda actualización relacionada con ellas, entre las que se incluyen:

• Cumplir con los estándares técnicos de IDN.

• Implementar un enfoque basado en la inclusión (es decir, los puntos de código no permitidos explícitamente por el registro están prohibidos).

• Definir las variantes de caracteres.

• Excluir los puntos de código no permitidos según las pautas, por ejemplo, símbolos formados por líneas, signos tipográficos, signos de puntuación estructurales.

• Elaborar tablas y políticas de registro en colaboración con las partes interesadas para abordar problemas comunes.

• Depositar tablas de IDN con el repositorio de IANA de prácticas IDN (una vez aceptadas como un TLD).

Las tablas de IDN de un postulante deben impedir la confusión del usuario en la implementación de los gTLD de IDN. Se solicita encarecidamente a los postulantes que, como parte de su tarea de definir las variantes de caracteres, consideren los problemas específicos del sistema de escritura y lingüísticos capaces de provocar dificultades cuando los caracteres se utilizan en nombres de dominios.

Para evitar la confusión del usuario debido a diferentes prácticas entre registros de TLD, se recomienda que los postulantes colaboren con los operadores de TLD que ofrecen registro de nombre de dominio con los mismos caracteres o caracteres visualmente similares.

6 Consulte http://www.icann.org/en/topics/idn/idn-guidelines-26apr07.pdf



Como ejemplo, a menudo se comparten idiomas o alfabetos que trascienden los límites geográficos. En ciertas ocasiones, esto podría causar confusión entre los usuarios de las comunidades que usan el idioma o alfabeto en cuestión; en ciertos casos, también podría existir confusión visual entre los diferentes alfabetos (griego, cirílico y latino, por ejemplo).

Se solicitará a los postulantes que describan el proceso utilizado en la elaboración de las tablas de IDN presentadas. ICANN puede comparar la tabla de IDN de un postulante con las tablas de IDN de los mismos idiomas o alfabetos que ya existen en el repositorio de IANA o que de otro modo se hayan enviado a ICANN. Si aparecen irregularidades que no se hayan explicado en la solicitud, ICANN puede solicitar al postulante que describa el fundamento de tales diferencias. Para los postulantes que deseen realizar y revisar tales comparaciones antes de presentar una tabla a ICANN, se pondrá a disposición una herramienta para la comparación de tablas. ICANN aceptará las tablas de IDN del postulante en función de los factores antes mencionados.

Una vez que la cadena solicitada haya sido delegada como un TLD en la zona raíz, las tablas presentadas se registrarán en el repositorio de IANA de prácticas IDN. Para obtener más información, consulte las tablas existentes en http://iana.org/domains/idn-tables/ y las pautas de presentación en http://iana.org/procedures/idn-repository.html. 1.3.3 Variante de TLD7 de IDN

Una variante de cadena proviene de la sustitución de uno o más caracteres en la cadena de gTLD que se solicita con variantes de caracteres basándose en la tabla de IDN del postulante.

7 El tema de la administración de las variantes en el nivel superior se ha analizado en la comunidad durante cierto tiempo. ICANN trabaja para respaldar la implementación de dominios de primer nivel de IDN lo más pronto posible, mientras elabora un enfoque para abordar problemas de variantes en el corto plazo debido a que aún no se ha aceptado un mecanismo para la administración de variantes en el nivel superior. Anteriormente se publicó un borrador para la implementación de recomendaciones del Grupo de trabajo para la implementación de IDN en relación con este problema (consulte http://icann.org/en/topics/new-gtlds/idn-variants-15feb10-en.pdf). Esta sección tiene el propósito de hacer uso de dicho trabajo y debate, y de avanzar hacia una solución de implementación completa que podría incorporarse en la versión final de la Guía del postulante. Conforme el enfoque aquí descrito, las variantes de TLD no se delegan en el corto plazo, pero las variantes de cadenas declaradas por el postulante se registran a fin de preservar la oportunidad para delegar la variante de TLD deseada una vez que se haya elaborado y probado un mecanismo apropiado.



Cada solicitud contiene una cadena de gTLD solicitada. El postulante puede también declarar en su solicitud todas las variantes de cadenas para el TLD. Cada variante de cadena que figura en la lista deberá también cumplir con los requisitos de la cadena conforme a la sección 2.2.1.3.2. Las variantes de cadenas que figuran en la solicitud se revisarán a fin de detectar la coherencia con las tablas de IDN presentadas en la solicitud. Si alguna variante de cadena declarada no respetara el uso de las variantes de caracteres de acuerdo con las tablas presentadas, el postulante será notificado y la cadena declarada dejará de considerarse una parte de la solicitud. Si se aprueba la solicitud, sólo la cadena de gTLD solicitada se delegará como un gTLD. Las variantes de cadenas que figuran en las solicitudes de gTLD triunfadoras se etiquetarán para la solicitud específica y se agregarán a una “Lista de variantes declaradas” que estarán a disposición en el sitio web de ICANN. Una lista de las variantes de cadenas pendientes (es decir, declaradas) del proceso acelerado de ccTLD de IDN se encuentra disponible en http://icann.org/en/topics/idn/fast-track/string-evaluation-completion-en.htm. Estas listas están vigentes para preservar la posibilidad de asignar variantes de cadenas de TLD a las entidades correspondientes cuando se desarrolle un mecanismo de administración de variantes. Toda solicitud posterior en ICANN de las cadenas que figuran en estas listas quedan sujetas a rechazo en función de la revisión de la similitud de cadenas (consulte el módulo 2). Las variantes de TLD pueden delegarse únicamente cuando se complete un mecanismo para administrar las variantes de TLD y dicho mecanismo haya sido probado por ICANN. En ese momento, podrá exigírseles a los postulantes presentar información adicional tal como detalles de implementación del mecanismo de administración de variantes de TLD; asimismo, es posible que deban participar en un proceso de evaluación posterior, que podría contener tarifas y pasos de revisión adicionales que deberán determinarse.

La declaración de variantes de cadenas en una solicitud no brinda al postulante ningún derecho o reserva respecto de una cadena en particular. Las variantes de cadenas que figuran en la Lista de variantes declaradas pueden



quedar sujetas a revisiones adicionales posteriores según un proceso y criterios que han de definirse. Aquí debe tenerse en cuenta que si bien las variantes para registros de niveles segundo e inferior se definen libremente por las comunidades locales sin ningún tipo de validación de ICANN, es posible que existan reglas específicas y criterios de validación que se indiquen para que las variantes se permitan en el primer nivel. Se espera que la información sobre las variantes proporcionada por los postulantes en la primera solicitud contribuya a una mayor comprensión de los problemas y ayude a determinar los pasos de revisión apropiados y los niveles de tarifas en lo sucesivo. Nota sobre variantes: En la actualidad, está establecido el proceso de solicitud de gTLD de modo que cada solicitud sea para una cadena, ya sea ASCII o IDN. Se han recibido comentarios relativos a que las solicitudes para cadenas de IDN también deberían incluir variantes de cadenas. Los debates sobre posibles métodos para administrar variantes en el primer nivel indican que restringir las variantes para su delegación en la zona raíz del DNS podría privar de sus privilegios a ciertas regiones que de otro modo se beneficiarían en gran medida de la introducción de TLD de IDN.

Delegar variantes de TLD a la zona raíz sin un mecanismo para asegurar que los TLD se tratan con un método que garantice una buena experiencia para los usuarios es una inquietud sobre la estabilidad relacionada con la posibilidad de confusión de los usuarios finales. Esto es comparable a la situación “companyname.com”, en la cual dos nombres de dominio (uno con caracteres latinos exclusivamente y el otro con caracteres latinos y cirílicos) parecen idénticos, pero son distintos en el aspecto técnico. Los usuarios hacen clic en la dirección “errónea”, que los lleva a un sitio que no es el que esperaban. Esto produjo un cambio en las pautas de IDN: exigir que no se mezclen alfabetos en nombres de dominio, excepto que haya un motivo lingüístico (por ejemplo, en el caso del japonés, que se representa combinando cuatro alfabetos). Esto también es un requisito para los TLD, pero así no se resuelve el problema de las variantes.



Al mismo tiempo, no permitir o bloquear variantes de TLD significa que para algunos usuarios será muy dificultoso usar TLD de IDN. En algunos casos, el usuario no puede saber qué caracter está escribiendo. Algunos teclados tienen sólo una variante del caracter, no las dos. De este modo, sin las variantes de TLD en la raíz, las comunidades pueden recibir mensajes de error al intentar acceder, por ejemplo, a una dirección web con un nombre de dominio bajo uno de estos TLD de IDN. Este no es el propósito de la implementación de IDN. En cambio, el objetivo es ayudar a que todas las comunidades tengan la misma posibilidad de acceso a Internet.

No todas las variantes son visualmente confusas. Para lograr el máximo beneficio, ICANN ha intentado acotar las variantes, y sólo incluir las que son visualmente confusas. La intención era permitir variantes de TLD que no se puedan confundir a la vista y delegar las otras a la zona raíz del DNS hasta encontrar una solución estable para abordar el problema de las variantes que son similares.

En este momento, es una cuestión pendiente saber si los problemas de estabilidad incluyen variantes de TLD que parecen diferentes, y se escriben de manera diferente, pero que los usuarios usan en forma indistinta para el mismo término.

Otra cuestión pendiente es el contenido del acuerdo entre el operador del TLD de IDN e ICANN donde se requiere que los registros de dos variantes de TLD se manejen (digamos, como paquete o con alias, de acuerdo con RFC 3747, u otra solución técnica) de determinada forma.



Por último, queda pendiente definir si es necesario exigir el cumplimiento de las reglas requeridas para el desarrollo de tablas de IDN. Estas tablas contienen información sobre los caracteres que se deben considerar como variantes. Los operadores de TLD desarrollan las tablas de IDN. Actualmente, a los operadores de TLD se les solicita que tengan en cuenta cuestiones lingüísticas y del sistema de escritura al momento de definir las variantes y que colaboren con otros operadores de TLD que ofrecen caracteres muy parecidos o iguales. Esto no siempre es viable en la práctica, y en la actualidad no hay reglas sobre cómo definir variantes. Tampoco hay mecanismos definidos para resolver disputas en casos en que puede haber comunidades en desacuerdo con respecto a la definición de una variante.

Hay un equipo de soporte para la implementación con expertos lingüísticos y técnicos que examina estas problemáticas y espera publicar una propuesta de solución para administrar las variantes en el primer nivel. Luego la solución propuesta quedará a disposición para los comentarios públicos.

1.4 Presentación de una solicitud Los postulantes pueden completar el formulario de solicitud y presentar los comprobantes a través del sistema de solicitudes de TLD (TAS) de ICANN. Para acceder al sistema, cada postulante primero debe registrarse como usuario del TAS.

Como usuario del TAS, el postulante podrá responder en cuadros de texto abiertos y enviar los comprobantes necesarios como adjuntos. Las restricciones sobre el tamaño de los adjuntos así como los formatos de archivo se detallan en las instrucciones en el sitio del TAS.

ICANN no aceptará formularios de solicitud ni comprobantes enviados a través de otro medio que no sea el TAS (es decir, copia impresa, fax, correo electrónico), salvo que tal envío responda a instrucciones específicas de ICANN dadas a los postulantes.

1.4.1 Acceso al sistema de solicitudes de TLD

Podrá accederse al sitio del TAS desde la página web de los nuevos gTLD (http://www.icann.org/en/topics/new-gtld-program.htm), y se destacarán en comunicados



referidos a la apertura del período de presentación de solicitudes.

El sitio del TAS se encuentra en [la dirección URL se insertará en la versión final de la Guía del postulante].

1.4.1.1 Registro de usuario

El registro como usuario del TAS exige la presentación de información preliminar, que se utilizará para validar la identidad de las partes involucradas en la solicitud. A continuación se muestra una descripción general de la información recabada durante el proceso de registro del usuario:

Nro. Preguntas

1 Nombre legal completo del postulante

2 Domicilio comercial

3 Número de teléfono del postulante

4 Número de fax del postulante

5 Sitio web o URL, si corresponde

6 Contacto principal: nombre, puesto, domicilio, teléfono, fax, dirección de correo electrónico

7 Contacto secundario: nombre, puesto, domicilio, teléfono, fax, dirección de correo electrónico

8 Prueba de establecimiento legal

9 Información comercial, de subsidiarias o de empresas conjuntas

10

Identificación comercial, identificación impositiva, número de registro de IVA o equivalente del postulante

11

Antecedentes del postulante: condenas previas, actividades relacionadas con el uso no autorizado de marcas comerciales en Internet

12(a) Confirmación del pago de depósito



Se recabará un subconjunto de información de identificación de la entidad que realiza el registro de usuario, además de la información del postulante que figura anteriormente. El usuario registrado podría ser, por ejemplo, un agente, representante o un empleado, que completaría la solicitud en nombre del postulante.

El proceso de registro exigirá al usuario solicitar la cantidad deseada de vacantes o “ranuras” de solicitudes. Por ejemplo, un usuario que desea presentar cinco solicitudes de gTLD pediría cinco vacantes del TAS, y el sistema le asignaría a tal usuario un único número de ID para cada una de las cinco solicitudes.

Los usuarios deberán también entregar un depósito de USD 5,000 por cada solicitud. El monto del depósito se acreditará contra la tarifa de evaluación de cada solicitud. El requisito del depósito está vigente para ayudar a reducir el riesgo de acceso innecesario al sistema de solicitudes.

Luego de completar el registro, los usuarios del TAS recibirán códigos de acceso para cada solicitud, los cuales los habilitarán para ingresar el resto de la información de la solicitud en el sistema.

No se aceptarán registros de nuevos usuarios después del [se insertará la fecha en la versión final de la Guía para el postulante].

ICANN tomará medidas razonables desde el punto de vista comercial para proteger todos los datos enviados por los postulantes contra el acceso no autorizado, pero no puede garantizar que no existan actividades maliciosas por parte de terceros que podrían, por medio de la corrupción del sistema o por otros medios, lograr el acceso no autorizado a dichos datos.

1.4.1.2 Formulario de solicitud

El formulario de solicitud consta de 50 preguntas.Una vez obtenidas las vacantes o “ranuras” para las solicitudes pedidas, el postulante completará las preguntas restantes de la solicitud. A continuación se muestra una descripción general de las áreas y las preguntas incluidas en el formulario:

Nro. Preguntas generalesInformación sobre la solicitud y las cadenas



1 Nombre legal completo del postulante

2 Domicilio comercial

3 Número de teléfono del postulante

4 Número de fax del postulante

5 Dirección de correo electrónico del postulante

6 Contacto principal: nombre, puesto, domicilio, teléfono, fax, dirección de correo electrónico

7 Contacto secundario: nombre, puesto, domicilio, teléfono, fax, dirección de correo electrónico

8 Prueba de establecimiento legal

9 Prueba de buena reputación

10

Identificación comercial, identificación impositiva, número de registro de IVA o equivalente del postulante

11

Antecedentes del postulante: condenas previas, actividades relacionadas con el uso no autorizado de marcas comerciales en Internet

12(b) Confirmación dedel pago dedel monto restante correspondiente a la tarifa de evaluación

13 Cadena de gTLD solicitada

14 Información sobre la cadena de IDN, si corresponde

15 Tablas de IDN, si corresponde

16 Atenuación de problemas de representación o de operación de IDN, si corresponde

17 Representación de cadenas en el alfabeto fonético internacional (opcional)

18 ¿La solicitud apunta a un TLD comunitario?Misión/objetivo del TLD

19

Si es comunitario, describa los elementos de las políticas propuestas y de la comunidad¿La solicitud apunta a un TLD comunitario?

20

Misión/objetivo del TLDSi es comunitario, describa los elementos de las políticas propuestas y de la comunidad



21 ¿La solicitud es para un nombre geográfico? Si es así, comprobantes requeridos

22 Indicar medidasMedidas de protección de nombres geográficos en el segundo nivel

23 Servicios de registro: suministrar el nombre y la descripción completa de todos los servicios de registro que se ofrecerán

Nro. Preguntas técnicas y operativas

24 Descripción técnica general del registro propuesto

25 Arquitectura (confidencial)

26 Capacidades de la base de datos

27 Diversidad geográfica

28 Cumplimiento del servicio DNS

29

Rendimiento del sistema de registro compartido (SRS)

30 EPP

31 Política de seguridad (confidencial)

32 Capacidad IPv6

33 Whois

34 Duración del registro

35 Prevención y atenuación del uso indebido

36 Mecanismos de protección de derechos

37 CopiasPolíticas y procedimientos de las copias de seguridad de los datos

38 Custodia

39 Continuidad del registro

40 Transición del registro (confidencial)



41 Pruebas de fallos

42 Procesos de supervisión y derivación de fallos

43 Extensiones de seguridad de nombres de dominio (DNSSEC)DNSSEC

44 IDN (opcional)

Nro. Preguntas financieras

45 Declaraciones financieras (confidencial)

46 Plantilla de proyecciones: costos y financiación (confidencial)

47 Costos: operativos y de configuración (confidencial)

48 Financiación e ingresos (confidencial)

49 Plan de contingencia: barreras, fondos, volúmenes (confidencial)

50 Continuidad: instrumento financiero (confidencial)

1.4.2 Servicio técnico Los Soporte para el postulante

El TAS también ofrecerá a los postulantes acceso a mecanismos de soporte durante el proceso de solicitud. En el TAS habrá a disposición un vínculo de soporte, que los usuarios de TAS pueden consultar la sección de Preguntaspara obtener documentación de referencia (tal como preguntas frecuentes o la base de información o guías para el usuario) o para comunicarse con [dirección de correo electrónico que se insertará en la versión final de la Guía del postulante] para acceder al el servicio técnico sobre el uso del sistema. Los. Al comunicarse con el soporte, los usuarios recibirán un número de comprobante de seguimiento para de una solicitud de soporte y una respuesta en un lapso de 48 horas. Las solicitudes de soporte se enviarán a la persona correspondiente, de acuerdo con la naturaleza de la solicitud. Por ejemplo, una solicitud de servicio técnico y una respuesta dentro de las 24 ó 48 horas vía la herramienta de envío de TAS.se derivará al personal a cargo de la resolución de problemas técnicos del TAS, mientras que una pregunta referida a la naturaleza de la



información o documentación exigidas se dirigirá a la persona de contacto correspondiente. La respuesta se añadirá a la documentación de referencia a disposición de todos los postulantes. 1.4.43 Proceso de solicitud alternativo

Si el sistema de solicitud en línea no está disponible, ICANN ofrecerá instrucciones alternativas para presentar las solicitudes.

1.5 Tarifas y pagos En esta sección, se describen las tarifas que debe pagar el postulante. También se detallan las instrucciones de pago.

1.5.1 Tarifa de evaluación de gTLD

Todos los postulantes deben abonar la tarifa de evaluación de gTLD. El importemonto de esta tarifa es de USD 185,000. La tarifa de evaluación deberá abonarse mediante un depósito de USD 5,000 que se realiza en el momento en que el usuario se registra en el TAS, y el pago de los restantes USD 180,000 se entrega con la solicitud. ICANN no comenzará la evaluación de una solicitud si no hahasta que haya recibido la tarifa total de evaluación de gTLD a lasantes de la [hora] UTC [fecha]. La tarifa de evaluación de gTLD se establece para recuperar los costos asociados con el programa de gTLD nuevos. La tarifa se establece para garantizar que el programa esté completamente financiado y no afecte los ingresos, y que no esté subsidiado por contribuciones actuales de fuentes de recursos de ICANN, incluidos registros y registradores de TLD genéricos, contribuciones ccTLD y contribuciones RIR.

La tarifa de evaluación de gTLD cubre todas las revisiones requeridas en la evaluación inicial y, en la mayoría de los casos, toda revisión requerida en la extensión de la evaluación. Si se lleva a cabo una revisión ampliada de los servicios de registro, se deberá abonar una tarifa adicional (consulte la sección 1.5.2). No hay una tarifa adicional para el postulante por una extensión de la evaluación de la estabilidad del DNS,las revisiones de nombres geográficos, revisiones técnicas y operativas o financieras. La tarifa de evaluación también cubre la evaluación (comparativa) con prioridad de la comunidad para los casos en que el postulante obtenga una puntuación satisfactoria.



Reembolsos: en algunos casos, se puede reembolsar una parte de la tarifa de evaluación para las solicitudes que se retiran antes de que finalice el proceso de evaluación. El importe del reembolso dependerá del momento del proceso en el que se retira la solicitud, como se detalla a continuación:

Reembolso para el postulante

Porcentaje de la tarifa de evaluación

Importe del reembolso

Luego de la publicación de las solicitudes hasta la publicación de los resultados de la evaluación inicial

70% USD 130.,000

Luego de la publicación de los resultados de la evaluación inicial

35% USD 65.,000

Luego de que el postulante haya completado la resolución de disputas, la extensión de la evaluación o la/s resolución/es de disputas por cadenas

20% USD 37,000

Por lo tanto, todo postulante que no haya tenido éxito es elegible para un reembolso de al menos el 20% de la tarifa de evaluación si retira su solicitud.

Todo postulante que desee retirar una solicitud debe presentar el formulario correspondiente para solicitar un reembolso y aceptar los términos y condiciones para el retiro. Los reembolsos sólo se emitirán a nombre de la organización que envío el pago originario. Todos los reembolsos se efectúan mediante transferencia. Los gastos de transacción y de transferencia bancaria incurridos por ICANN se deducirán del importe pagado.

Nota para los postulantes de la serie de prueba de concepto en el año 2000 – Los participantes del proceso de solicitud de prueba de concepto de ICANN en el año 2000 pueden ser elegibles para un crédito aplicable a la tarifa de evaluación. El importe del crédito es de USD 86,000 y está sujeto a:



• presentación de prueba documental por parte del postulante de que se trata de la misma entidad, un causahabiente de la misma entidad o una afiliada de la misma entidad que presentó la solicitud previamente;

• confirmación de que no se le concedió una cadena de TLD al postulante conforme a la serie de solicitudes de prueba de concepto del año 2000 y de que el postulante no tiene reclamaciones judiciales a partir del proceso de prueba de concepto del año 2000; y

• presentación de una solicitud, que puede tener modificaciones con respecto a la solicitud presentada originalmente en el año 2000, para la misma cadena de TLD que dicha entidad solicitó en la serie de solicitudes de prueba de concepto del año 2000.

Todo participante en el proceso de solicitud de prueba de concepto en el año 2000 es elegible para un crédito como máximo. Se puede reclamar un crédito como máximo para toda solicitud de nuevos gTLD presentada de acuerdo con el proceso detallado en esta guía. La elegibilidad para este crédito es determinada por ICANN.

1.5.2 Tarifas aplicables en ciertos casos

Es posible que los postulantes deban abonar tarifas adicionales en ciertos casos donde son aplicables procesos especializados, que incluyen:

• Tarifa de revisión de servicios de registro – Si se aplica, se pagará esta tarifa para costos adicionales incurridos en relación con una solicitud al RSTEP de una revisión ampliada. Los postulantes serán notificados si deben abonar tal tarifa. Se prevé que la tarifa para un equipo de revisión del RSTEP de tres miembros será de USD 50,000. En algunos casos, es posible que se requieran paneles de cinco miembros, o puede haber un examen más profundo a un mayor costo. En cada caso, se advertirá al postulante del costo de la revisión antes de su inicio.



Consulte la subsección 2.12.3 del módulo 2 sobre la revisión de los servicios de registro.

• Tarifa por presentación de resolución de disputas: se – Se debe abonar este importe al presentar una objeción formal y cualquier respuesta que el postulante presente ante una objeción. Esta tarifa deberá abonarse directamente al proveedor de servicios de resolución de disputas que corresponda de acuerdo con las instrucciones de pago del proveedor. ICANN estima que las tarifas de presentación no reembolsables pueden ir desde USD 1,000 a USD 5,000 (o más) por parte por proceso. Consulte con el proveedor respectivo para conocer el importe correspondiente. Consulte el módulo 3 para obtener información sobre los procedimientos de resolución de disputas.

• TarifaPago por adjudicaciónadelantado de resoluciónlos costos – En el caso de disputas:una objeción formal, esta tarifa deberá abonarse directamente al proveedor de servicios de resolución de disputas que corresponda de acuerdo con los procedimientos y la programación de costos de esetal proveedor. Normalmente, las dos partes que intervengan en el proceso de resolución de disputas deberán enviar el pago por adelantado de los costos en un importe estimado para cubrir todos los gastos del proceso. Podría tratarse de una tarifa por hora en función de la cantidad aproximada de horas que los miembros del panel deban destinar al caso (incluida la revisión de la presentación, la vista, si se permite, y la preparación de una decisión), o bien de un importe fijo. En casos en que se consoliden las disputas y haya más de dos partes involucradas, el pago por adelantado de las tarifas se realizará de acuerdo con las reglas del proveedor de servicioservicios de resolución de disputas.

La parte que resulte favorecida en el proceso de resolución de disputas recibirá el reembolso del pago por adelantado, mientras que la otra parte lo perderá y deberá asumir el costo del proceso. En casos en que se consoliden las disputas y haya más de dos partes involucradas, el reembolso de las tarifas se realizará de acuerdo con las reglas del



proveedor de servicioservicios de resolución de disputas.

ICANN estima que las tarifas por adjudicación para un proceso que implique un importe fijo podríapodrían ir desde USD 2,000 a USD 8,000 (o más) por proceso. ICANN estima además que un proceso con tarifas por hora con un panel de un miembro puede ir de USD 32,000 a USD 56,000 (o más) y con un panel de tres miembros, puede ir de USD 70,000 a USD 122,000 (o más). Estas estimaciones pueden ser inferiores si el panel no reclama más escritos que la objeción y la respuesta, y no permite una vista. Consulte al proveedor adecuado para conocer los importes pertinentes o las estructuras de las tarifas. Consulte también la sección 3.3 del módulo 3 para conocer más detalles.

• Tarifa de evaluación (comparativa) con prioridad de la comunidad: en – En caso de que el postulante participe en una evaluación (comparativa) con prioridad de la comunidad, la tarifa correspondiente deberá abonarse mediante un depósito; su importe cubrirá el costo de la revisión de dicha solicitud por parte del panel (en este momento ronda los USD 10,000). El depósito se aplicará al proveedor designado para encargarse de las evaluaciones (comparativas) con prioridad de la comunidad. Los postulantes serán notificados si deben abonar tal tarifa. Consulte la sección 4.2 del módulo 4 para conocer las instanciascircunstancias en las que puede llevarse a cabo una evaluación (comparativa) con prioridad de la comunidad. Si un postulante puntúa en el umbral de la puntuación de la evaluación (comparativa) con prioridad de la comunidad, o por encima de este, se le reembolsará el depósito.

ICANN notificará a los postulantes las fechas de vencimiento del pago de tarifas adicionales (si procede). Esta lista no incluye las tarifas (tarifas de registro anuales) que deberán abonarse a ICANN después de celebrar un acuerdo de registro.



1.5.3 Métodos de pago

Los pagos a ICANN deben realizarse mediante transferencias. En el TAS,8, se incluirán las instrucciones para realizar pagos mediante transferencias.

Los pagos a los proveedores de servicios de resolución de disputas deberán abonarse de acuerdo con las instrucciones del proveedor.

1.5.4 Solicitud de factura

La interfaz del TAS permite al postulante solicitar la emisión de una factura para cada una de las tarifas que se deben abonar a ICANN. Se ofrece este servicio para los postulantes que requieren una factura para procesar los pagos.

1.6 Preguntas sobre esta Guía del postulante Para recibir asistencia y realizar preguntas al completar el formulario de solicitud, los postulantes tendrán a disposición un foro de preguntas y respuestas, que funcionará durante todo el período de presentación de solicitudes.deberán utilizar los recursos de soporte disponibles por medio del TAS. Se recomienda que los postulantes que no comprendan con exactitud a qué información apunta una pregunta o cuáles son los parámetros de la documentación aceptable comuniquen estas dudas a través le los canales de soporte apropiados antes de presentar la solicitud para. Esto ayuda a evitar el intercambio con examinadores para aclarar información, lo que prolonga el plazo asociado con la solicitud.

Las preguntas se pueden enviarenviarse a [dirección de correo electrónico que se insertará en la versión final de la Guíatravés del postulante].vínculo de soporte del TAS. Para que todos los postulantes puedan acceder equitativamente a la información, ICANN publicará todas las preguntas y respuestas en la página de soporte del TAS y también en una ubicación centralizada de su sitio web público.

Todos los pedidos de información a ICANN acerca del proceso o los aspectos relativos a la preparación de una

8 La transferencia es el método de pago preferido ya que ofrece un medio accesible y confiable a nivel mundial para las transferencias internacionales de fondos. Este método permite a ICANN recibir la tarifa y comenzar a procesar las solicitudes lo antes posible.



solicitud, deben enviarse por escrito a la dirección de email designada.través de los canales de soporte designados. ICANN no responderá los pedidos de los postulantes por consultas personales o telefónicas con respecto a la preparación de una solicitud. Los postulantes que se comuniquen con ICANN para aclarar aspectos de la solicitud, serán remitidos al área exclusiva para preguntas y respuestas en línea.

Las respuestas a las consultas sólo servirán para aclarar los formularios y los procesos relacionados con la solicitud. ICANN no ofrece asesoramiento financiero, legal ni consultoría.

Se cierra el período de solicitudes

BORRADOR - Programa de gTLD nuevos - Proceso de evaluación

Se abre el período de presentaciónde objeciones

Solicitudes publicadas para

comentarios públicos

Se abre el período de solicitudes

El período para comentarios públicos se abrirá durante un

plazo de 45 días

Revisión de las solicitudes

Estabilidad del DNS

Similitud de cadenas

Nombres geográficos

Capacidad financiera

Capacidad técnica y operativa

Servicios de registro

No reúne los requisitos para una

nueva revisión

¿Se aprobó la comprobación administrativa?

Sí

No

BORRADOR – Para discusión - Ago. 09 – V1.82

A

Verificación de

antecedentes

Solicitud ‐ Módulo 1

Evaluación inicial ‐ Módulo 2

Extensión de la evaluación ‐ Módulo 2

Resolución de disputas ‐ Módulo 3

Disputa por cadenas ‐ Módulo 4

Transición hacia la delegación ‐Módulo 5

Línea más

gruesa

Indica la vía más rápida hacia la delegación

Leyenda

ICANN procurará publicar los resultados de la revisión de la similitud de cadenas, incluidos los conjuntos en

disputa, antes de la publicación de los resultados

completos de la IE

Estas tres partes de la evaluación inicial (IE) se

denominan revisión de la cadena

Estas tres partes de la evaluación inicial (IE) se denominan revisión del

postulante

No reúne los requisitos para una

nueva revisión

¿Hay alguna objeción?

¿Aprueba el postulante todos los

elementos de la extensión de la evaluación?

¿Hay alguna disputa por cadenas?

¿Algún postulante comunitario eligió prioridad

de la comunidad?

El postulante con éxito garantiza la

cadena

¿Hay un ganador claro?

No

No

BORRADOR – Para discusión - Ago. 09 – V1.82

Delegación

¿Aclara el postulante todas las objeciones?

Sí

No

No Sí

Resultados de la IE publicados

El postulante opta por seguir con la

extensión de la valuación (EE)

No

No

Sí

El período de presentación de objeciones

cierra dos semanas después de la publicación de los resultados de la IE

No

¿Logran los postulantes con

cadenas en disputa resolver ellos mismos la

disputa?

Sí

No SíSí

¿Aprueba el postulante todos los

elementos de la evaluación inicial?

Sí

Procedimientos por confusión de cadenas

Procedimientos por derechos

legales

Procedimientos por objeción de la comunidad

Procedimientos por moralidad y orden público

El postulante entra en la EE para una combinación de los cuatro elementos siguientes:· Técnico y operativo· Financiero· Nombres geográficos· Servicios de registro

Evaluación con prioridad

de la comunidad

Procedimientos de subasta

Ejecución del contrato

Comprobación anterior a la delegación

A BORRADOR - Programa de gTLD nuevos -Proceso de evaluación, página 2

No

Sí

La extensión de la evaluación y la resolución de

disputas se realizarán al mismo tiempo

Se puede objetar la solicitud teniendo como base

cualquier combinación de los cuatro motivos de objeción a la vez. Además, la solicitud

puede recibir varias objeciones por el mismo

motivo

Borrador de la Guía del solicitante, v4€¦ · Corporación para la Asignación de Números y...

Documents

Transcript of Borrador de la Guía del solicitante, v4€¦ · Corporación para la Asignación de Números y...