Skip to main content
Resources

Política de transición al Whois amplio para .COM, .NET y .JOBS

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.

Novedades

El 7 de noviembre de 2019, la Junta Directiva de la ICANN aprobó una Resolución para diferir la aplicación del cumplimiento contractual. Cumplimiento Contractual de la ICANN diferirá el cumplimiento de la Política de Transición hacia WHOIS Amplio hasta que haya ocurrido lo siguiente:

  • El Equipo para la Revisión de la Implementación (IRT) de la Política de Datos de Registración de gTLD complete su revisión y establezca un cronograma estimativo para la implementación de las recomendaciones del Equipo responsable del Proceso Expeditivo de Desarrollo de Políticas (EPDP) adoptadas por la Junta Directiva de la ICANN el 15 de mayo de 2019.
  • La organización de la ICANN y el IRT proporcionen al Consejo de la GNSO la información requerida sobre los impactos de las recomendaciones del Equipo responsable del EPDP sobre procedimientos y políticas existentes (incluida la política de Transición hacia WHOIS Amplio).
  • El Consejo de la GNSO tome una decisión en cuanto a si tomará alguna medida sobre las actualizaciones a los procedimientos y políticas pertinentes (que podrían incluir trabajo de políticas adicional, pautas u otras acciones a determinar) que afectan a la Política de Transición hacia WHOIS Amplio.

Las palabras clave "DEBE", "NO DEBE", "REQUERIDO", "DEBERÁ", "NO DEBERÁ", "DEBERÍA", "NO DEBERÍA", "RECOMENDADO" y "PUEDE" en este documento se han de interpretar como se describe en el documento RFC 2119, que está disponible en: http://www.ietf.org/rfc/rfc2119.txt.

Alcance:

La presente política se APLICARÁ a los Operadores de Registro para los gTLD .COM, .NET y .JOBS, al igual que a todos los Registradores que patrocinan registraciones de nombres de dominio en los gTLD .COM, .NET o .JOBS.

Definiciones:

    • Acotado (registración): nombre de dominio para el cual el Operador de Registro mantiene y proporciona sólo información técnica (por ejemplo, servidores de nombre, estados, fecha de creación) y el Registrador patrocinador asociado con el nombre de dominio. La información de contacto para el nombre de dominio la mantiene el Registrador patrocinador.
    • Amplio (registración): nombre de dominio para el cual el Registrador patrocinador proporciona una copia de la información de contacto asociada al Operador de Registro. El Operador de Registro mantiene la información técnica (por ejemplo, servidores de nombre, estados, fecha de creación) y el Registrador patrocinador asociado con el nombre de dominio. La información de contacto para el nombre de dominio la mantiene el Registrador patrocinador.
    • Nombre de dominio existente: nombre de dominio creado, o en estado pendingCreate, antes del 1 de mayo de 2018.
    • Mediciones del Progreso de la Transición: mediciones creadas por el Operador de Registro y comunicadas de forma periódica a los Registradores y a la ICANN para permitir la medición del progreso de la transición de Acotado a Amplio, incluida al menos la cantidad total de dominios gestionados por el Registrador, la cantidad y el porcentaje de dominios con objetos de contactos adjuntos.

Fechas de vigencia y políticas:

3.1 Todas las registraciones nuevas de nombres de dominio DEBEN presentarse como Amplias a partir del 1 de mayo de 2018 a más tardar.

3.2 Todos los datos de registración relevantes para los nombres de dominio existentes DEBEN haberse migrado de Acotados a Amplios antes del 1 de febrero de 2019.

Los siguientes requisitos se aplican únicamente a los Operadores de Registro:

4.1 El Operador de Registro DEBE implementar un mecanismo de EPP y un mecanismo alternativo de transferencia masiva antes del 1 de agosto de 2017 para que los registradores migren los datos de registración para los nombres de dominio existentes (por ejemplo, la transición de Acotados a Amplios).

4.2 Antes del 1 de mayo de 2017, el Operador de Registro DEBE proporcionar a los Registradores correspondientes y a la ICANN la documentación que refleje los cambios del sistema necesarios para respaldar los requisitos de la Sección 4.1.

4.3 Antes del 1 de mayo de 2017, el Operador de Registro DEBE implementar un mecanismo de EPP y un mecanismo alternativo de transferencia masiva en los Entorno de Prueba y Evaluación Operativa (OT&E) para que los Registradores prueben la migración de los datos de registración para los nombres de dominio existentes (por ejemplo, la transición de Acotados a Amplios).

