Skip to main content

El equipo responsable del EPDP publica el informe final sobre su segunda etapa de trabajo

En nombre del equipo responsable del Proceso Expeditivo de Desarrollo de Políticas (EPDP) sobre la Especificación Temporaria para los Datos de Registración de los Dominios Genéricos de Alto Nivel (gTLD), tengo el agrado de anunciar la publicación del informe final correspondiente a nuestra segunda etapa de trabajo.

En el informe final, se presentan las recomendaciones del equipo responsable del EPDP sobre un Sistema Estandarizado de Acceso/Divulgación (SSAD) para datos de registración de gTLD sin carácter público, junto con recomendaciones y conclusiones sobre los temas de segundo nivel prioritario, entre los cuales se incluye la eliminación del campo donde se indica la ciudad.

Puntos destacados del informe final

En sus deliberaciones, el equipo responsable del EPDP consideró un modelo centralizado, en el cual las solicitudes y decisiones de divulgar información serían gestionadas por la ICANN o una entidad a la cual la ICANN le delegara esta función, junto con un modelo descentralizado, en el cual tanto las solicitudes como las decisiones de divulgar información serían gestionadas por partes contratadas (registradores acreditados por la ICANN y operadores de registro de gTLD). Al no llegar a un acuerdo sobre ninguna de estas opciones, el equipo propuso un modelo híbrido en el cual las solicitudes serían centralizadas y las decisiones de divulgar información, al menos en la implementación inicial, correrían normalmente por cuenta de las partes contratadas.

A fin de entender los requisitos para la divulgación de datos de registración sin carácter público, el equipo responsable del EPDP tuvo en cuenta una gran cantidad de preguntas, analizó una amplia variedad de casos prácticos reales para los usuarios del SSAD, definió los elementos básicos del modelo y acordó los temas en común para elaborar sus recomendaciones preliminares. Tras un análisis exhaustivo de todos los comentarios públicos recibidos y nuevas rondas de deliberaciones, el equipo responsable del EPDP incluyó 18 recomendaciones sobre políticas relativas al SSAD y cuatro recomendaciones sobre temas de segundo nivel prioritario en su informe final.

A grandes rasgos, las 18 recomendaciones sobre políticas relativas al SSAD corresponden, entre otros, a los siguientes temas:

  • Acreditación de solicitantes en el SSAD, incluidas las entidades gubernamentales
  • Criterios y contenidos requeridos para las solicitudes en el SSAD
  • Requisitos de respuesta
  • Acuerdos de Nivel de Servicio (SLA) requeridos
  • Automatización de procesos en el SSAD
  • Términos y condiciones del SSAD
  • Requisitos para iniciar sesión, realizar auditorías y presentar informes
  • Creación de un Comité Permanente de la GNSO a cargo de evaluar los aspectos operativos del SSAD y recomendar mejoras al Consejo de la GNSO

Es importante señalar que, para el equipo responsable del EPDP, las 18 recomendaciones sobre el SSAD son interdependientes. Por lo tanto, el equipo recomienda que el Consejo de la GNSO y la Junta Directiva de la ICANN consideren estas recomendaciones como un todo.

El equipo responsable del EPDP también presentó recomendaciones sobre los siguiente temas:

  • Visualización de la información de proveedores de servicios de privacidad/ representación (proxy) subsidiarios
  • Campo donde se indica la ciudad
  • Retención de datos
  • Segundo propósito

Próximos pasos

El 3 de septiembre de 2020 a las 21:00 UTC, el Consejo de la GNSO realizará un seminario web para presentar información detallada sobre el Informe Final de la Segunda Etapa del EPDP. Las instrucciones para conectarse al seminario web su publicarán aquí.

Agradecimientos

La publicación del informe final sobre su segunda etapa de trabajo es otro logro importante del equipo responsable del EPDP. El equipo responsable de esta segunda etapa, integrado por 31 miembros titulares y 19 suplentes, llevó a cabo 74 teleconferencias que se extendieron por varias horas y una serie de reuniones presenciales el año pasado.

Gracias a la dedicación, la voluntad de llegar a un acuerdo y el compromiso de trabajar mediante un proceso de múltiples partes interesadas que demostraron todos los participantes, el EPDP avanzó notablemente y se encuentra más cerca de concluir su labor.

Agradecemos todos los aportes recibidos durante el periodo de comentario público. También valoramos la estrecha colaboración de la Junta Directiva y la organización de la ICANN. Sus valiosos aportes nos facilitaron información para nuestras deliberaciones sobre el SSAD.

Asimismo, deseamos expresarle nuestro agradecimiento al personal de apoyo al equipo responsable del EPDP por su gran labor en pos del logro de nuestros objetivos en todas las etapas de este proceso.

Por último, no debo dejar de agradecerle a Janis Karklins, quien presidió la segunda etapa de este proceso, por las innumerables horas que le dedicó a esta iniciativa en carácter voluntario, junto con sus habilidades de coordinación y liderazgo, necesarias para que el equipo llegara hasta aquí.

Comments

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