Novo Procedimento da ICANN para Resolução de Conflitos de Serviços de Diretório de Dados de Registro com as Leis de Privacidade

Por favor, observe que a versão em inglês de todo o conteúdo e dos documentos traduzidos são versões oficiais e que as traduções em outras línguas são apenas para fins de informar.

Data de início de vigência: 18 de abril de 2017

Exibir a versão com controle de alterações do Novo Procedimento para Conflitos de RDDS.

Para mais informações sobre Dados de Registro, acesse Dados de Registro na página da ICANN.

Introdução e histórico

0.1 Em dezembro de 2003, [1] a Força-tarefa 2 de WHOIS da GNSO recomendou o desenvolvimento de um procedimento para permitir que registros/registradores de gTLDs pudessem demonstrar situações em que fossem impedidos por leis locais de manter a conformidade plena com as disposições em contratos com a ICANN relacionadas a dados pessoais no WHOIS.

0.2 Em novembro de 2005 [2], a GNSO concluiu um processo de desenvolvimento de política para estabelecer esse procedimento. Ele se baseia em um “conselho bem elaborado sobre um procedimento” recomendado pela Força-tarefa de WHOIS e aprovado pelo Conselho da GNSO. [3] Em maio de 2006, a Diretoria da ICANN [4] adotou a política e orientou a equipe da ICANN a desenvolver e documentar publicamente um procedimento para conflitos.

