Skip to main content
Resources

POLITICA DE TRANSFERENCIA

  1. Política Entre Registradores

    1. Transferencias Autorizadas por el Titular

      1. Requisitos del Registrador

        Los Titulares de Nombres Registrados deben poder transferir sus registros de nombres de dominio entre Registradores siempre y cuando el proceso de transferencia del Registrador Receptor cumpla con los estándares mínimos dispuestos en la presente política y que dicha transferencia no esté prohibida por la ICANN o las políticas del Registro. Los procesos de transferencia de nombres de dominio entre registradores deben ser claros y concisos a fin de evitar confusiones. Además, los Registradores deben realizar esfuerzos razonables para informar a los Titulares de Nombres Registrados acerca de la documentación publicada sobre el proceso específico de transferencia empleado por los Registradores y proporcionar acceso a la misma.

        1.1 Autoridades de Transferencia

        El Contacto Administrativo y el Titular del Nombre Registrado, tal como se enumeran en el servicio de Whois de acceso público del Registrador que autoriza la transferencia o del Registro (si corresponde), son las únicas partes que tienen la autoridad para aprobar o denegar una solicitud de transferencia al Registrador Receptor. En el caso de conflicto, la autoridad del Titular del Nombre Registrado prevalece sobre la del Contacto Administrativo.

        Los registradores pueden utilizar los datos del Whois del Registrador Emisor o del Registro pertinente con el fin de verificar la autenticidad de una solicitud de transferencia; o los provenientes de otra fuente de datos tal como lo determina una política de consenso.

      2. Requisitos del Registrador Receptor:

        Para cada instancia en la que un Titular de Nombre Registrado solicite transferir una registración de nombre de dominio a un Registrador diferente, el Registrador Receptor deberá:

        2.1 Obtener autorización expresa del Titular del Nombre Registrado o del Contacto Administrativo (en adelante, "Contacto de Transferencia"). Por lo tanto, una transferencia sólo puede proceder si la confirmación de la transferencia es recibida por el Registrador Receptor del Contacto de Transferencia.

        2.1.1. La autorización debe otorgarse mediante un Formulario de Autorización (FOA) Estandarizado válido. Existen dos FOA diferentes disponibles en el sitio web de la ICANN. El FOA denominado "Autorización Inicial de Transferencia del Registrador" debe ser utilizado por el Registrador Receptor para solicitar la autorización de una transferencia para el Registrador del Contacto de Transferencia. El FOA denominado "Solicitud de Confirmación de Transferencia de Registrador" debe ser utilizado por el Registrador Emisor para solicitar la confirmación de la transferencia del Contacto de Transferencia.

        El FOA será comunicado en inglés, y cualquier controversia derivada de una solicitud de transferencia será abordada en idioma inglés. Los registradores pueden optar por comunicarse con el Contacto de Transferencia en otros idiomas. No obstante, los registradores que opten por ejercer dicha opción son responsables de la exactitud e integridad de la traducción del FOA en una versión distinta del idioma inglés.

        2.1.2 En el caso de que el Registrador Receptor dependa de un proceso físico para obtener esta autorización, bastará una copia en papel del FOA, siempre y cuando haya sido firmada por el Contacto de Transferencia y, además, esté acompañada de una copia impresa del resultado del Whois del Registrador Emisor para el nombre de dominio en cuestión.

        2.1.2.1 Si el Registrador Receptor depende de un proceso de autorización físico, entonces el Registrador Receptor asume la responsabilidad de generar pruebas confiables de la identidad del Contacto de Transferencia y de mantener los registros apropiados probando la obtención de dicha evidencia. Además, el Registrador Receptor también asume la responsabilidad de garantizar que la entidad que emite la solicitud esté realmente autorizada para hacerlo. Los medios aceptables para comprobar la identidad con medios físicos son:

        1. Declaración notariada
        2. Licencia de conducir válida
        3. Pasaporte
        4. Actas Constitutivas
        5. Identificación militar
        6. Identificación emitida por el estado / gobierno
        7. Certificado de nacimiento

        2.1.3.1 En el caso de que el Registrador Receptor dependa de un proceso electrónico para obtener esta autorización, los medios aceptables para comprobar la identidad incluirían:

        1. Firma electrónica de conformidad con la legislación nacional, en el lugar del Registrador Receptor (si existe tal legislación).
        2. Consentimiento de una persona o entidad que tenga una dirección de correo electrónico que corresponda a la dirección de correo electrónico del Contacto de Transferencia.

        2.1.3.2 El Registrador Emisor no podrá denegar una solicitud de transferencia únicamente porque crea que el Registrador Receptor no ha recibido la confirmación dispuesta anteriormente.

        2.1.3.3 No se debe permitir que una transferencia proceda si no se recibe la confirmación por parte del Registrador Receptor. La presunción en todos los casos será que el Registrador Receptor ha recibido y autenticado la solicitud de transferencia efectuada por un Contacto de Transferencia.

        2.2 Solicitud, mediante la transmisión de una orden de "transferencia", tal como se especifica en el Conjunto de Herramientas para el Registrador, de que la base de datos del Operador de Registro sea modificada a fin de incorporar al nuevo Registrador.

        2.2.1 La transmisión de una orden de "transferencia" constituye una garantía por parte del Registrador Receptor de que se ha obtenido la autorización requerida del Contacto de Transferencia enumerado en la base de datos del Whois autorizada.

        2.2.2 El Registrador Receptor es responsable de validar las solicitudes del Titular del Nombre Registrado para transferir nombres de dominio entre Registradores. Sin embargo, el Registrador Emisor deberá aún confirmar, de forma independiente, la intención del Titular del Nombre Registrado de transferir su nombre de dominio al Registrador Receptor, según lo dispuesto en la Sección I.A.3 ("Obligaciones del Registrador Emisor") de esta política.

        2.2.3. El FOA denominado "Autorización inicial de Transferencia de Registrador" caducará en las siguientes circunstancias:

        2.2.3.1 Ha transcurrido un período de sesenta (60) días desde que el FOA fue emitido por el Registrador Receptor, a menos que el Registrador Receptor permita la renovación automática del FOA y el Titular del Nombre Registrado haya optado expresamente por la renovación automática;

        2.2.3.2. El nombre de dominio expira antes de que se complete la transferencia entre registradores;

        2.2.3.3 Se finaliza un Cambio de Registratario según lo estipulado en la Sección II.C.

        2.2.3.4. Se completa la transferencia entre registradores.

        2.2.4 Si el FOA expira en una de las circunstancias antes mencionadas descritas en IA2.2.3.1 - IA2.2.3.4, antes de presentar la solicitud de "transferencia" al registro, para proceder a la transferencia, el Registrador Receptor deberá volver a autorizar la solicitud de transferencia a través de un nuevo FOA.

      3. Obligaciones del Registrador Emisor

        3.1 Un Registrador Emisor confirmará la intención del Titular del Nombre Registrado cuando se reciba una notificación de transferencia pendiente del Registro notificando al Titular del Nombre Registrado de la transferencia. El Registrador Emisor debe hacerlo en consonancia con las normas establecidas en esta política.

        3.2 A fin de garantizar que la forma de la solicitud empleada por el Registrador Emisor sea sustancialmente de carácter administrativo e informativo y claramente proporcionada al Contacto de Transferencia con el propósito de verificar la intención del Contacto de Transferencia, el Registrador Emisor debe utilizar el FOA.

        3.3. El FOA será comunicado en inglés, y cualquier controversia derivada de una solicitud de transferencia se abordará en idioma inglés. Los registradores pueden optar por comunicarse con el Contacto de Transferencia en otros idiomas. No obstante, el Registrador que opte por ejercer dicha opción será responsables de la exactitud e integridad de la traducción del FOA en una versión distinta del idioma inglés. Además, tales comunicaciones en inglés deben seguir los procesos y procedimientos establecidos en esta política. Esto incluye, aunque no taxativamente, el requisito de que ningún Registrador agregará información adicional al FOA utilizado para obtener el consentimiento del Contacto de Transferencia en el caso de una solicitud de transferencia.

        En el caso de que el Titular del Nombre Registrado pre apruebe una transferencia, el Registrador Emisor tiene la opción de enviar una versión modificada del FOA, la cual informa al Titular del Nombre Registrado que se ha iniciado la transferencia pre aprobada.

        Este requisito no impide que el Registrador Emisor lo comercialice entre sus clientes existentes mediante comunicaciones separadas.

        3.4 El FOA "debe ser enviado por el Registrador Emisor al Contacto de Transferencia tan pronto como sea operativamente posible, pero a más tardar veinticuatro (24) horas luego de haber recibido la solicitud de transferencia del Operador de Registro.

        3.5 Si el Registrador Emisor no responde dentro de los 5 (cinco) días calendario a la notificación de solicitud de transferencia enviada por el Registro, la transferencia se considerará "aprobada por defecto".

        3.6 En el caso de que un Contacto de Transferencia incluido en el Whois no haya confirmado su solicitud de transferencia con el Registrador Emisor y el Registrador Emisor no haya rechazado explícitamente la solicitud de transferencia, la acción por defecto será que el Registrador Emisor debe dar lugar a que proceda la transferencia.

        3.7 Al denegar una solicitud de transferencia debido a cualquiera de las siguientes razones, el Registrador Emisor debe proporcionar al Titular del Nombre Registrado y al posible Registrador Receptor el motivo de la denegación. El Registrador Emisor podrá denegar una solicitud de transferencia solamente en los siguientes casos específicos:

        3.7.1 Evidencia de fraude

        3.7.2 Una controversia razonable en relación a la identidad del Titular del Nombre Registrado o Contacto Administrativo

        3.7.3 Falta de pago por el período de registración anterior (incluidos los cargos por devolución de la tarjeta de crédito) si el nombre de dominio ha excedido su fecha de vencimiento o si el nombre de dominio aún no ha expirado. En todos estos casos, no obstante, el Registrador Emisor debe colocar el nombre de dominio en estado de "Bloqueo del Registrador" antes de la denegación de la transferencia.

        3.7.4 Expresa objeción a la transferencia por parte del Contacto de Transferencia autorizado. La objeción puede adoptar la forma de una solicitud específica (ya sea impresa o por medio electrónico) por parte del Contacto de Transferencia autorizado para denegar una solicitud de transferencia en particular o una objeción general a todas las solicitudes de transferencia recibidas por el Registrador, en forma temporal o indefinida. En todos los casos, la objeción se deberá presentar con el consentimiento expreso e informado del Contacto de Transferencia sobre una cláusula de inclusión y, a solicitud del Contacto de Transferencia autorizado, el Registrador debe eliminar el bloqueo u ofrecer un método accesible para que el Contacto de Transferencia autorizado elimine el bloqueo en un plazo de cinco (5) días calendario.

        3.7.5 La transferencia fue solicitada dentro de los 60 días siguientes a la fecha de creación, como se muestra en el registro del Whois del registro para el nombre de dominio.

        3.7.6 Un nombre de dominio se encuentra dentro de los 60 días (o un período menor a ser determinado) después de ser transferido (aparte de ser transferido de nuevo al Registrador original en los casos en que tanto los Registradores así lo acuerden y / o cuando así lo disponga un fallo en el proceso de resolución de disputas). "Transferido" significa únicamente que se ha producido una transferencia entre registradores de acuerdo con los procedimientos de esta política.

        3.8 El Registrador Emisor debe denegar una solicitud de transferencia en las siguientes circunstancias:

        3.8.1 La existencia de un procedimiento de UDRP pendiente informado al Registrador.

        3.8.2. Recepción de orden judicial de tribunal con jurisdicción competente.

        3.8.3 Disputa pendiente relacionada con una transferencia anterior de conformidad con la Política de Resolución de Disputas relacionadas con Transferencias.

        3.8.4 El Registrador impuso un bloqueo de transferencia entre registradores de 60 días tras un Cambio de Registratario de acuerdo con los procedimientos de esta política.

        3.8.5 El Registrador impuso un bloqueo de transferencia entre registradores de 60 días tras un Cambio de Registratario, y el Titular del Nombre Registrado no optó por la exclusión del bloqueo de transferencia entre registradores de 60 días previo a la solicitud de Cambio de Registratario .

        3.9 Las instancias en las que el cambio solicitado del Registrador no puede ser denegado incluyen, aunque no taxativamente:

        3.9.1 Falta de pago por un período de registración pendiente o futuro.

        3.9.2 No hay respuesta del Titular del nombre Registrado o del Contacto Administrativo.

        3.9.3 Nombre de dominio en estado de Bloqueo del Registrador, a menos que el Titular del Nombre Registrado tenga ocasión razonable y la facultad de desbloquear el nombre de dominio antes de la Solicitud de Transferencia.

        3.9.4 Limitaciones de tiempo del período de registración de nombres de dominio, excepto durante los primeros 60 días de la registración inicial, durante los primeros 60 días después de la transferencia del registrador, o durante el bloqueo de 60 días posteriores a un Cambio de Registratario, tal como lo dispone la Sección II. C.2.

        3.9.5 Incumplimiento de pago general entre el registrador y sus socios de negocios o filiales, en los casos en que el Titular del Nombre Registrado en cuestión hubiese pagado la registración.

        3.10 El Registrador Emisor tiene otros mecanismos disponibles para cobrar el pago del Titular del Nombre Registrado que es independiente del proceso de Transferencia. Por lo tanto, en el caso de una disputa en relación al pago, el Registrador Emisor no debe emplear los procesos de transferencia como un mecanismo para garantizar el pago de servicios de un Titular de Nombre Registrado. Las excepciones a este requisito son las siguientes:

        3.10.1 En caso de falta de pago por parte del ( de los) período (s) de registración anterior (es) si la transferencia se solicita después de la fecha de vencimiento, o

        3.10.2 En caso de falta de pago del período de registración vigente, si la transferencia se solicita antes de la fecha de vencimiento.

      4. Coordinación del Registrador

        4.1 Cada Registrador es responsable de mantener copias de la documentación, incluido el FOA y la Respuesta de los Contactos de Transferencia, que puede ser requerida para interponer y justificar una disputa según la política de resolución de disputas. Los Registradores Receptores deben mantener copias del FOA, tal como se reciben del Contacto de Transferencia, según las políticas de conservación de documentos estándares de los contratos. Se deben conservar copias de la evidencia confiable de la identidad junto con el FOA.

        4.2 Tanto el Registrador Receptor como el Registrador Emisor deben proporcionar la evidencia en la que se basaron para la transferencia durante las transacciones de nombres de dominio entre los registradores correspondientes y después de las mismas. Dicha información se deberá proporcionar cuando así lo solicite únicamente el otro Registrador que sea parte en la transacción de transferencia. Además, la ICANN, el Operador de Registro, un tribunal o autoridad con jurisdicción sobre el asunto o un panel de resolución de disputas externo podrá requerir dicha información dentro de los cinco (5) días de presentada la solicitud.

        4.3 El Registrador Receptor debe conservar y emitir, de acuerdo con una solicitud por parte del Registro que autoriza la transferencia, una copia escrita o electrónica del FOA. En los casos en que el Registrador Emisor haya solicitado copias del FOA, el Registrador Receptor deberá cumplir con la solicitud del Registrador Emisor (incluida la presentación de la documentación respaldatoria) en un plazo de cinco (5) días calendario. No proporcionar esta documentación dentro del plazo especificado es motivo de revocación por parte del Operador de Registro o del Panel de Resolución de Disputas en caso de que se presente un reclamo relacionado con la transferencia de acuerdo con los requisitos de esta política.

        4.4 Si un Registrador Emisor o un Registrador Receptor cree que una solicitud de transferencia no fue gestionada según las disposiciones de la presente política, entonces el Registrador puede iniciar un procedimiento de resolución de disputas como se establece en la Sección I.C de esta política.

        4.5 Con el objeto de facilitar las solicitudes de transferencia, los Registradores deben proporcionar y mantener una dirección de correo electrónico única y privada para uso exclusivo de otros Registradores y con el Registro:

        4.5.1 Esta dirección de correo electrónico es para asuntos relacionados con solicitudes de transferencia y los procedimientos establecidos en esta política únicamente.

        4.5.2 La dirección de correo electrónico debe ser administrada a fin de garantizar que los mensajes sean recibidos por alguien que pueda responder en relación al tema de la transferencia.

        4.5.3 Los mensajes recibidos en dicha dirección de correo electrónico deben ser respondidos dentro de un plazo comercial razonable que no exceda los siete (7) días calendario.

        4.6 Contacto de Emergencia para Comunicaciones Urgentes sobre Transferencias

        4.6.1 Los Registradores establecerán un Contacto de Emergencia para Comunicaciones Urgentes sobre Transferencias ("TEAC") para las comunicaciones urgentes relacionadas con las transferencias. El objetivo del TEAC es establecer rápidamente una conversación en tiempo real entre los registradores (en un idioma que ambas partes puedan comprender) en caso de una emergencia. Posteriormente, se pueden adoptar otras medidas para lograr una resolución, incluida la iniciación de procesos de resolución de disputas o la anulación de una transferencia existente (o futura).

        4.6.2 Las comunicaciones con los TEAC se reservarán para el uso de los Registradores Acreditados por la ICANN, los Operadores de Registro de gTLD y el Personal de la ICANN. El punto de contacto del TEAC puede ser designado como número de teléfono u otro canal de comunicación en tiempo real y será registrado en el portal de registradores de la ICANN y mantenido de forma confidencial. Las comunicaciones con un TEAC deben iniciarse de manera oportuna, dentro de un plazo razonable después de la supuesta pérdida no autorizada de un dominio.

        4.6.3 Los mensajes enviados a través del canal de comunicación del TEAC deben generar una respuesta no automatizada por parte de un representante humano del Registrador Receptor. La persona o el equipo que responda debe ser capaz de investigar y abordar asuntos de transferencia urgentes y estar autorizado para hacerlo. Las respuestas se deben brindar dentro de las 4 horas de presentada la solicitud inicial, aunque la resolución final del incidente puede tomar más tiempo.

        4.6.4 El Registro que autoriza la transferencia informará la falta de respuesta a una comunicación con un TEAC al Departamento de Cumplimiento de la ICANN y al Operador de Registro. La falta de respuesta a una comunicación con un TEAC puede resultar en una cancelación de la transferencia de acuerdo con la Sección I.A.6.4 de esta política y también puede derivar en otras acciones por parte de la ICANN, que podría incluir hasta la no renovación o la rescisión de la acreditación.

        4.6.5 Ambas partes mantendrán la correspondencia escrita o electrónica de toda comunicación y respuestas del TEAC y compartirán copias de esta documentación con la ICANN y con el operador del registro cuando lo soliciten. Esta documentación se conservará de acuerdo con la Sección 3.4 del Acuerdo de Acreditación de Registradores (RAA). Los usuarios del canal de comunicación del TEAC deben informar a la ICANN sobre los Registradores que no respondan. Además, la ICANN puede realizar pruebas periódicas del canal de comunicación del TEAC del Registrador en situaciones y de la manera que se considere apropiada para asegurar que los registradores respondan a los mensajes del TEAC.

      5. Requisitos para el estado "ClientTransferProhibited" (Transferencia de Cliente Prohibida) y los códigos "AuthInfo"

        5.1 Con sujeción a las especificaciones o políticas de la ICANN y a toda ley o reglamento que se aplique, los Registradores deben cumplir con los requisitos establecidos a continuación.

        Los Registradores sólo pueden colocar un nombre de dominio en el estado "ClientTransferProhibited" al registrarse o solicitarlo posteriormente el Titular del Nombre Registrado, siempre y cuando el Registrador incluya en su acuerdo de registración (con el consentimiento expreso del Titular del Nombre Registrado) los términos y condiciones sobre los cuales prohíbe la transferencia del nombre de dominio. Además, el Registrador debe eliminar el estado "ClientTransferProhibited" dentro de los cinco (5) días calendario de presentada la solicitud inicial del Titular del Nombre Registrado si el Registrador no brinda los medios para que el Titular del Nombre Registrado elimine el estado "ClientTransferProhibited".

        5.2 Los registradores deben proporcionar al Titular del Nombre Registrado el código único "AuthInfo" y eliminar el estado "ClientTransferProhibited" dentro de los cinco (5) días calendario de presentada la solicitud inicial del Titular del Nombre Registrado si el Registrador no proporciona los medios para que el Titular del Nombre Registrado genere y gestione su propio código "AuthInfo" único y elimine el estado "ClientTransferProhibited".

        5.3 Los Registradores no podrán utilizar ningún mecanismo para cumplir con la petición de un Titular de Nombre Registrado de eliminar el estado "ClientTransferProhibited" u obtener el código "AuthInfo" correspondiente que sea más restrictivo que los mecanismos utilizados para cambiar cualquier aspecto de la información de contacto del Titular del Nombre Registrado o la información del servidor de nombres.

        5.4 El Registrador Emisor no debe negarse a eliminar el estado "ClientTransferProhibited" o liberar un Código "AuthInfo" al Titular del Nombre Registrado únicamente porque existe una disputa entre el Titular del Nombre Registrado y el Registrador con respecto al pago.

        5.5 Los códigos "AuthInfo" generados por el Registrador deben ser únicos por dominio.

        5.6 Los códigos "AuthInfo" deben usarse únicamente para identificar a un Titular de Nombre Registrado, en tanto que sigue siendo necesario utilizar los FOA para la autorización o confirmación de una solicitud de transferencia, tal como se describe en la Sección I.A.2 y en la Sección I.A.4 de esta política.

      6. Requisitos del Registro

        6.1 Una vez recibida la orden de "transferencia" del Registrador Receptor, el Operador de Registro transmitirá una notificación electrónica a ambos Registradores. En el caso de aquellos Registros que utilizan notificaciones por correo electrónico, la notificación de respuesta puede ser enviada a la dirección de correo electrónico única establecida por cada Registrador con el propósito de facilitar las transferencias.

        6.2 El Operador de Registro completará la transferencia solicitada a menos que, dentro de los cinco (5) días calendario, el Operador de Registro reciba una orden de protocolo NACK del Registrador Emisor.

        6.3 Cuando la base de datos del Registro se hubiese actualizado para reflejar el cambio al nuevo Registrador Receptor, el Operador de Registro remitirá una notificación electrónica a ambos Registradores. La notificación se puede enviar a la dirección de correo electrónico única establecida por cada Registrador con el fin de facilitar las transferencias o a cualquier otra dirección de correo electrónico acordada por las partes.

        6.4 El Operador de Registro podrá dejar sin efecto una transferencia si, después de ocurrir la transferencia, el Operador de Registro recibe una de las notificaciones detalladas a continuación. En tal caso, la transferencia se revertirá y el campo del Registrador Emisor se restablecerá a su estado original. El Operador de Registro debe anular la transferencia dentro de los cinco (5) días calendario luego de haber recibido la notificación, excepto en el caso de una decisión sobre una disputa del Registro, en cuyo caso el Operador de Registro debe anular la transferencia dentro de los catorce días calendario a menos que se interponga una acción judicial. La notificación requerida será una de las siguientes:

        6.4.1 Acuerdo del Registrador Emisor y el Registrador Receptor enviado por correo electrónico, carta o fax donde se especifica que la transferencia fue realizada por error o no se efectuó de acuerdo con los procedimientos establecidos en esta política;

        6.4.2 El fallo definitivo de un organismo de resolución de disputas con competencia con respecto a la transferencia; o

        6.4.3 Orden de un tribunal competente con respecto a la transferencia;

        6.4.4 Documentación proporcionada por el Registrador Emisor antes de la transferencia que indica que el Registrador Receptor no ha respondido a un mensaje a través del TEAC dentro del plazo especificado en la Sección I.A.4.6.

      7. Registros de la Registración

        Cada Registrador exigirá que su cliente, el Titular del Nombre Registrado, mantenga sus propios registros adecuados para documentar y probar la fecha inicial de la registración del nombre de dominio.

      8. Efecto con respecto al Plazo de la Registración

        La finalización por parte del Operador de Registro de una transferencia autorizada por el titular en virtud de la Sección I.A dará lugar a una prórroga de un año de la registración existente, siempre que, en ningún caso, la duración total no vencida de una registración no exceda los diez (10) años.

    2. Transferencias Aprobadas por la ICANN

      1. 1 La transferencia del patrocinio de todos las registraciones patrocinadas por un Registrador como resultado de (i) la adquisición de dicho Registrador o sus activos por parte de otro Registrador, o (ii) la falta de acreditación de dicho Registrador o la falta de su autorización con el Operador de Registro, se puede realizar según el siguiente procedimiento:

        1.1 El Registrador Receptor debe estar acreditado por la ICANN para el TLD del Registro y debe tener implementado un Acuerdo Registro-Registrador con el Operador de Registro para el TLD del Registro.

        1.2 La ICANN deberá certificar por escrito al Operador de Registro que la transferencia promueve el interés de la comunidad, como por ejemplo el interés en la estabilidad que puede verse amenazada por una falla comercial real o inminente de un Registrador.

      2. 2 Una vez que se cumplan estas dos condiciones, el Operador de Registro realizará los cambios necesarios, por única vez, en la base de datos del Registro sin costo alguno, para transferencias que de 50.000 inscripciones o menos. Si la transferencia implica registraciones de más de 50.000 nombres, el Operador de Registro cobrará al Registrador Receptor una tarifa fija única de USD 50.000.

    3. Política de Resolución de Disputas Relacionadas con Transferencias

      Los procedimientos para gestionar disputas relativas a las transferencias entre registradores se establecen en la Política de Resolución de Disputas relacionadas con Transferencias. Los procedimientos de esta política deben ser cumplidos por los Operadores de Registro y los Registradores acreditados de la ICANN correspondientes.

  2. Transferencia entre Registratarios (Cambio de Registratario)

    1. DEFINICIONES:

      1. Esta política utiliza los siguientes términos:

        1.1 "Cambio de Registratario" significa un cambio sustancial a alguno de los siguientes datos:

        1.1.1 Nombre del Registratario Anterior

        1.1.2. Organización del Registratario Anterior

        1.1.3 Dirección de correo electrónico del Registratario Anterior

        1.1.4 Dirección de correo electrónico del Contacto administrativo, si no hay dirección de correo electrónico de Registratario Anterior

        1.2. "Agente Designado" significa un individuo o entidad que el Registratario Anterior o el Nuevo Registratario autoriza expresamente para aprobar un Cambio de Registratario en su nombre.

        1.3 "Cambio Sustancial" significa un cambio que no es una corrección tipográfica. Los siguientes serán considerados cambios sustanciales:

        1.3.1 Un cambio en el nombre u organización del Titular del Nombre Registrado que no parezca ser una simple corrección tipográfica;

        1.3.2. Todo cambio en el nombre u organización del Titular del Nombre Registrado que esté acompañado de un cambio de dirección o número telefónico;

        1.3.3 Todo cambio en la dirección de correo electrónico del Titular del Nombre Registrado.

        1.4 "Registratario Anterior" significa el Titular del Nombre Registrado en el momento en que se inicia un Cambio de Registratario.

        1.5 "Nuevo Registratario" significa la entidad o persona a quien el Registratario Anterior se propone transferir su registración del nombre de dominio.

    2. Disponibilidad del Cambio de Registratario

      1. En general, se debe permitir a los Registratarios actualizar sus datos de registración / Whois y transferir sus derechos de registración a otros Registratarios libremente.

      2. El Registrador debe denegar una solicitud de Cambio de Registratario en las siguientes circunstancias:

        2.1. El acuerdo de registración del nombre de dominio ha expirado, y el Titular del Nombre Registrado ya no tiene el derecho de renovar o transferir el nombre de dominio a otro registrador, tal como se establece en la Sección 2.2.5 de la Política de Recuperación de Registros Vencidos.

        2.2 El Cambio de Registratario no fue debidamente autorizado por el Registratario Anterior y el Nuevo Registratario, según lo establecido en la Sección II.C a continuación;

        2.3 El nombre de dominio es objeto de una disputa relacionada con un nombre de dominio, lo que incluye, aunque no taxativamente:

        2.3.1 La existencia de un procedimiento de UDRP pendiente informado al Registrador.

        2.3.2 La existencia de un procedimiento de URS pendiente informado al Registrador.

        2.3.3 Un procedimiento TDRP pendiente;

        2.3.4 Una orden judicial de un tribunal de jurisdicción competente, que prohíba un Cambio de Registratario, informada al Registrador.

      3. En las siguientes circunstancias, los datos de un Titular de un Nombre Registrado pueden ser cambiados por el Operador de Registro o Registrador y el proceso de Cambio de Registratario descrito en la Sección II.C a continuación no se aplica:

        3.1 caduca el acuerdo de registro;1

        3.2 el acuerdo de registración es rescindido por el registrador;

        3.3 el Registrador o Operador de Registro actualiza la información del Registratario Anterior de acuerdo con una orden judicial;

        3.4 el Registrador actualiza la información del Registratario Anterior en la implementación de una decisión en materia de UDRP;

        3.5 el Registrador actualiza la información del Registratario Anterior de acuerdo con la Política de Eliminación de Dominios Vencidos;

        3.6 el Registrador actualiza la información del Registratario Anterior en respuesta a un reclamo sobre uso indebido.

    3. Proceso para el Cambio de Registratario

      1. Para procesar un Cambio de Registratario del Registratario Anterior a un Nuevo Registratario, el Registrador debe realizar lo siguiente:

        1.1 Confirmar que el nombre de dominio es apto para el Cambio de Registratario de acuerdo con la Sección II.B;

        1.2 Obtener la confirmación de la solicitud de Cambio de Registratario por parte del Nuevo Registratario o de un agente designado del Nuevo Registratario. El Registrador debe utilizar un mecanismo seguro2 para confirmar que el Nuevo Registratario y / o sus respectivos Agentes Designados han consentido explícitamente el Cambio de Registratario. Al obtener la confirmación, el Registrador debe informar al Nuevo Registratario que debe firmar un acuerdo de registración con el Registrador (se puede brindar un enlace al propio acuerdo de registración); El Registrador también debe incluir instrucciones sobre cómo aprobar o cancelar el Cambio de Registratario e informar al Nuevo Registratario o Agente Designado, si corresponde, que la solicitud no procederá si no se confirma en una cantidad de días establecida por el Registrador y que no excederá los sesenta (60) días);

        1.3.Informar al Registratario Anterior o su Agente Designado que si su objetivo final es transferir el nombre de dominio a un registrador diferente, se aconseja al Registratario Anterior solicitar la transferencia entre registradores antes del Cambio de Registratario a fin de evitar el inicio del bloqueo de 60 días descrito en la Sección II.C.2 (a menos que el Registrador otorgara al Registratario Anterior la opción de retirarse del bloqueo de 60 días, y el Registratario Anterior optara por no utilizar el bloqueo de 60 días);

        1.4 Al momento de informar al Registratario Anterior tal como se describe anteriormente en II.C.1.3, o después , obtener la confirmación de la solicitud de Cambio de Registratario del Registratario Anterior o del Agente Designado del Registratario Anterior. El Registrador debe utilizar un mecanismo seguro para confirmar que el Registratario Anterior y / o sus respectivos Agentes Designados han consentido explícitamente el Cambio de Registratario. Al obtener la confirmación, el Registrador también debe informar al Registratario Anterior o al Agente Designado, si corresponde, que la solicitud de Cambio de Registratario no procederá si no se confirma en una cantidad de días establecida por el Registrador y que no excederá los sesenta (60) días);3

        1.5 Procesar el Cambio de Registratario dentro de un (1) día luego de obtener las confirmaciones anteriormente descritas;

        1.6 Notificar al Registratario Anterior y al Nuevo Registratario dentro del día de la finalización del Cambio de Registratario o con anterioridad al mismo. La notificación deberá:

        1.6.1 ser siempre enviada tanto al Nuevo Registratario como al Registratario Anterior dentro del día de la finalización del Cambio de Registratario o con anterioridad al mismo.

        1.6.2 explicar la solicitud que se recibió y enumerar los dominios en cuestión;

        1.6.3. Incluir información de contacto para consultas.

        1.6.4. Aconsejar al Registratario Anterior y al Nuevo Registratario el bloqueo de la transferencia entre registradores de 60 días como se describe en la Sección II.C.2, o informar al Registratario Anterior que previamente optó por salir del bloqueo de transferencia entre registradores de 60 días, tal como se describe en la Sección II.C.

      2. El Registrador debe imponer un bloqueo de transferencia entre registradores de sesenta (60) días4, aunque los registradores pueden permitir que los titulares del nombre registrado opten por el bloqueo en forma previa a cualquier solicitud de Cambio del Registratario.

