Procedimiento para solicitudes de cambios a los gTLD comunitarios
Tenga presente que la versión oficial de todos los contenidos y documentos traducidos es la versión en idioma inglés; las traducciones a otros idiomas son solo a título informativo.
Introducción
El procedimiento para las solicitudes de cambios a los gTLD comunitarios fue desarrollado por el Grupo de Trabajo para el Proceso de Solicitudes de Cambios a los gTLD Comunitarios (grupo de trabajo) y la organización de la ICANN con aportes del Grupo de Partes Interesadas de Registros y la comunidad de la ICANN. Los principios rectores de este procedimiento permiten que un operador de registro de gTLD solicite modificaciones a la Especificación 12 sin que se desestimen las políticas de registración para la comunidad, lo cual ampliaría o acotaría de manera excesiva la elegibilidad de los registratarios o los requisitos para la selección de nombres, o bien traería aparejado un impacto significativamente negativo para la comunidad usuaria del gTLD.
La organización de la ICANN publicó un procedimiento preliminar para comentario público en febrero de 2018. Una vez considerados los comentarios recibidos, la organización de la ICANN y el grupo de trabajo concluyeron que los comentarios no indicaban que el procedimiento está en conflicto con la política existente y analizaron actualizaciones al procedimiento. Además, el 26 de abril de 2018, el Consejo de la GNSO acordó [PDF, 574 KB] que "la organización de la ICANN debería continuar tratando el proceso de solicitud de cambios a los gTLD comunitarios como una cuestión de implementación". Esta versión publicada del Procedimiento fue acordada por el grupo de trabajo y la organización de la ICANN en abril de 2018.
Procedimiento
Versión: Abril de 2018
Solicitud de cambios a los gTLD comunitarios
La solicitud de cambios a los gTLD comunitarios (la "Solicitud") es el procedimiento por el cual un operador de registro de gTLD comunitarios busca la aprobación de la ICANN para modificar las políticas de registración de la comunidad enumeradas en la Especificación 12 a su Acuerdo de Registro. En virtud de la sección 2.19 de los Acuerdos de Registro de gTLD Comunitarios, "el Operador de Registro operará el TLD de forma que permita a su comunidad debatir y participar en el desarrollo y modificación de las políticas y prácticas de dicho TLD". El Operador de Registro de un gTLD comunitario no puede solicitar cambios que desestimen las políticas de registración de la comunidad, lo cual ampliaría o acotaría de manera excesiva la elegibilidad de los registratarios o los requisitos para la selección de nombres, o bien traería aparejado un impacto significativamente negativo a la comunidad usuaria del gTLD.
Como sucede en todos los procedimientos de la ICANN, la ICANN puede revisar la eficacia de este procedimiento de manera periódica con aportes de los operadores de registro y las unidades constitutivas relevantes.
1. Definiciones
1.1 Un gTLD comunitario se define como un gTLD que tiene u Acuerdo de Registro con la ICANN que incluye la Especificación 12 con el título de sección "Políticas de registración de la comunidad" o "Políticas de TLD".
1.2 Un cambio al gTLD comunitario se define como un cambio a la Especificación 12 del Acuerdo de Registro con la ICANN.
1.3 La comunidad de TLD se define por los requisitos de elegibilidad descriptos en la Especificación 12 del Acuerdo de Registro con la ICANN.
1.4 El Operador de Registro se define como una entidad con un Acuerdo de Registro para administrar un gTLD comunitario.
1.5 Todas las referencias a días dentro de este procedimiento se definen como días calendario.
2. Procedimiento de solicitud de cambios a los gTLD comunitarios
2.1 El Operador de Registro presenta una Solicitud de Cambios a los gTLD Comunitarios (la "Solicitud")
El Operador de Registro puede presentar una Solicitud en cualquier momento. La Solicitud será presentada por escrito a la ICANN acompañada de un Cuestionario sobre Solicitud de Cambios a los gTLD Comunitarios (véase Anexo A) [PDF, 38 KB] completo y debe incluir documentación que respalde el cambio por la comunidad de TLD (incluidas entidades que representan toda extensión propuesta de la comunidad de TLD, si corresponde), así como por los organismos rectores representativos, si corresponde.
2.2 Revisión preliminar de la solicitud por parte de la ICANN
Una vez recibida una Solicitud, la ICANN comprobará su integridad y notificará al Operador de Registro por escrito de cualquier deficiencia dentro de los 5 días. El Operador de Registro puede volver a enviar una Solicitud revisada a la ICANN en cualquier momento para que vuelva a ser tratada. Siempre y cuando se hayan abordado todos los puntos del cuestionario y se hayan entregado los documentos de respaldo, la Solicitud será considerada completa.
Después de la prueba de exhaustividad, la ICANN realizará una revisión preliminar y preparará la Solicitud y la enmienda preliminar para el período de comentario dentro de los 10 días. Si durante la revisión preliminar la ICANN determina que la Solicitud no está dentro del alcance de este procedimiento o señala inquietudes que probablemente resulten en el rechazo de la Solicitud, la ICANN puede identificar estas inquietudes e iniciar u período de consulta con el Operador de Registro antes del período de comentario.
2.3 Período de comentario de la Solicitud de Cambios
Con posterioridad a la revisión preliminar de la Solicitud por parte de la ICANN, la ICANN publicará la Solicitud y una enmienda preliminar durante un período de comentario de 30 días.
2.4 Período de respuesta del Operador de Registro
Si se plantean preguntas sobre la Solicitud durante el período de comentario, la ICANN iniciará un período de consulta con el Operador de Registro y solicitará su respuesta a los comentarios recibidos dentro de los 15 días posteriores a la solicitud de la ICANN. Durante este período, la ICANN también puede consultar al Operador de Registro para que aclare los comentarios que pueden afectar negativamente la aprobación de la Solicitud o que responda directamente a los comentarios recibidos, en caso de ser necesario.
3. Revisión y determinación de la ICANN
3.1 Revisión de la ICANN
La ICANN analizará si la Solicitud debe ser aprobada o rechazada, y su evaluación se basará en los siguientes criterios:
- Descripción de la comunidad usuaria del TLD – ¿Hay una descripción clara de los requisitos de elegibilidad del TLD y cómo se ven afectados por la solicitud?
- Evidencia de difusión y apoyo de la comunidad usuaria de TLD – ¿Hay evidencia razonable de la difusión a la comunidad de TLD que muestre los esfuerzos del RO para "operar el TLD de manera que permita que la comunidad del TLD debata y participe en el desarrollo y la modificación de políticas y prácticas del TLD?" ¿Hay evidencia razonable de apoyo a la Solicitud por parte de la comunidad usuaria del TLD?
- Beneficios a la comunidad del TLD – ¿Las respuestas suministradas en 1.3 y 1.4 del Cuestionario sobre Solicitud de Cambios explican adecuadamente de qué manera la Solicitud beneficiaría a la comunidad usuaria del TLD? ¿La aprobación del cambio sería en detrimento de la comunidad usuaria del TLD?
- Inquietudes planteadas durante el período de comentario – ¿Se plantearon inquietudes significativas durante el período de comentario que identificaron perjuicios a la comunidad del TLD o la comunidad de Internet? ¿El Operador de Registro proporcionó una respuesta adecuada a estas inquietudes? Una respuesta adecuada puede incluir evidencia respaldatoria del Operador de Registro respecto de que (1) no habrá daño en la reputación de la comunidad; (2) no hay interferencia con las actividades principales de la comunidad; o (3) no hay perjuicio económico para la comunidad.
3.2 Determinación de la ICANN
3.2.1 Aprobación
Si la ICANN determina que se aprueba la Solicitud, la ICANN proporcionará la aprobación al Operador de Registro dentro del plazo objetivo de 30 días a partir del cierre del período de comentario o a partir de la respuesta del Operador de Registro a las inquietudes planteadas durante el período de comentario. Si se produjese una demora, la ICANN brindará una explicación y una indicación por escrito del nuevo plazo.
Junto con la aprobación, la ICANN suministrará una enmienda para su ejecución. De ser necesario, la ICANN puede modificar la enmienda según sea pertinente para implementar la Solicitud aprobada y se la suministrará al Operador de Registro para su revisión antes de su ejecución.
3.2.2 Rechazo
Si la ICANN determina que se rechaza la Solicitud, la ICANN notificará al Operador de Registro de su rechazo de la Solicitud de Cambio e indicará claramente su fundamento para rechazar la Solicitud dentro de un plazo objetivo de 30 días a partir del cierre del período de comentario o a partir de la respuesta del Operador de Registro a las inquietudes planteadas durante el período de comentario. Si se produjese una demora, la ICANN brindará una explicación y una indicación por escrito del nuevo plazo.
ANEXO A: Cuestionario sobre Solicitud de Cambio a los gTLD Comunitarios [PDF, 38 KB]