Skip to main content
Resources

Política de Evaluación de Servicios de Registro

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.

Página web del Proceso de la RSEP

(Publicada el 25 de julio de 2006, en vigencia a partir del 15 de agosto de 2006)

1. Definiciones

1.1 Los Servicios de Registro se definen de la siguiente manera:

  1. los servicios que abarcan: (i) las operaciones del registro que resultan fundamentales para las siguientes tareas: la recepción de datos de registradores concernientes a la registración de nombres de dominio y servidores de nombres; la provisión a los registradores de información sobre el estado relativa a los servidores de la zona para el TLD (Dominio de Alto Nivel); la diseminación de los archivos de zona del TLD; la operación de los servidores de la zona del registro; y la diseminación de información de contacto u otra información relacionada con las registraciones de servidores de nombres de dominio en el TLD, de conformidad con el Acuerdo de Registro; y (ii) los suministros por parte del operador de registro a la fecha de vigencia del Acuerdo de Registro, según corresponda;
  2. otros productos o servicios que el operador de registro debe entregar de conformidad con la Política de Consenso (según se define anteriormente);
  3. Cualquier otro producto o servicio que únicamente el operador de registro puede brindar como consecuencia de su designación para este cargo; y
  4. Los cambios materiales para cualquier servicio de registro comprendido dentro del alcance de los puntos (A), (B) o (C) anteriores. (La definición se incluye en el Acuerdo de .NET, de acuerdo con lo especificado por la Junta de la ICANN el 8 de noviembre de 2005, http://www.icann.org/minutes/resolutions-08nov05.htm).

1.2 Seguridad - Se entiende por efecto sobre la seguridad por parte del Servicio de Registro propuesto a: (A) la divulgación, alteración, inserción o destrucción de datos de registro realizados sin autorización, o (B) el acceso no autorizado o la divulgación de información o recursos en Internet por los sistemas operativos de conformidad con todas las normas aplicables. (La definición se incluye en la Recomendación de la Organización de Apoyo para Nombres Genéricos (GNSO), disponible en http://gnso.icann.org/issues/registry-services/final-rpt-registry-approval-10july05.htm#5).

1.3 Estabilidad – Se entiende por efecto sobre la estabilidad por parte del Servicio de Registro propuesto cuando éste: (A) no cumpla con los estándares aplicables autorizados correspondientes, que han sido publicados por un ente de aplicación de normas reconocido y autorizado, como las Solicitudes de Comentarios (RFC) sobre el Seguimiento de normas o mejores prácticas vigentes, patrocinadas por el IETF (Grupo de Trabajo en Ingeniería de Internet) o (B) crea un estado que puede afectar adversamente el resultado, el tiempo de respuesta, la consistencia o coherencia de las respuestas a los servidores o sistemas finales de Internet, que operan de conformidad con los estándares aplicables correspondientes, autorizados y publicados por un ente de aplicación de normas establecido, reconocido y autorizado, como las RFC sobre el Seguimiento de normas o mejores prácticas vigentes y en función de los servicios de delegación de información o suministro de los operadores de registro. (La definición se incluye en la Recomendación de la Organización de Apoyo para Nombres Genéricos (GNSO), disponible en http://gnso.icann.org/issues/registry-services/final-rpt-registry-approval-10july05.htm#5).

1.4 Panel de Evaluación Técnica de Servicios de Registro - El Panel de Evaluación Técnica de Servicios de Registro deberá estar formado por un total de 20 expertos en diseño, administración e implementación de sistemas complejos y protocolos estándar utilizados en la infraestructura de Internet y el Sistema de Nombres de Dominio (DNS) (el "Panel de Evaluación Técnica de Servicios de Registro"). El Presidente del Panel de Evaluación Técnica de Servicios de Registro deberá seleccionar a los miembros de este panel. El Presidente del Panel de Evaluación Técnica de Servicios de Registro será una persona aceptable tanto para la ICANN como para las unidades constitutivas de registros de las organizaciones de apoyo responsables por las políticas de los registros de dominios genéricos de alto nivel. Todos los miembros del Panel de Evaluación Técnica de Servicios de Registro y su Presidente deberán firmar un contrato mediante el cual se requiera que cada cuestión deberá ser sometida a consideración de manera neutral ante el panel y de acuerdo con las definiciones de Seguridad y Estabilidad. Por cada asunto referido al Panel de Evaluación Técnica de Servicios de Registro, el Presidente deberá seleccionar no más de cinco miembros de dicho panel para evaluar el asunto referido y ninguno de ellos deberá tener conflictos de interés existentes de índole financiera, legal o relacionados con la competencia y con respecto a las cuestiones técnicas específicas planteadas con respecto a dicha referencia. (La definición se incluye en la Recomendación de la Organización de Apoyo para Nombres Genéricos (GNSO), disponible en http://gnso.icann.org/issues/registry-services/final-rpt-registry-approval-10july05.htm#5).

2. Proceso para someter a consideración los servicios de registro propuestos

2.1 El operador de registro o la organización patrocinadora considera el nuevo servicio de registro

Un operador de registro u organización patrocinadora en cualquier momento puede decidir cambiar la arquitectura o el funcionamiento de un servicio de registro existente de TLD o presentar un nuevo servicio de registro de TLD (véase la Introducción de las notas de implementación de la RSEP).

2.2 Determinar si el cambio requiere la revisión de la ICANN

Un operador de registro de gTLD o una organización patrocinadora determinará, mediante consultas a la ICANN y de acuerdo con lo mencionado en la Sección 2.4, si un cambio a un servicio requerirá aprobación de conformidad con el contrato entre la ICANN y el operador de registro (véase la Introducción de las notas de implementación de la RSEP).

2.3 Entregar a la ICANN la información relacionada con el cambio propuesto

La Política alienta a los proponentes de un nuevo servicio de registro a colaborar con la ICANN antes de presentar una solicitud de nuevos servicios de registro. El objetivo de la Política para Servicios de Evaluación de Registros y el proceso de aprobación consiste en crear un entorno que aliente a los operadores de registro de gTLD a debatir con la ICANN los cambios que pudieran tener impacto sobre terceros, antes de su implementación.

El operador de registro de TLD o la organización patrocinadora debería suministrar a la ICANN suficiente información sobre los cambios, a fin de permitir que la ICANN pueda evaluar si el cambio deberá estar sujeto al proceso de aprobación. La información debería incluir una descripción técnica del cambio como se verá por los usuarios externos y una evaluación del impacto sobre dichos usuarios externos. Si el operador de registro u organización patrocinadora ha solicitado aportes por parte de terceros y la comunidad, se deberán incluir los detalles del proceso y los resultados de dichos aportes. En esta etapa del proceso, el personal de la ICANN deberá considerar a dicha información como confidencial (véase las Notas de implementación de la RSEP, Pasos 1 y 2).

2.4 Período de Decisión Preliminar

Después de la notificación escrita del operador de registro a la ICANN, dicho operador de registro puede realizar un cambio en el Servicio de Registro dentro del alcance del párrafo anterior:

  1. La ICANN deberá contar con 15 días calendario para establecer una "decisión preliminar" en cuanto a si el Servicio de Registro requiere ser sometido a consideración adicional de la ICANN porque determina razonablemente que dicho Servicio de Registro: (i) podría plantear cuestiones significativas relacionadas con la Seguridad y la Estabilidad o (ii) podría plantear cuestiones significativas relacionadas con la competencia.
  2. Al momento de la notificación, el operador de registro debe entregar la información suficiente a la ICANN de que podrá implementar este Servicio de Registro propuesto, a fin de que la ICANN pueda tomar una "decisión preliminar" informada. La información provista por el operador de registro y señalada como "CONFIDENCIAL" deberá ser considerada confidencial por parte de la ICANN. El operador del registro no establecerá como "CONFIDENCIAL" la información necesaria para describir el objetivo del Servicio de Registro propuesto y el efecto sobre los usuarios del DNS.
  3. Durante el período de decisión preliminar, la ICANN puede solicitar asesoramiento de expertos (por parte de entidades o personas sujetas a los acuerdos de confidencialidad) sobre las implicancias relacionadas con la competencia, la seguridad o la estabilidad del Servicio de Registro para tomar esta "decisión preliminar". En la medida en que la ICANN determine divulgar la información confidencial a cualquiera de estos expertos, notificará al operador de registro la identidad del experto o los expertos y la información que desea transmitir. Para las implicancias de Seguridad y Estabilidad, la ICANN podrá retirar a un experto del Panel de Evaluación Técnica de Servicios de Registro, descripto en el punto 2.4(F) más adelante.
  4. Si la ICANN estableciera, durante el período de 15 días calendario de "decisión preliminar", que el Servicio de Registro propuesto no plantea cuestiones significativas relacionadas con la seguridad o la estabilidad (de acuerdo con lo definido en las Secciones 1.3 y 1.4) o la competencia, el operador de registro deberá tener libertad para realizar la implementación ante dicha decisión.

Si la implementación del servicio propuesto requiere un cambio esencial en el Acuerdo de Registro, la decisión preliminar será remitida a la Junta de la ICANN (véase las Notas de implementación de la RSEP, Paso 5).

2.5 Cuestiones relacionadas con la competencia

En el caso de que la ICANN determinara de manera razonable, durante el período de 15 días calendario de "decisión preliminar", que el Servicio de Registro podría plantear cuestiones significativas relacionadas con la competencia, la ICANN deberá remitir esta cuestión a la autoridad gubernamental competente adecuada o a las autoridades que tengan jurisdicción en la materia dentro de los cinco días hábiles de tomar dicha decisión o dos días hábiles posteriores al vencimiento de dicho período de 15 días, el que ocurra en primera instancia, notificándolo al operador de registro.

Cualquier comunicación de dicha remisión deberá ser publicada en el sitio web de la ICANN en la fecha de transmisión.

Con posterioridad a dicha remisión, la ICANN no será responsable y el operador de registro no deberá tener obligaciones adicionales con la ICANN, sobre cuestiones relacionadas con la competencia relativa al Servicio de Registro. Si dicha remisión tuviera lugar, el operador de registro no implementará el Servicio de Registro hasta 45 días calendario posteriores a la misma, a menos que la autoridad gubernamental competente referida lo aclarase con anticipación (véase las Notas de implementación de la RSEP, Pasos 4 a 6).

2.6 Cuestiones relacionadas con la Seguridad y la Estabilidad

En el caso de que la ICANN estableciera de manera razonable, durante el período de 15 días calendario de la "decisión preliminar", que el Servicio de Registro propuesto podría plantear cuestiones significativas relacionadas con la estabilidad o la seguridad (de acuerdo con lo definido en las Secciones 1.3 y 1.4), la ICANN remitirá la propuesta al Panel de Evaluación Técnica de Servicios de Registro (de acuerdo con lo definido en la Sección 1.5), dentro de cinco días hábiles de tomar dicha decisión o dos días hábiles posteriores al vencimiento de dicho período de 15 días, el que ocurra en primera instancia, y simultáneamente invitará a realizar comentarios públicos sobre la propuesta.

El Panel de Evaluación Técnica de Servicios de Registro deberá tener 45 días calendario a partir de la remisión, para preparar un informe escrito relacionado con el efecto del Servicio de Registro propuesto sobre la Seguridad y la Estabilidad (de acuerdo con lo definido en las Secciones 1.2 y 1.3) y dicho informe (junto con un resumen de los comentarios públicos) deberá ser entregado a la Junta de la ICANN. El informe deberá establecer las opiniones del Panel de Evaluación Técnica de Servicios de Registro, entre las que se incluyen, a modo de ejemplo, un informe detallado del análisis, los motivos y la información sobre la cual se ha basado el panel para llegar a estas conclusiones, junto con la respuesta a cualquier pregunta específica del personal de la ICANN que hubiera sido incluida con la remisión. Una vez realizada la derivación de la ICANN al Panel de Evaluación Técnica de Servicios de Registro, el operador de registro podrá presentar la información o el análisis adicional relacionado con el posible efecto sobre la Seguridad o la Estabilidad del Servicio de Registro.

Una vez realizada esta evaluación del Servicio de Registro propuesto, el Panel de Evaluación Técnica de Servicios de Registro informará la probabilidad y concreción de los efectos del Servicio de Registro propuesto sobre la Seguridad y la Estabilidad, inclusive si el Servicio de Registro propuesto origina un riesgo razonable de efectos adversos significativos para la Seguridad o la Estabilidad (véase las Notas de implementación de la RSEP, Pasos 4 a 6).

2.7 Decisión de la Junta de la ICANN

Una vez recibido el informe del Panel de Evaluación Técnica de  Servicios de Registro, que será publicado (respetando confidencialidad de los textos elaborados después de las consultas con el operador de registro) y publicado para la recepción de comentarios públicos, la Junta de la ICANN tendrá 30 días calendario para tomar una decisión. En el caso de que la Junta de la ICANN determinara de manera razonable que el Servicio de Registro propuesto origina un riesgo razonable de un efecto adverso significativo para la Estabilidad o la Seguridad, el operador de registro no ofrecerá el Servicio de Registro propuesto.

Se entregará al operador de registro una versión completa del informe del Panel de Evaluación Técnica de Servicios de Registro, una vez que el mismo sea publicado. El operador de registro podrá responder a dicho informe del Panel de Evaluación Técnica de Servicios de Registro o, de lo contrario, presentar ante la Junta de la ICANN la información o los análisis adicionales relacionados con el efecto probable sobre la Seguridad o la Estabilidad del Servicio de Registro (véase las Notas de implementación de la RSEP, Paso 5).

3. Reconsideración

Los operadores de gTLD o las organizaciones patrocinadoras afectadas por una decisión de la ICANN sobre un nuevo servicio de registro podrán utilizar los procesos de reconsideración existentes en los estatutos de la ICANN.

Los estatutos de la ICANN constituyen la fuente autoritativa para la información sobre el proceso de reconsideración (véase el Artículo IV: Sección 2 http://www.icann.org/general/bylaws.htm#IV). La reconsideración se aplica a las acciones del personal que contradicen una política de la ICANN o bien a medidas tomadas por la Junta de la ICANN sin tener en cuenta información importante. Puede encontrar información sobre procesos de reconsideración pasados en http://www.icann.org/committees/reconsideration.

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