Notas

Introducción y Antecedentes: El Proceso de Desarrollo de Políticas (PDP) sobre IRTP Parte C es el tercero de una serie de cinco PDP que abordan áreas para implementar mejoras en la política de transferencia existente.

El Consejo de la GNSO resolvió, en su reunión del 22 de septiembre de 2012, lanzar un PDP para abordar los siguientes tres temas:

  1. La función "Cambio de control", incluida una investigación sobre cómo se logra actualmente esta función, si existen modelos aplicables en el espacio de nombres con códigos de país que puedan utilizarse como una práctica recomendada para el espacio de gTLD y cualquier problema de seguridad asociado. También se debe incluir una revisión de los procedimientos de bloqueo, como se describe en Razones para la Denegación # 8 y # 9, con el objetivo de equilibrar la actividad de transferencia legítima y la seguridad.
  2. Si se deben implementar disposiciones sobre los formularios de autorización (FOA) con restricciones temporales para evitar transferencias fraudulentas. Por ejemplo, si un nuevo registrador envía un FOA y lo recibe de vuelta de un contacto de transferencias, pero el nombre está bloqueado, el registrador podría retener el FOA pendiente del ajuste del estado del nombre de dominio, período durante el cual el registratario u otros datos de registración podrían cambiar.
  3. La posibilidad de simplificar el proceso mediante un requerimiento que exija a los registros que utilicen identificaciones de IANA para los registradores en lugar de identificaciones propias.

