Skip to main content

El equipo responsable del EPDP logra un progreso clave en su segunda etapa de trabajo

Epdp team key progress phase 2 1910x1082 19sep19 es

Como presidente del Proceso Expeditivo de Desarrollo de Políticas sobre la Especificación Temporaria para los Datos de Registración de los gTLD (equipo responsable del EPDP), me complace informarles que el equipo responsable del EPDP logró un avance fundamental en el desarrollo de un Sistema Estandarizado de Acceso/Divulgación (SSAD) para los datos de registración de gTLD sin carácter público, lo cual es central para la segunda etapa de trabajo del equipo.

La semana pasada, tuvimos tres jornadas de trabajo productivas en la sede central de la ICANN en Los Ángeles. Antes de nuestra reunión, el equipo responsable del EPDP analizó una variedad de casos de uso reales a fin de entender las necesidades y los requisitos que implica una solicitud de acceso a datos de registración sin carácter público. Luego de hacer una síntesis de los aspectos comunes a los casos analizados, nuestro personal de apoyo redactó el "Borrador Cero [DOCX, 5.45 MB]". En el documento, se incluyen los principales elementos de base y principios propuestos en materia de políticas para estimular nuestros debates sobre el desarrollo del SSAD.

Modelo "hamburguesa" para el SSAD

Para explicar este modelo de manera sencilla mediante una analogía, el equipo responsable del EPDP propuso el "modelo hamburguesa". La "hamburguesa" del SSAD se compone de tres partes esenciales e igualmente importantes.

  • El "pan de arriba": incluye los elementos relacionados con los solicitantes de acceso, es decir, personas o entidades que solicitan acceso a los datos de registración de gTLD sin carácter público.
  • El "pan de abajo": incluye los elementos relacionados con los proveedores de acceso, es decir, los registros y registradores que poseen los datos de registración de los gTLD.
  • La "hamburguesa" del medio: se trata de una interfaz que determina las modalidades de interacción entre quienes solicitan y proveen acceso en consonancia con los requisitos en materia de políticas desarrollados por el equipo responsable del EPDP. En debates posteriores, se determinará la estructura de la interfaz y el modo de procesamiento de las solicitudes.

Las tres partes del "modelo hamburguesa" del SSAD se construyeron con importantes bloques de base, los cuales representan varios principios en materia de políticas que sostienen su implementación.

  • Lado de la demanda: los bloques de base son necesarios para determinar quién puede solicitar los datos de registración, cómo se formula una solicitud y si el solicitante es un actor legítimo, entre otras consideraciones.
  • Lado de la oferta: los registros y registradores deben realizar determinadas acciones, como también responder a las solicitudes en consonancia con los requisitos establecidos en los bloques de base.
  • Interfaz del sistema: puede incluir diversas opciones. Por ejemplo, las solicitudes de datos pueden ingresar mediante una única puerta de enlace o mediante puertas de enlace múltiples; entre las posibilidades para comprobar la validez de cada solicitud, se incluyen la verificación de credenciales de acceso, la acreditación de los solicitantes u otras formas de verificación.

Si bien el equipo responsable del EPDP aceptó el "modelo hamburguesa" como punto de partida para sus deliberaciones, el equipo aún tiene mucho por hacer para llegar a un acuerdo sobre la política y los detalles operativos del SSAD. En esta última reunión celebrada en Los Ángeles, nuestro objetivo fue tomar varias decisiones fundamentales sobre el sistema en lo que respecta a su arquitectura.

Reunión en Los Ángeles

El primer día, nos reunimos con el Presidente y Director Ejecutivo (CEO) de la ICANN, Göran Marby, y los representantes del equipo de la organización de la ICANN a cargo de estar en contacto con el Comité Europeo de Protección de Datos. Esta sesión nos ayudó a comprender las próximas acciones que el equipo espera concretar para recibir los comentarios del EDPB sobre los supuestos en materia de políticas relativos al Modelo de Acceso Unificado (UAM). Nuestras conversaciones también se centraron en algunas de las cuestiones más críticas que debemos resolver, como la responsabilidad compartida entre los actores que participan en el procesamiento de solicitudes de datos, la posibilidad de que esta responsabilidad recaiga sobre organizaciones externas y la función que tendría la organización de la ICANN, si corresponde.

