Resumo

  • A autoridade da ICANN é montada por instrumentos diferentes: sua carta corporativa e seus bylaws definem capacidade e limites; processos multissetoriais produzem políticas; contratos e acordos técnicos tornam essas políticas operacionais.
  • O teste de accountability não termina quando existe um canal de revisão. É preciso saber se esse canal alcança o ato contratual ou técnico que causou o efeito, oferece reparação vinculante e chega a tempo, inclusive quando o afetado não é contraparte contratual da ICANN.

A controvérsia sobre a ICANN costuma começar com uma pergunta ampla demais: ela é uma reguladora? Os documentos examinados apontam para uma resposta mais precisa. A ICANN é uma corporação californiana sem fins lucrativos de benefício público, e sua carta de incorporação descreve objetivos ligados à coordenação dos sistemas globais de identificadores únicos da Internet e à estabilidade operacional. Isso define uma finalidade institucional, não uma transferência automática de poder legislativo, licenciador, policial ou adjudicatório. A carta de incorporação da ICANN é, portanto, uma fonte sobre forma jurídica e propósito, não prova de soberania.

Os bylaws estreitam ainda mais o enquadramento. Eles descrevem uma missão centrada na coordenação dos sistemas de identificadores únicos e na formulação de políticas razoável e apropriadamente relacionadas a essas funções técnicas. Também afirmam que a ICANN não possui autoridade regulatória autorizada pelo governo e não deve regular serviços que utilizam identificadores da Internet, nem o conteúdo transportado por esses serviços, fora de sua missão definida. Os bylaws da ICANN são constitutivos e expressam a posição institucional sobre seus próprios limites. Não resolvem, sozinhos, se alguma lei externa atribui autoridade pública em um caso concreto.

Essa distinção importa porque uma regra pode ter efeitos regulatórios sem nascer de uma autoridade pública. Quando a ICANN incorpora uma política em um contrato de registry ou registrar, a consequência prática pode atingir registros, serviços de dados, auditorias, contatos de abuso, escrow, taxas, conformidade, suspensão, inadimplemento ou término. O repositório de acordos de registries, o acordo-base de registry, as especificações aprovadas e as políticas de consenso para registrars mostram uma arquitetura de obrigações contratuais, emendas e políticas incorporadas. Não há um único contrato que governe todos os TLDs, e domínios de código de país podem obedecer a arranjos diferentes. Ainda assim, a dependência contratual da zona-raiz pode produzir efeitos semelhantes aos de regulação sem converter a ICANN em um regulador soberano.

O segundo componente é a formulação de políticas. A política não surge simplesmente de uma ordem unilateral da equipe da ICANN. O desenho institucional depende de processos das comunidades, organizações de apoio, comitês consultivos, aprovação e, em alguns casos, incorporação posterior em contratos. Isso separa três atos que frequentemente são tratados como um só: elaborar a regra, adotá-la dentro da estrutura corporativa e fazê-la operar contra uma contraparte contratual.

A separação fica mais clara nas funções IANA. Antes de 2016, o contrato de funções IANA colocava o papel da ICANN dentro de uma estrutura de contratação e supervisão do governo dos Estados Unidos, incluindo responsabilidades ligadas ao gerenciamento da zona-raiz. O instrumento histórico não descreve a autoridade atual depois da transição. O contrato de funções IANA de 2012 serve para reconstruir esse contexto anterior, não para provar que a supervisão federal continua.

A proposta de transição de 2016 desenhou uma arquitetura distribuída, e não uma transferência integral de controle soberano para a ICANN. O arranjo envolvia a Public Technical Identifiers, o contrato entre ICANN e PTI para a função de nomes, monitoramento pelo Customer Standing Committee, revisões periódicas e especiais da função de nomes e uma possível separação. Também preservava relações distintas com os Regional Internet Registries e com a IETF. A proposta é um documento de desenho de governança; quando houver divergência, prevalecem os bylaws, contratos e emendas operacionais.

No plano dos nomes, o contrato da função IANA Naming entre ICANN e PTI descreve serviços operacionais, obrigações de desempenho, relatórios, níveis de serviço e escalonamento. Ele mostra que uma parte importante da capacidade operacional é corporativa e contratual. Também mostra uma limitação: PTI é uma afiliada controlada pela ICANN, de modo que não se trata simplesmente de um fornecedor independente contratado em condições de mercado.

A manutenção técnica da zona-raiz é ainda mais fragmentada. O Root Zone Maintainer Service Agreement distribui responsabilidades entre ICANN ou PTI e a Verisign e trata de níveis de serviço, controle de mudanças, segurança, desempenho e remédios contratuais. A existência desse acordo não significa que a ICANN seja a única participante da publicação da raiz, nem que tenha recebido poder geral sobre conteúdo, acesso ou serviços de Internet. O controle relevante pode estar dividido entre quem formula a política, quem autoriza uma mudança, quem executa a manutenção e quem possui um remédio contra a falha.

