Procedimiento revisado de la ICANN para el manejo de conflictos entre los Servicios de Directorio de Datos de Registración de Nombres de Dominio y las leyes de privacidad

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.

Fecha de entrada en vigencia: 18 de abril de 2017

Ver la versión con cambios resaltados del Procedimiento revisado para el manejo de conflictos del RDDS.

Para más información sobre datos de registración, visite nuestra página sobre datos de registración en el sitio web de la ICANN.

Introducción e información de referencia

0.1 En diciembre de 2003, [1] el Grupo de Acción 2 del WHOIS de la GNSO recomendó el desarrollo de un procedimiento para permitir que el registro/los registradores de gTLD demuestren cuando la legislación local les impide cumplir en su totalidad con las disposiciones de los contratos de la ICANN respecto de datos personales en el WHOIS.

0.2 En noviembre de 2005 [2], la GNSO concluyó un proceso de desarrollo de políticas sobre el establecimiento de dicho procedimiento. Sigue el ‘asesoramiento bien desarrollado sobre un procedimiento’ recomendado por el Grupo de Acción del WHOIS y aprobado por el Consejo de la GNSO. [3] En mayo de 2006, la Junta Directiva de la ICANN [4] adoptó la política y ordenó al personal de la ICANN que desarrollase y documentase públicamente un procedimiento para el manejo de conflictos.