Después de nuestra conversación con Göran y el equipo de la organización de la ICANN, analizamos nuestra situación y reflexionamos sobre cómo capitalizar la información que recibimos e incorporarla a nuestro trabajo de desarrollo de políticas. Con el "Borrador Cero" como la base de nuestro trabajo, dedicamos el resto de la reunión a desarrollar varios bloques de base, los cuales priorizamos mediante una encuesta. Los temas fueron los siguientes:

  • Autenticación, autorización y acreditación de solicitantes.
  • Categorización de usuarios.
  • Propósitos de solicitar acceso a datos de registración sin carácter público.
  • Política de consultas que incluya acceso masivo y búsquedas inversas.

Además, analizamos los memorandos jurídicos de Bird & Bird LLP, nuestros asesores letrados externos. Los memorandos jurídicos nos orientaron acerca de los roles y las responsabilidades de las partes involucradas en el SSAD, la manera de llevar a cabo la prueba de equilibrio de conformidad con el GDPR y la posible automatización de las respuestas en el marco del SSAD, entre otros factores.

Al final de la reunión, acordamos de forma preliminar que las demás funciones del SSAD deberían tener el mayor grado posible de automatización y estandarización. También acordamos una serie de acciones a concretar para continuar avanzando, como el desarrollo de un posible modelo de acreditación y la consideración de quién decide, en última instancia, dar a conocer datos de registración sin carácter público. Continuaremos trabajando en cada elemento de base y, en paralelo, analizaremos las cuestiones estructurales y de arquitectura del SSAD para llegar a un acuerdo sobre cómo debería funcionar el sistema.

Estas tres jornadas presenciales resultaron ser una manera efectiva de trabajar en el escaso tiempo disponible del equipo. Mantuvimos un diálogo constructivo y definimos un curso de acción para dar respuesta a las diversas inquietudes de todas las partes interesadas mediante un proceso de múltiples partes interesadas y desde las bases.

En nombre del equipo responsable del EPDP, deseo agradecerle a Gina Bartlett de CBI por facilitar este encuentro y ayudarnos a mantener el impulso y foco de nuestro trabajo. También le agradecemos al personal de apoyo al equipo responsable del EPDP y al resto del personal de la organización de la ICANN que facilitó nuestro trabajo en Los Ángeles.

Próximos pasos

Aún tenemos mucho trabajo por delante. El próximo paso del equipo responsable del EPDP es hacer un seguimiento de nuestras acciones a concretar, recopilar los resultados de nuestro trabajo y redactar el "Borrador 1.0" para continuar aclarando nuestra visión del SSAD. También necesitamos planificar nuestras sesiones durante la reunión ICANN66 para optimizar las deliberaciones del equipo.

En Montreal, el equipo responsable del EPDP llevará a cabo cuatro sesiones, incluida una jornada de un día el sábado 2 de noviembre. Invitamos a quienes siguen nuestro trabajo a participar de nuestra sesión plenaria el lunes 4 de noviembre. Durante la sesión, esperamos presentar información actualizada sobre nuestros avances a partir de nuestro encuentro presencial en Los Ángeles y recibir los comentarios de la comunidad de la ICANN.

Más información

Las transcripciones, las grabaciones de audio y los resultados producidos por el equipo responsable del EPDP durante la reunión llevada a cabo en Los Ángeles se encuentran disponibles en esta página wiki.

Para ver más información sobre el equipo de la organización de la ICANN a cargo de interactuar con el EDPB, pueden consultar esta presentación [PDF, 10.5 MB].

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