4.4 Antes del 1 de agosto de 2017, el Operador de Registro DEBE admitir todos los comandos de contacto especificados en la RFC5733 como se describe en la presente disposición. Los campos de contacto del EPP <contact:id>, <contact:postalInfo type> y <contact:authInfo> serán REQUERIDOS por el Operador de Registro. El Operador de Registro DEBE aceptar pero NO DEBE requerir todos los demás elementos de datos de registro hasta el 1 de febrero de 2019 que le permitan cumplir con los requisitos de WHOIS (disponibles a través del puerto 43) y de los servicios de directorio basados en la web que se describen en la Sección 1 de la Especificación 4 del "Acuerdo de Registro Base aprobado el 9 de enero de 2014" (" Acuerdo de Registro Base") o sus posteriores enmiendas y la Política de Uniformidad de Etiquetado y Visualización de los Servicios de Directorio de Datos de Registración.

4.5 A partir del 1 de mayo de 2018, el Operador de Registro DEBE requerir datos de Registro Amplio para un comando <create> de un objeto de dominio de EPP como se describe en la presente disposición. El Operador de Registro DEBE requerir todos los elementos de datos de registro que le permitan cumplir con los requisitos de WHOIS (disponibles a través del puerto 43) y de los servicios de directorio basados en la web que se describen en la Sección 1 de la Especificación 4 del "Acuerdo de Registro Base aprobado el 9 de enero de 2014" (" Acuerdo de Registro Base") o sus posteriores enmiendas y la Política de Uniformidad de Etiquetado y Visualización de los Servicios de Directorio de Datos de Registración.

4.6 Entre el 1 de agosto de 2017 y el 1 de febrero de 2019, el Operador de Registro DEBE proporcionar Mediciones del Progreso de la Transición a cada registrador, como mínimo de forma mensual, antes de las 23:59 UTC del primer día del mes siguiente.

4.7 Entre el 1 de agosto de 2017 y el 1 de febrero de 2019, el Operador de Registro DEBE proporcionar a la ICANN todas las Mediciones del Progreso de la Transición a cada registrador, como mínimo de forma mensual, antes de las 23:59 UTC del primer día del mes siguiente.

4.8 El Operador de Registro PUEDE implementar los requisitos de la Política de Uniformidad de Etiquetado y Visualización de los Servicios de Directorio de Datos de Registración ("Política de CL&D") junto con la Sección 1 de la Especificación 4 del "Acuerdo de Registro Base aprobado el 9 de enero de 2014" ("Acuerdo de Registro Base") o sus posteriores enmiendas antes del 1 de agosto de 2017.

4.9 El Operador de Registro DEBE cumplir con los requisitos de WHOIS (disponibles a través del puerto 43) y de los servicios de directorio basados en la web que se describen en la Sección 1 de la Especificación 4 del "Acuerdo de Registro Base aprobado el 9 de enero de 2014" (" Acuerdo de Registro Base") o sus posteriores enmiendas y la Política de Uniformidad de Etiquetado y Visualización de los Servicios de Directorio de Datos de Registración antes del 1 de mayo de 2018 para las nuevas registraciones y antes del 1 de febrero de 2019 para los nombres de dominio existentes.

4.10 Entre el 1 de agosto de 2017 y el 1 de febrero de 2019, para los nombres de dominio existentes, para los siguientes campos de salida del RDDS en los que no existen datos en el Sistema de Registro Compartido (SRS), el Operador de Registro PUEDE tratar los siguientes campos del RDDS como opcionales tal como se describe en la Aclaración 1 del "Asesoramiento: Aclaraciones sobre el Acuerdo de Registro y el Acuerdo de Acreditación de Registradores (RAA) de 2013 relativas a las Especificaciones aplicables del Servicio de Directorio de Datos de Registración (WHOIS)":

    • ID del Registro/Registratario/Contacto administrativo/Contacto técnico
    • Nombre del Registratario/Contacto administrativo/Contacto técnico
    • Calle del Registratario/Contacto administrativo/Contacto técnico
    • Ciudad del Registratario/Contacto administrativo/Contacto técnico
    • País del Registratario/Contacto administrativo/Contacto técnico
    • Teléfono del Registratario/Contacto administrativo/Contacto técnico
    • Correo electrónico del Registratario/Contacto administrativo/Contacto técnico

4.11 El contacto de "Facturación", salvo que el Acuerdo de Registro exija lo contrario, es opcional. La Política de registro puede definir si es obligatorio, opcional o no admitido Si corresponde, la información de contacto de Facturación se debe mostrar tal como se describe en el "Asesoramiento: Aclaraciones sobre el Acuerdo de Registro y el Acuerdo de Acreditación de Registradores (RAA) de 2013 relativas a las Especificaciones aplicables del Servicio de Directorio de Datos de Registración (WHOIS)" (sección22).

Los siguientes requisitos se aplican únicamente a los Registradores:

5.1 Entre el 1 de agosto de 2017 y el 1 de febrero de 2019, los Registradores DEBEN migrar al Operador de Registro relevante todos los campos requeridos de los nombres de dominio existentes que estén disponibles en la base de datos del Registrador que permitan al Operador de Registro cumplir con los requisitos de WHOIS (disponibles a través del puerto 43) y de los servicios de directorio basados en la web que se describen en la Sección 1 de la Especificación 4 del "Acuerdo de Registro Base aprobado el 9 de enero de 2014" (" Acuerdo de Registro Base") o sus posteriores enmiendas y la Política de Uniformidad de Etiquetado y Visualización de los Servicios de Directorio de Datos de Registración.

5.2 Los Registradores PUEDEN proporcionar datos completos de Registración Amplia al Operador de Registro que le permitan cumplir con los requisitos de WHOIS (disponibles a través del puerto 43) y de los servicios de directorio basados en la web que se describen en la Sección 1 de la Especificación 4 del "Acuerdo de Registro Base aprobado el 9 de enero de 2014" (" Acuerdo de Registro Base") o sus posteriores enmiendas y la Política de Uniformidad de Etiquetado y Visualización de los Servicios de Directorio de Datos de Registración, ante la creación de nuevas registraciones de nombres de dominio a partir del 1 de agosto de 2017.

5.3 Los Registradores DEBEN proporcionar datos completos de Registración Amplia al Operador de Registro que le permitan cumplir con los requisitos de WHOIS (disponibles a través del puerto 43) y de los servicios de directorio basados en la web que se describen en la Sección 1 de la Especificación 4 del "Acuerdo de Registro Base aprobado el 9 de enero de 2014" (" Acuerdo de Registro Base") o sus posteriores enmiendas y la Política de Uniformidad de Etiquetado y Visualización de los Servicios de Directorio de Datos de Registración, ante la creación de nuevas registraciones de nombres de dominio a partir del 1 de mayo de 2018.

Nota de implementación

Cuando exista un conflicto entre las leyes locales de privacidad y los requisitos incluidos en la presente Política, el Procedimiento de la ICANN para el manejo de conflictos de WHOIS con las leyes de privacidad está disponible para los Operadores de Registro y los Registradores.

Antecedentes

La Junta Directiva de la ICANN adoptó las recomendaciones de políticas de consenso del Grupo de trabajo de WHOIS amplio de la GNSO en relación al uso de WHOIS amplio por todos los registros de gTLD el 7 de febrero de 2014, después de que las recomendaciones fueran aprobadas por el Consejo de la GNSO. La recomendación n.° 1 indica que "el suministro de servicios de WHOIS amplio, con pautas uniformes de etiquetado y visualización conforme al modelo descripto en la especificación 3 del RAA (Acuerdo de Acreditación de Registradores) de 2013, debería ser un requisito para todos los registros de gTLD, tanto actuales como futuros". (Véase resoluciones 2014.02.07.08 - 2014.02.07.09 de la Junta Directiva de la ICANN en http://www.icann.org/en/groups/board/documents/resolutions-07feb14-en.htm#2.c).

La ICANN trabajó con un equipo de miembros de la comunidad (por ejemplo, el Equipo para la Revisión de la Implementación) para implementar las recomendaciones de políticas. Como parte de la implementación, y antes de su adopción, la ICANN procuró el aporte de la comunidad sobre las recomendaciones de políticas propuestas y sobre el texto incluido en esta Política. (Véasehttps://www.icann.org/public-comments/proposed-implementation-gnso-thick-rdds-whois-transition-2016-10-26-en).

Además, en la sección 7.2 del Informe Final [PDF, 1,23 MB] del Grupo de Trabajo para el PDP sobre la Política de Registros Amplios de WHOIS, incluyó pautas para las 'Consideraciones de implementación' en relación al cronograma y a los requisitos para la implementación de la transición desde los registros acotados hacia los registros amplios de WHOIS. Específicamente, señala que: "El Grupo de Trabajo hace hincapié en que la implementación de una parte de la recomendación (por ejemplo, la transición de los registros acotados existentes en los Registros de gTLD hacia el modelo de registros amplios de WHOIS) no debería retrasar innecesariamente la implementación de otra parte de la recomendación (por ejemplo, el etiquetado y la visualización coherentes de dichos datos)".

Como consecuencia, la organización de la ICANN trabajó con el Equipo de Revisión de Implementación para encontrar vías de implementación paralelas para la transición de registraciones de Whois acotado a amplio y una uniformidad de etiquetado y visualización de datos de Whois. Para obtener más detalles, consulte https://www.icann.org/resources/pages/rdds-labeling-policy-2017-02-01-en

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."