0.3 El 3 de diciembre de 2006, el personal de la ICANN publicó un procedimiento preliminar de la ICANN para el manejo de conflictos entre el sistema de WHOIS y las leyes de privacidad [insertar nota al pie, https://gnso.icann.org/issues/whois-privacy/whois_national_laws_procedure.htm]. La ICANN solicitó aportes sobre el procedimiento preliminar del Comité Asesor Gubernamental (GAC). La redacción revisada se incorpora al ítem 1.4. que figura a continuación.

0.4 El 5 de octubre de 2015, el Grupo Asesor de Implementación respecto de Conflictos del WHOIS con la legislación nacional¹ publicó su informe en el que señala posibles mejoras a este procedimiento. Se solicitó comentario público sobre el informe del grupo asesor del 5 de octubre al 17 de noviembre de 2015. El informe final fue presentado ante el Consejo de la GNSO para su consideración en su reunión de mayo de 2016.

0.5 El procedimiento descripto más abajo detalla cómo la ICANN responderá ante una situación en la que un registrador/registro [5] indica que las normas regulatorias o leyes de privacidad locales/nacionales le impiden cumplir con las disposiciones de su contrato de la ICANN respecto de la recopilación, visualización y distribución de datos personales a través del Servicio de Directorio de Datos de Registración de Nombres de Dominio (“RDDS”). El procedimiento es para ser utilizado por el personal de la ICANN. Si bien incluye posibles acciones para el registro/registrador del gTLD afectado, este procedimiento no impone ninguna obligación nueva sobre los registros/registradores o terceros. Tiene el objetivo de informar a los registros/registradores y otras partes de los pasos que se tomarán cuando un posible conflicto entre otras obligaciones legales y los requisitos contractuales de la ICANN respecto del RDDS sea informado a la ICANN.

Primer paso:

1. Notificación del procedimiento de RDDS

   1.1 En el acontecimiento correspondiente que ocurra primero en recibir la notificación de una investigación, litigio, procedimiento regulatorio u otra acción civil o gubernamental que pueda afectar su cumplimiento con las disposiciones del Acuerdo de Acreditación de Registradores (“RAA”) u otro acuerdo contractual con la ICANN respecto de la recopilación, visualización o distribución de datos de identificación personal mediante el Servicio de Directorio de Datos de Registración de Nombres de Dominio (“Procedimiento de RDDS”), un registrador/registro debe proporcionar al personal de la ICANN lo siguiente:

   • Una breve descripción de la índole y el estado de la acción (por ejemplo, investigación, litigio, advertencia de sanción, etc.) y un conjunto de posibles resultados.
   • Datos de contacto del funcionario del registrador o registro responsable de resolver el problema.
   • De ser pertinente, información de contacto de la agencia gubernamental territorial responsable u otra parte reclamante, y una declaración del registrador/registro que autorice a la ICANN a comunicarse con dichos funcionarios o partes actoras sobre el asunto. Si la ley aplicable impide que el registro o registrador otorgue dicha autorización, esa situación debe quedar documentada en la notificación.
   • El texto de la ley aplicable o de la norma regulatoria en la cual el gobierno local, o el solicitante, fundamente su acción o investigación, en caso de que esta información haya sido indicada por el gobierno o por el solicitante.
   • Descripción de los esfuerzos realizados para cumplir con los requisitos de la legislación local y las obligaciones para con la ICANN.

   1.2 Al cumplir con los requisitos de notificación, los registradores y registros pueden participar de las investigaciones y responder a resoluciones judiciales, normas regulatorias u organismos encargados de la aplicación de la ley, de la manera en que sus asesores letrados consideren más apropiada.

   1.3 En función de las circunstancias específicas del procedimiento de RDDS, el registrador/registro puede solicitar que la ICANN mantenga toda la correspondencia entre las partes de manera confidencial hasta tanto se dé a conocer el resultado del procedimiento de RDDS. La ICANN normalmente responderá de manera favorable a dichas solicitudes en la medida que puedan ser acomodadas con otras responsabilidades legales y los principios básicos de transparencia aplicables a las operaciones de la ICANN.

   1.4 Un registro o registrador sujeto a un procedimiento de RDDS debe colaborar con el gobierno nacional pertinente para demostrar que opera conforme a las leyes y normas regulatorias locales, y el derecho nacional e internacional aplicable.

2. Disparador alternativo: declaración escrita de la agencia gubernamental

   1.5 Ante la ausencia de un procedimiento de RDDS, un registro o registrador puede presentar ante la ICANN una declaración escrita de la agencia, la cual deberá:

   • (a) Especificar los hechos ante ella; es decir,
     • (i) la parte contratada específica en cuestión (registrador o registro)
     • (ii) los términos aplicables de servicio/acuerdos de registro que ha revisado la agencia
     • (iii) las disposiciones aplicables del contrato de la ICANN en cuestión
     • (iv) la ley aplicable que ha analizado
   • (b) Identificar y analizar la incongruencia que la agencia ha detectado entre la legislación nacional y las obligaciones contractuales, citando las disposiciones específicas de cada una; y
   • (c) Certificar que la agencia tiene autoridad legal para aplicar la legislación nacional que ha detectado que es incongruente con las obligaciones contractuales y que tiene jurisdicción sobre la parte contratada con los fines de dicho cumplimiento efectivo

Segundo paso: Consultas

2.1 El objetivo del proceso de consulta debería ser buscar resolver el problema de una manera que preserve la capacidad del registrador/registro de cumplir con sus obligaciones contractuales del RDDS en la mayor medida posible.

2.1.1 A menos que resulte poco práctico según las circunstancias, al momento de la recepción y revisión de la notificación, la ICANN consultará con el registrador/registro. En los casos donde resulte pertinente según las circunstancias, la ICANN consultará con las autoridades responsables del cumplimiento de la ley locales/nacionales u otro solicitante junto con el registrador/registro.

2.1.2 En virtud del asesoramiento del Comité Asesor Gubernamental de la ICANN, la ICANN solicitará asesoramiento del gobierno nacional relevante sobre la autoridad de la solicitud de derogación de los requisitos de RDDS de la ICANN.

2.2 Si el procedimiento de RDDS finaliza sin requerir ningún cambio o los cambios requeridos en la práctica del registrador/registro, según la opinión de la ICANN, no constituyen una desviación del RAA u otra obligación contractual, la ICANN y el registrador/registro no necesitan realizar otra acción.

2.3 Si autoridades responsables del cumplimiento de la ley locales o un tribunal exigen al registrador/registro realizar cambios en sus prácticas que afecten el cumplimiento de las obligaciones contractuales relacionadas con el RDDS antes de que pueda tener lugar un proceso de consulta, el registrador/registro debería notificar prontamente a la ICANN de los cambios realizados y la norma regulatoria/legislación sobre la cual se basó la acción.

2.4 El registrador/registro puede solicitar que la ICANN mantenga toda la correspondencia entre las partes de manera confidencial hasta tanto se dé a conocer el resultado del procedimiento de RDDS. La ICANN normalmente responderá de manera favorable a dichas solicitudes en la medida que puedan ser acomodadas con otras responsabilidades legales y los principios básicos de transparencia aplicables a las operaciones de la ICANN.

2.5 En los casos en los que se aplique el disparador alternativo, el paso de consulta incluye una consulta pública en la cual las partes interesadas pueden revisar la declaración escrita presentada en el paso de notificación y comentar sobre todos los aspectos de la misma. En dichos casos, la ICANN también consultaría con el representante del GAC (si lo hubiera) del país en cuestión, de conformidad con la sección 2.1.2 del procedimiento.

Tercer paso: análisis y recomendación del Asesor Letrado General

3.1 Si el procedimiento de RDDS requiere cambios (ya sea antes, durante o después del proceso de consulta descripto anteriormente) que, en la opinión de la oficina del Asesor Letrado General de la ICANN, impiden el cumplimento de las obligaciones contractuales del RDDS, el personal de la ICANN puede abstenerse, de manera provisional, de tomar una acción en pos del cumplimiento en contra del registrador/registro por la falta de cumplimiento, mientras la ICANN prepara un informe público y recomendación, y lo presenta a la Junta de la ICANN para que tome una decisión. Antes de la publicación del informe al público, el registro/registrador puede solicitar que cierta información (por ejemplo, comunicaciones entre el registro/registrador y la ICANN u otra información confidencial/privilegiada) sea editada en el informe. El Asesor Letrado General puede editar dicho asesoramiento o información en cualquier versión publicada del informe que se relacione con el asesoramiento legal a la ICANN o el asesoramiento del asesor de la ICANN que en la opinión del Asesor Letrado General debería restringirse debido a privilegios o posible responsabilidad para con la ICANN. El informe debe contener lo siguiente:

1. Un resumen de la ley o normativa regulatoria implicada en el conflicto,
2. Especificación de la parte de las obligaciones contractuales del RDDS del registro o registrador con la cual se impide el cumplimiento total;
3. Un resumen del proceso de consulta, si lo hubiere, efectuado en el segundo paso del procedimiento, y
4. Recomendación de cómo debería resolverse la cuestión, que puede incluir si la ICANN debería brindar una excepción para aquellos registradores/registros a los que el conflicto específico se aplica de una o más disposiciones contractuales del RDDS identificadas. El informe debería contener una justificación detallada de su recomendación, incluido el impacto anticipado sobre la estabilidad, confiabilidad y seguridad operativa, o la interoperabilidad de los sistemas de identificadores únicos de Internet en caso de que la recomendación fuese aprobada o denegada.

3.2 El registro o registrador tendrá una oportunidad razonable de presentar sus comentarios ante la Junta Directiva. El registrador/registro puede solicitar que la ICANN mantenga dicho informe de manera confidencial antes de que la Junta llegue a una resolución. La ICANN normalmente responderá de manera favorable a dichas solicitudes en la medida que puedan ser acomodadas con otras responsabilidades legales y los principios básicos de transparencia aplicables a las operaciones de la ICANN.

3.3 En los casos en que se aplique el disparador alternativo, la Junta considerará todo comentario público recibido sobre la declaración escrita presentada en el paso de notificación, así como todo aporte recibido del representante del GAC (si lo hubiere) del país en cuestión, en virtud de la sección 2.1.2 del procedimiento.

Cuarto paso: Resolución

4.1 Teniendo presente el impacto anticipado sobre la estabilidad, confiabilidad y seguridad operativa, o la interoperabilidad global de los sistemas de identificadores únicos de Internet, la Junta Directiva considerará adoptar las acciones apropiadas respecto de las recomendaciones presentadas en el informe del Asesor Letrado General a la brevedad posible. Las acciones pueden incluir:

• Aprobar o rechazar las recomendaciones presentadas en el informe, con o sin modificaciones,
• Solicitar información adicional al registro o registrador afectado, o a terceros,
• Llevar a cabo un período de comentario público sobre el informe, o
• Remitir el informe a la GNSO para su revisión y comentario para una fecha determinada.

Quinto paso: Publicación

5.1 La resolución de la cuestión por parte de la Junta, junto con el informe del Asesor Letrado General, normalmente estará a disposición del público y será archivada en el sitio web de la ICANN (junto con otros materiales relacionados) para futura investigación. Antes de la publicación pública de dicha información, el registro/registrador puede solicitar que cierta información (por ejemplo, comunicaciones entre el registro/registrador y la ICANN, u otra información confidencial/privilegiada) sea editada en la notificación pública. El Asesor Letrado General puede editar dicho asesoramiento o información en cualquier versión publicada del informe que se relacione con el asesoramiento legal a la ICANN o el asesoramiento del asesor de la ICANN que en la opinión del Asesor Letrado General debería restringirse debido a privilegios o posible responsabilidad para con la ICANN. En el caso de que cualquier edición dificulte transmitir al público la naturaleza de las acciones a ser tomadas por el registro/registrador, la ICANN trabajará para proporcionar la notificación apropiada al público en la que se describan las acciones a tomarse y la justificación de dichas acciones, como pueda resultar factible en virtud de las circunstancias.

5.2 A menos que la Junta decida lo contrario, si el resultado de su resolución de la cuestión es que los elementos de datos del resultado del RDDS del registro/registrador sean eliminados o menos accesibles, la ICANN emitirá una notificación adecuada al público de la resolución y de los motivos para la indulgencia de la ICANN en la exigencia del cumplimiento total de la disposición contractual en cuestión.

Sexto paso: Revisión continua

6.1 Con aportes sustanciales de los registros o registradores relevantes, junto con todas las unidades constitutivas, la ICANN revisará la eficacia del proceso en forma anual.

---

[1] Grupo de Acción del WHOIS, Informe preliminar, junio de 2004; https://gnso.icann.org/issues/whois-privacy/Whois-tf2-preliminary

[2] Actas de reunión del Consejo de la GNSO, 28 de noviembre de 2005; https://gnso.icann.org/meetings/minutes-gnso-28nov05

[3] Informe Final del Grupo de Acción, 25 de octubre de 2005, del Grupo de Acción del WHOIS de la GNSO; https://gnso.icann.org/issues/tf-final-rpt-25oct05.htm

[4] Actas de reunión de la Junta Directiva, 10 de mayo de 2006; https://www.icann.org/minutes/minutes-10may06.htm

[5] La referencia a 'registros' en este documento incluye a los operadores de registro y a las organizaciones patrocinadoras.

---

¹ https://community.icann.org/display/WNLCI/WHOIS+and+national+law+conflicts+IAG+Home