El Grupo de Trabajo sobre IRTP Parte C publicó su Informe Inicial [PDF, 1.23 MB] el 4 de junio de 2012 conjuntamente con la apertura de un foro de comentarios públicos (véase la sección 6 para más detalles) seguido de su Informe Final [PDF, 624 KB] el 9 de octubre de 2012. La Junta Directiva de la ICANN adoptó las recomendaciones del Grupo de Trabajo sobre IRTP Parte C el 20 de diciembre de 2012. El Equipo para la Revisión de la Implementación y el personal de la ICANN trabajaron en conjunto para elaborar un borrador de la Política de Transferencia. El borrador de la política fue sometido a un periodo de comentarios públicos.

Todos los registradores acreditados por la ICANN deben cumplir con la política para el 1 de noviembre de 2016.

Cambio Sustancial: La Sección II.A.1.3 define como Cambio Sustancial a un cambio que no sea una corrección tipográfica. Los registradores tienen cierta flexibilidad para determinar qué es una corrección tipográfica. Algunos ejemplos de correcciones tipográficas podrían incluir:

  1. Cambiar el campo del Nombre del Registratario de John Smith a John Smith.
  2. Cambiar el campo del Nombre de Registratario de Jane Kgan a Jane Kang.
  3. Cambiar la organización del Registratario de Ejemplo Icn. a Ejemplo Inc.
  4. Cambiar la Organización de Registratario de ExamploCorp. a Ejemplo Corp.