A função de números segue outra cadeia. O acordo de nível de serviço para os serviços IANA de numeração coloca os serviços em uma relação contratual envolvendo ICANN e os RIRs, enquanto a formulação de políticas de numeração provém do sistema regional. O SLA cobre os serviços IANA, não todas as decisões de alocação tomadas individualmente pelos RIRs. Para parâmetros de protocolo, o memorando entre IETF e ICANN distingue a formulação de políticas e padrões pela IETF do trabalho técnico de registro realizado como serviço IANA. Esses arranjos impedem que a transição seja descrita como concentração de toda a política de identificadores nas mãos da ICANN.

O ponto de controle muda conforme a consequência. Uma política pode ser bloqueada antes da adoção por um processo comunitário; depois da adoção, sua incorporação contratual pode condicionar a continuidade de uma relação; uma falha operacional pode ser enfrentada por níveis de serviço, escalonamento ou mudança técnica; e uma decisão do Board pode ser atacada por mecanismos corporativos de accountability. A pergunta analítica é: qual ator, sob qual instrumento, pode causar, bloquear, condicionar, atrasar, reverter ou reparar a consequência?

A ICANN publica vários canais que não devem ser tratados como equivalentes. O material de compliance, o processo de Reconsideration, o Independent Review Process, seus procedimentos suplementares, o Ombudsman, a Empowered Community, o Customer Standing Committee e as revisões da função IANA representam instâncias diferentes de resposta, revisão ou supervisão. O conjunto de fontes disponível não permite afirmar que tenham os mesmos requisitos de admissibilidade, padrões de revisão, poderes provisórios, força vinculante, alcance remedial, capacidade de execução, prazo ou custo.

Essa diferença é o núcleo do problema. Um canal pode oferecer uma resposta ou uma declaração sem suspender o ato que produz o dano. Outro pode alcançar uma decisão do Board, mas não ter poder direto para ordenar que uma contraparte técnica reabra um registro. Um procedimento pode ser formalmente acessível e ainda ser inútil para uma parte que não é signatária do contrato relevante. A existência de revisão não prova, portanto, a existência de reparação efetiva.

A questão do terceiro afetado é especialmente difícil. Contratos entre ICANN, registries, registrars, PTI, RIRs ou mantenedores podem produzir efeitos sobre registrantes, usuários, operadores e outras entidades que não assinaram o instrumento. A influência prática pode ser ampla, mas a posição processual não se expande automaticamente com ela. Para avaliar legitimidade institucional, é necessário perguntar se o terceiro consegue apresentar a objeção no foro adequado, se o foro pode alcançar o ato de implementação e se sua decisão pode ser imposta antes que o efeito se torne irreversível.

A fonte histórica da autoridade também não é suficiente para decidir o remédio atual. O contrato federal anterior explica uma camada da IANA antes da transição, mas não substitui os instrumentos pós-2016. Da mesma forma, a proposta de transição explica a arquitetura pretendida, mas não substitui o texto vigente dos contratos, SLAs, bylaws ou emendas. A análise deve separar desenho, texto operativo e prática documentada.

O pacote de evidências disponível ainda deixa lacunas importantes. As versões eficazes e os históricos de emendas dos documentos precisam ser confirmados. Falta reconstruir um procedimento concreto desde a proposta de política até sua adoção, incorporação contratual, ação de compliance ou execução técnica e tentativa de revisão. Também não estão estabelecidos, para cada canal, os requisitos de standing, a possibilidade de medida provisória, o padrão de análise, a força final, a execução, o tempo e o custo.

E o conjunto pesquisado é predominantemente composto por materiais hospedados pela própria ICANN; caracterizações controvertidas sobre poder regulatório público exigiriam legislação independente, decisões judiciais ou regulatórias e análise especializada externa.

Por isso, a melhor descrição da ICANN não é a de um governo mundial nem a de uma simples associação sem influência. Sua autoridade prática é composta. A carta e os bylaws fornecem capacidade e limites corporativos. Os processos multissetoriais dão forma às políticas. Os contratos transformam políticas em obrigações para participantes específicos. Os acordos técnicos repartem a execução entre entidades e serviços. Os mecanismos de accountability oferecem diferentes possibilidades de resposta, mas não necessariamente um caminho até cada superfície de controle.

O teste de legitimidade é, então, operacional: quando uma decisão produz um efeito contratual ou técnico, o afetado consegue identificar o instrumento que o autorizou, alcançar o ator que o executou, obter uma revisão antes da perda de valor e receber uma reparação vinculante e executável? Se a resposta for negativa, a instituição pode ser formalmente revisável e ainda assim praticamente não corrigível. Se for positiva apenas para a contraparte contratual, a arquitetura pode proteger a relação sem oferecer remédio equivalente ao terceiro afetado.

A investigação futura deve acompanhar um caso específico, e não apenas enumerar canais. O caso precisa mostrar a passagem entre regra, contrato, execução e contestação: quem tomou a decisão, quem tinha capacidade técnica de implementá-la, qual documento limitava essa capacidade, que revisão foi tentada e se o resultado alcançou o ato que causou o efeito. Só então será possível distinguir uma promessa de accountability de uma capacidade comprovada de impedir ou reparar dano.

Fontes

1 · 2 · 3 · 4 · 5 · 6 · 7 · 8 · 9 · 10 · 11 · 12 · 13 · 14 · 15 · 16 · 17 · 18 · 19

Para o registro do sujeito: ICANN no diretório BTW.