ES AL-ALAC-ST-0116-01-00-ES ORIGINAL: inglés FECHA: 23 de enero de 2016 ESTADO: Final

COMITÉ ASESOR AT-LARGE Declaración del ALAC sobre el Perfil operacional del Protocolo de Acceso a los Datos de Registración de Nombres de Dominio (RDAP) para Registros y Registradores de gTLD Introducción Holly Raiche, miembro del ALAC (Comité Asesor At-Large) por la Organización Regional At-Large de Asia, Australasia y las Islas del Pacífico (APRALO) y miembro del Equipo de Liderazgo del ALAC (ALT), y Carlton Samuels, miembro de la Organización Regional At-Large de América Latina e Islas del Caribe (LACRALO), redactaron un borrador inicial de la Declaración del ALAC. El 4 de enero de 2016 se publicó el primer borrador de la declaración en el Espacio de Trabajo de At-Large para el Perfil operacional del Protocolo de Acceso a los Datos de Registración de Nombres de Dominio (RDAP) para Registros y Registradores de gTLD. Ese mismo día, Alan Greenberg, Presidente del ALAC, solicitó al personal de políticas de la ICANN (Corporación para la Asignación de Nombres y Números en Internet) a cargo de asistir al ALAC que enviara una convocatoria a todos los miembros de At-Large a través de la lista de intercambio de correos electrónicos para anuncios del ALAC para que presentasen sus comentarios sobre la Declaración. El 14 de enero de 2016, en el espacio de trabajo mencionado anteriormente, se publicó una versión que incluía los comentarios recibidos y el Presidente del Comité solicitó al Personal que se abriera un período de votación para que el ALAC ratificase la declaración propuesta. El 23 de enero de 2016, el Personal confirmó que, de acuerdo con los resultados de la votación en línea, el ALAC respalda la Declaración con 14 votos a favor, ningún voto en contra y ninguna abstención. Los resultados están disponibles en el siguiente enlace: https://www.bigpulse.com/pollresults?code=5333p7i74gWzSWjyea43spnz.

Declaración del ALAC sobre el Perfil operacional del Protocolo de Acceso a los Datos de Registración de Nombres de Dominio (RDAP) para Registros y Registradores de gTLD El ALAC recibe con agrado la oportunidad de comentar sobre el Perfil operacional del Protocolo de Acceso a los Datos de Registración de Nombres de Dominio (RDAP) para Registros y Registradores de gTLD. Mientras que el nuevo Perfil operacional del RDAP incluye muchas nuevas características mejoradas a partir del anterior protocolo WHOIS, no incluye una lista de las características y disposiciones obligatorias que apoyen un marco de autenticación y autorización para el control de acceso. En su Informe del SSAC sobre la Terminología y Estructura de WHOIS, en relación a los Nombres de Dominio, de 2011, el SSAC (Comité Asesor de Seguridad y Estabilidad) recomendó el desarrollo de un protocolo de reemplazo que proporcionaría un marco uniforme y estándar para acceder a los Datos de Registración de Nombres de Dominio (DNRD). Ese marco 'definiría e implementaría métodos de verificación, servicios de credenciales y capacidades de control de acceso'. La Junta Directiva aceptó las recomendaciones del SSAC y estableció el Grupo de Trabajo de Expertos en Servicios de Directorio de gTLD (EWG) para que inicie la implementación de las recomendaciones. En su Informe Final, el EWG recomendó un cambio de paradigma, mediante el cual los datos de registración de gTLD son recolectados, validados y divulgados únicamente con fines permisibles, con ciertos elementos de datos accesibles únicamente a solicitantes autorizados y responsables de usarlos apropiadamente. Por lo tanto, mientras que las políticas de la ICANN existentes no requieren ahora el acceso diferenciado a los DNRD, a partir de las decisiones de la Junta Directiva y de las recomendaciones del EWG queda claro que las futuras políticas de la ICANN probablemente cuenten con ese requisito. Por lo tanto, el Perfil operacional del RDAP debe incluir la obligación de que todos los Registros y Registradores de gTLD cuenten con la funcionalidad básica que apoyará un marco de autenticación y autorización. Específicamente, las características para permitir el acceso diferenciado deben ser exigidas ahora como parte de este protocolo; incluso si en esta etapa todos quienes soliciten acceso estarán dentro de una clase: el público. De esa manera, al imponer requisitos de acceso diferenciados, las características del protocolo ya estarán desplegadas como para suministrar dicho acceso.