Para evitar dudas, nada impide que el Registrador trate cualquier cambio en el nombre de Registratario o el campo Organización del Registratario como un Cambio Significativo.

Mecanismo Seguro: Las recomendaciones de política de la GNSO reconocen que se requiere algo de flexibilidad con respecto a cómo los registradores procesan un Cambio Significativo. Como ejemplo meramente enunciativo, los Registradores pueden desear considerar la autenticación "fuera de banda" en función de la información que no puede conocerse desde dentro de la cuenta del registrador o recursos públicamente disponibles como el Whois. Algunos ejemplos pueden incluir, en forma no taxativa:

  1. enviar un correo electrónico que requiera de una respuesta afirmativa a través de un método de autenticación basado en herramientas tales como proporcionar un código único que debe ser devuelto de la manera designada por el Registrador; o
  2. llamar o enviar un SMS al número de teléfono del Titular del Nombre Registrado suministrando un código único que debe ser devuelto de la manera designada por el registrador; o
  3. llamar al número de teléfono del Titular del Nombre Registrado y solicitarle que brinde un código único que le fue enviado a través de Internet, correo electrónico o correo postal.

Bloqueo de transferencia entre registradores posterior a un cambio de registratario: Los registradores no están obligados a implementar un código de estado de EPP específico para el bloqueo de transferencia entre registradores de 60 días descrito en la sección II.C.2. Sin embargo, si un registrador decide implementar el código de estado de EPP clientTransferProhibited, también debe bloquear el nombre de manera que prohíba al Titular del Nombre Registrado eliminar el bloqueo de conformidad con la sección I.A.5.1.


1 Si la registración y los detalles del Whois se cambian luego de la expiración del nombre de dominio de acuerdo con los términos del acuerdo de registro, las protecciones de la Política de Recuperación de Registraciones Vencidas se continúan aplicando.

2 Algunos ejemplos de mecanismos seguros se pueden encontrar en las notas de implementación que siguen el texto de esta política.

3 El registrador puede utililizar información de contacto adicional al obtener la confirmación del Registratario Anterior y no está limitado al Whois accesible al público.

4 El Registrador puede, aunque no está obligado a hacerlo, imponer restricciones a la remoción del bloqueo descrito en la Sección II.C.2. Por ejemplo, el Registrador sólo retirará el bloqueo después de que hayan transcurrido cinco días hábiles, la eliminación del bloqueo debe ser autorizada mediante la respuesta afirmativa del Registratario Anterior al correo electrónico, etc.

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."