0.3 Em 3 de dezembro de 2006, a equipe da ICANN publicou a versão preliminar do Procedimento da ICANN para Resolução de Conflitos do WHOIS com as Leis de Privacidade [inserir nota de rodapé, https://gnso.icann.org/issues/whois-privacy/whois_national_laws_procedure.htm]. A ICANN buscou feedback sobre o procedimento preliminar com o GAC (Governmental Advisory Committee, Comitê Consultivo para Assuntos Governamentais). O texto revisado foi incorporado em 1.4 abaixo.

0.4 Em 5 de outubro de 2015, o Grupo Consultivo de Implementação sobre conflitos de WHOIS com Leis Nacionais ¹ publicou seu relatório descrevendo possíveis aprimoramentos para esse procedimento. Comentários públicos foram solicitados sobre o relatório do grupo consultivo de 5 de outubro a 17 de novembro de 2015. O relatório final foi enviado ao Conselho da GNSO para ser considerado na reunião de maio de 2016.

0.5 O procedimento descrito abaixo explica como a ICANN responderá a uma situação em que um registrador/registro [5] indicar que é legalmente impossibilitado por leis ou regulamentos de privacidade locais/nacionais de manter a conformidade com as disposições do seu contrato com a ICANN no que diz respeito à coleta, exibição e distribuição de dados pessoais por meio do Serviço de Diretório de Dados de Registro (“RDDS”). O procedimento é para uso da equipe da ICANN. Embora ela inclua possíveis ações para o registrador/registro de gTLDs afetado, esse procedimento não impõe nenhuma obrigação aos registradores/registros nem a terceiros. Ele tem como objetivo informar registradores/registros, e outras partes, sobre as etapas que serão realizadas quando um possível conflito entre outras obrigações legais e os requisitos contratuais da ICANN no que diz respeito ao RDDS for relatado à ICANN.

Etapa um:

1. Notificação de procedimento do RDDS

   1.1 No momento mais oportuno após receber uma notificação de investigação, litígio, procedimento regulatório ou outra ação de natureza civil ou governamental que possa afetar sua conformidade com as disposições do Contrato de Credenciamento de Registrador (“RAA”) ou outro dispositivo contratual com a ICANN relacionado à coleta, exibição ou distribuição de dados de identificação pessoal por meio de um Serviço de Diretório de Dados de Registro (“Procedimento do RDDS”), o registro/registrador deverá fornecer à equipe da ICANN o seguinte:

   • Uma descrição resumida da natureza e do status da ação (por exemplo, sindicância, investigação, litígio, ameaça de sanções etc.) e uma série de possíveis resultados.
   • As informações de contato da pessoa responsável do registrador/registro por resolver o problema.
   • Se apropriado, as informações de contato da agência governamental territorial responsável, ou outro reclamante, e uma declaração do registrador/registro autorizando a ICANN a se comunicar com essas autoridades ou reclamantes sobre a questão. Se o registrador/registro for impedido por uma lei aplicável de conceder essa autorização, isso deverá ser informado na notificação.
   • O texto da lei ou regulamento relevante no qual o governo local ou outro reclamante estiver embasando a ação ou investigação, caso essa informação tenha sido indicada pelo governo ou outro reclamante.
   • Uma descrição dos esforços realizados para atender aos requisitos, tanto da legislação local quando das obrigações com a ICANN.

   1.2 Atender ao requisito de notificação permite aos registradores/registros participar em investigações e responder a decisões judiciais, regulamentos ou autoridades de fiscalização seguindo as medidas e orientações consideradas mais apropriadas por seus representantes legais.

   1.3 Dependendo das circunstâncias específicas do Procedimento do RDDS, o registrador/registro poderá solicitar que a ICANN mantenha a confidencialidade de todas as comunicações feitas entre as partes, na pendência do resultado do Procedimento do RDDS. A ICANN ordinariamente responderá de maneira favorável a essas solicitações, contanto que seja possível executá-las juntamente com outras responsabilidades legais e princípios básicos de transparência que se aplicam às operações da ICANN.

   1.4 Um registrador ou registro sujeito a um Procedimento do RDDS deverá trabalhar de maneira colaborativa com o governo nacional relevante a fim de garantir que o registrador ou registro opere em conformidade com as leis e os regulamentos nacionais, bem como o direito internacional e as convenções internacionais relevantes.

2. Gatilho Alternativo: declaração por escrito de agência governamental

   1.5 Na ausência de um Procedimento do RDDS, o registro ou registrador poderá apresentar à ICANN uma declaração por escrito de uma agência:

   • (a) Especificando os fatos dispostos, ou seja,
     • (i) a parte contratada específica em questão (registrador ou registro)
     • (ii) os termos de serviço/contratos de registro aplicáveis analisados pela agência
     • (iii) as disposições aplicáveis do contrato da ICANN em questão
     • (iv) as leis aplicáveis analisadas
   • (b) Identificando e analisando as inconsistências encontradas pela agência entre as leis nacionais e as obrigações contratuais, citando as cláusulas específicas de cada uma; e
   • (c) Certificando que a agência tem a autoridade legal para aplicar as leis nacionais que foram determinadas inconsistentes com as obrigações contratuais e que essa agência detém jurisdição sobre a parte contratada para fins dessa aplicação.

Etapa dois: consulta

2.1 O objetivo do processo de consulta deverá ser o de resolver o problema de maneira a preservar a capacidade do registrador/registro de manter conformidade com suas obrigações contratuais relacionados ao RDDS na medida do máximo possível.

2.1.1 A menos que seja impraticável diante das circunstâncias, após o recebimento e a análise da notificação, a ICANN consultará o registrador/registro. Quando apropriado considerando as circunstâncias específicas, a ICANN consultará as autoridades locais/nacionais de fiscalização ou outro reclamante juntamente com o registrador/registro.

2.1.2 De maneira alinhada a orientações do Comitê Consultivo para Assuntos Governamentais da ICANN, a ICANN entrará em contato com o governo nacional relevante para consultar sobre a autoridade da solicitação para derrogação com base nos requisitos do RDDS da ICANN.

2.2 Se o Procedimento do RDDS for concluído sem exigir alterações ou se as alterações necessárias na prática do registrador/registro, na opinião da ICANN, não constituir um desvio do RAA ou de outra obrigação contratual, então, a ICANN e o registrador/registro não precisarão fazer mais nada.

2.3 Se for exigido, por uma autoridade de fiscalização legal ou por uma decisão judicial, que o registrador/registro faça alterações em suas práticas de maneira a afetar sua conformidade com as obrigações contratuais referentes ao RDDS, antes de realizar qualquer processo de consulta, o registrador/registro deverá notificar a ICANN imediatamente sobre as alterações feitas, bem como as leis/regulamentos que embasaram a ação.

2.4 O registrador/registro poderá solicitar que a ICANN mantenha a confidencialidade de todas as comunicações feitas entre as partes, na pendência do resultado do Procedimento do RDDS. A ICANN ordinariamente responderá de maneira favorável a essas solicitações, contanto que seja possível executá-las juntamente com outras responsabilidades legais e princípios básicos de transparência que se aplicam às operações da ICANN.

2.5 Nos casos em que se aplica o Gatilho Alternativo, a Etapa de Consulta incluirá uma consulta pública durante a qual todas as partes interessadas poderão analisar a declaração por escrito enviada na Etapa de Notificação e enviar comentários sobre todos os aspectos dela. Nesses casos, a ICANN também consultará um representante do GAC do país em questão (se houver), de acordo com a seção 2.1.2 do procedimento.

Etapa três: análise e recomendação do diretor jurídico

3.1 Se o Procedimento do RDDS exigir alterações (antes, durante ou após o processo de consulta descrito acima) que, na opinião do gabinete do Diretor Jurídico da ICANN, impeçam a conformidade com as obrigações contratuais do RDDS, a equipe da ICANN poderá, em caráter provisório, deixar de tomar medidas executórias contra o registrador/registro por não conformidade, enquanto a ICANN prepara um relatório público e uma recomendação, que serão enviados à Diretoria da ICANN para uma decisão. Antes da divulgação do relatório ao público, o registro/registrador poderá solicitar que certas informações (inclusive, entre outras, comunicações entre o registro/registrador e a ICANN ou outras informações privilegiadas/confidenciais) sejam ocultas no relatório. O diretor jurídico poderá ocultar essas informações ou dados em qualquer versão publicada do relatório que digam respeito a conselhos legais à ICANN ou a conselhos da equipe jurídica da ICANN que, na opinião do diretor jurídico, devam ser restritas por se tratarem de informações privilegiadas ou por representarem um risco de imposição de responsabilidade à ICANN. Esse relatório poderá conter o seguinte:

1. Um resumo da lei ou regulamento envolvido no conflito;
2. Uma especificação da parte das obrigações contratuais relacionadas ao RDDS do registro ou registrador com a qual a conformidade plena foi impedida;
3. Um resumo do processo de consulta, se houver, da etapa dois; e
4. Uma recomendação de como o problema poderá ser resolvido, que talvez seja de a ICANN estabelecer uma exceção para os registradores/registros aos quais o conflito específico se aplica com base em uma ou mais disposições contratuais do RDDS identificadas. O relatório deverá incluir uma justificativa detalhada para sua recomendação, inclusive o impacto esperado na estabilidade operacional, confiabilidade, segurança ou interoperabilidade global dos sistemas de identificadores exclusivos da Internet se a recomendação for aprovada ou rejeitada.

3.2 O registrador/registro terá uma oportunidade razoável para enviar comentários à Diretoria. O Registrador/Registro poderá solicitar que a ICANN mantenha esse relatório confidencial antes de qualquer resolução da Diretoria. A ICANN ordinariamente responderá de maneira favorável a essas solicitações, contanto que seja possível executá-las juntamente com outras responsabilidades legais e princípios básicos de transparência que se aplicam às operações da ICANN.

3.3 Nos casos em que se aplica o Gatilho Alternativo, a Diretoria considerará todos os comentários públicos recebidos sobre a declaração por escrito enviada na Etapa de Notificação, bem como quaisquer comentários recebidos do representante do GAC do país em questão (se houver), de acordo com a seção 2.1.2 do procedimento.

Etapa quatro: resolução

4.1 Tendo em mente o impacto esperado na estabilidade operacional, confiabilidade, segurança ou interoperabilidade global dos sistemas de identificadores exclusivos da Internet, a Diretoria considerará as recomendações incluídas no relatório do diretor jurídico o quanto antes e tomará as medidas apropriadas. Essas medidas poderão incluir, entre outras:

• Aprovar ou rejeitar as recomendações do relatório, com ou sem modificações;
• Solicitar mais informações ao registrador/registro afetado ou outras partes;
• Agendar um período para comentários públicos sobre o relatório; ou
• Encaminhar o relatório à GNSO para ser revisado e comentado até uma data específica.

Etapa cinco: aviso público

5.1 A resolução da Diretoria para o problema, juntamente com o relatório do diretor jurídico, normalmente será publicada e arquivada no site da ICANN (além de outros materiais relacionados) para pesquisas futuras. Antes da divulgação dessas informações ao público, o registro/registrador poderá solicitar que certas informações (inclusive, entre outras, comunicações entre o registro/registrador e a ICANN ou outras informações privilegiadas/confidenciais) sejam ocultas no aviso público. O diretor jurídico poderá ocultar essas informações ou dados em qualquer versão publicada do relatório que digam respeito a conselhos legais à ICANN ou a conselhos da equipe jurídica da ICANN que, na opinião do diretor jurídico, devam ser restritas por se tratarem de informações privilegiadas ou por representarem um risco de imposição de responsabilidade à ICANN. Caso quaisquer partes ocultas dificultem a comunicação ao público sobre a natureza das medidas que serão tomadas pelo registro/registrador, a ICANN trabalhará para fornecer um aviso apropriado ao público descrevendo as medidas que serão tomadas, bem como as justificativas para elas, conforme a viabilidade diante de circunstâncias específicas.

5.2 A menos que a Diretoria decida de outra forma, se o resultado da resolução para o problema for que os elementos de dados na saída do RDDS do registro/registrador sejam removidos ou tenham acesso restrito, a ICANN emitirá um aviso apropriado ao público sobre a resolução e os motivos para a leniência da ICANN quanto à execução de plena conformidade com a disposição contratual em questão.

Etapa seis: revisão constante

6.1 Aproveitando os comentários significativos dos registros ou registradores relevantes, a ICANN, juntamente com todos os grupos constituintes, analisará a eficiência do processo anualmente.

---

[1] Força-tarefa 2 de WHOIS, Relatório Preliminar, junho de 2004; https://gnso.icann.org/issues/whois-privacy/Whois-tf2-preliminary

[2] Ata do Conselho da GNSO, 28 de novembro de 2005; https://gnso.icann.org/meetings/minutes-gnso-28nov05

[3] Relatório da Força-tarefa Final, 25 de outubro de 2005, da Força-tarefa de WHOIS da GNSO; https://gnso.icann.org/issues/tf-final-rpt-25oct05.htm

4] Ata da Diretoria, 10 de maio de 2006; https://www.icann.org/minutes/minutes-10may06.htm

[5] As referências a “registros” neste documento incluem operadores de registro e organizações patrocinadoras.

---

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