Resumo
- A ICANN é uma corporação californiana sem fins lucrativos, não um regulador estatal geral; sua missão e seus limites estão nos Articles of Incorporation e nos Bylaws (Articles of Incorporation; Bylaws).
- Seu poder prático aparece sobretudo em contratos com registros e registradores, enquanto a IANA executa funções operacionais delegadas e os mecanismos de reconsideração, Independent Review e Ombudsman oferecem recursos procedimentais, não um recurso geral sobre o mérito de qualquer decisão.
A pergunta correta sobre a ICANN não é se ela “controla a Internet”, mas qual instrumento autoriza cada ato e contra quem esse instrumento pode ser aplicado. Essa distinção separa coordenação técnica, governança corporativa, obrigação contratual e autoridade pública.
1. A fonte inicial é corporativa, não soberana
Os Articles of Incorporation descrevem a ICANN como uma corporação californiana sem fins lucrativos de benefício público, organizada para fins caritativos e públicos. O documento conecta o propósito corporativo à missão prevista nos Bylaws, mas não cria, por si só, o conjunto detalhado de poderes contratuais e operacionais usado no sistema de nomes (Articles of Incorporation).
Os Bylaws definem uma missão centrada na coordenação dos identificadores únicos da Internet e limitam a atuação da organização a essa missão. Também restringem a possibilidade de regular serviços que usam identificadores únicos ou o conteúdo transportado por esses serviços, salvo dentro da missão e de exceções especificadas (Bylaws). Portanto, a ICANN não deve ser descrita como uma autoridade geral sobre serviços on-line, conteúdo ou usuários da Internet.
A governança pós-transição inclui Conselho, Supporting Organizations, Advisory Committees, Empowered Community, reconsideração e Independent Review. Esses mecanismos fazem parte da arquitetura institucional, mas sua existência não transforma a ICANN em um tribunal ou em um órgão legislativo (Bylaws).
2. A transição da IANA mudou a supervisão, não criou soberania
A Affirmation of Commitments de 2009 foi um instrumento bilateral entre a ICANN e o Departamento de Comércio dos Estados Unidos. Ela estabeleceu revisões recorrentes sobre prestação de contas, transparência, segurança e estabilidade, concorrência, confiança do consumidor e serviços de diretório de registros (Affirmation of Commitments).
Depois da transição da supervisão da IANA, a NTIA e a ICANN encerraram a Affirmation; compromissos relevantes de prestação de contas e revisão foram incorporados aos Bylaws revisados (terminação da Affirmation). A transição não transferiu a “propriedade da Internet” nem concedeu à ICANN jurisdição regulatória geral.
O anúncio da NTIA de 2014 iniciou um processo e exigiu proteção do modelo multissetorial, da segurança, estabilidade, resiliência e abertura do DNS. Ele não foi, sozinho, o instrumento jurídico final da transição (anúncio da NTIA de 2014). Em 2016, a expiração do contrato das funções IANA encerrou o papel contratual de supervisão da NTIA, deixando a operação e a prestação de contas nas estruturas envolvendo ICANN, PTI e as comunidades operacionais pertinentes (declaração da NTIA de 2016).
O desenho da transição separou desenvolvimento de políticas e desempenho operacional nas comunidades de nomes, números e parâmetros de protocolo. Para nomes, previu a PTI como afiliada juridicamente separada da ICANN, acompanhada por contrato, níveis de serviço, comitê de clientes, revisões e possibilidade de separação (proposta de transição; proposta de accountability). A proposta explica a arquitetura, mas os Bylaws e contratos adotados são os instrumentos operativos.
3. A IANA opera funções delegadas; não define sozinha todas as políticas
A IANA descreve funções operacionais que incluem coordenação da zona raiz do DNS, alocação de recursos de números da Internet e manutenção de registros de parâmetros de protocolo. Essas funções são desempenhadas pela PTI, uma afiliada da ICANN (About IANA; PTI).
O contrato da função de nomes da IANA delega à PTI operações de nomes e estabelece obrigações de desempenho, relatórios, níveis de serviço, auditoria, escalonamento e subcontratação. O contrato não cria, por si só, autoridade para formular políticas de nomes (IANA Naming Function Contract).
A distinção também aparece nos parâmetros de protocolo: a RFC 2860 separa a administração dos registros IANA do desenvolvimento de políticas técnicas pelo processo da IETF (RFC 2860). No sistema de números, o acordo de nível de serviço com os registros regionais preserva a função da comunidade dos RIRs na formulação de políticas globais e estrutura o desempenho operacional da IANA/PTI (IANA Numbering Services SLA).
4. Contratos são a principal superfície de controle sobre registros e registradores
As obrigações dos operadores de gTLDs surgem de contratos individuais, e os termos variam conforme o tipo de registro e o arranjo aplicável (Registry Agreements). O Base Registry Agreement constitui uma importante superfície contratual sobre muitos novos gTLDs: cobre políticas, escrow, exigências técnicas e de segurança, auditorias, inadimplemento, suspensão, rescisão e resolução de disputas (Base Registry Agreement).
Essa autoridade é substancial, mas limitada. As especificações sobre Consensus Policies e Temporary Policies delimitam os assuntos nos quais políticas podem vincular o operador. O contrato, os Bylaws, as políticas incorporadas e as disposições de disputa formam conjuntamente o limite da execução. O Base Registry Agreement não deve ser generalizado para todos os gTLDs, muito menos para todos os ccTLDs.
A Registrar Accreditation Agreement impõe deveres contratuais sobre políticas, serviços de dados de registro, retenção e escrow, contatos de abuso, supervisão de revendedores, auditorias, investigações de compliance e suspensão ou rescisão (Registrar Accreditation Agreement). Mas os registrantes normalmente contratam com registradores ou revendedores, não diretamente com a ICANN. Isso reduz os recursos contratuais diretos da ICANN contra usuários finais.
As relações com administradores de ccTLDs são mais heterogêneas e podem assumir a forma de acordos de patrocínio, estruturas de accountability ou cartas de entendimento. Por isso, o contrato-base de gTLD não é uma fonte universal de autoridade sobre todos os operadores de TLDs (relações com ccTLDs).
5. Os recursos existem, mas não formam um recurso geral
Compliance, reconsideração, Independent Review, Ombudsman e revisões institucionais são canais distintos (Compliance; Reconsideration; Independent Review; procedimentos do IRP; Ombudsman; revisões).
Reconsideração alcança atos especificados do Conselho ou da equipe e depende de requisitos procedimentais. Independent Review examina questões de governança dentro do escopo de suas regras; não funciona como uma apelação universal sobre qualquer conflito contratual ou político. O Ombudsman oferece uma via de justiça institucional e tratamento imparcial, mas sua análise não equivale a uma sentença judicial.
A consequência prática é importante: uma contestação pode registrar que uma decisão foi reconsiderada, examinada ou objeto de mediação sem necessariamente alterar o resultado. A força do recurso depende de quatro perguntas: quem tomou a decisão, qual instrumento é contestado, qual remédio está disponível e se esse remédio pode produzir uma mudança vinculante ou apenas uma recomendação.
6. A tensão institucional
A autoridade da ICANN depende de relações institucionais e contratuais executáveis, enquanto seus próprios instrumentos rejeitam uma missão regulatória geral. Sua legitimidade, portanto, depende da rastreabilidade do poder: a decisão deve apontar para uma missão, uma regra interna, um contrato ou uma obrigação operacional delegada.
O mesmo vale para os recursos. Um sistema de accountability é mais do que uma lista de canais quando o desafiante consegue identificar a porta correta e quando o procedimento pode afetar o resultado. Se o mecanismo apenas registra desacordo depois que a obrigação contratual ou a decisão operacional se consolidou, sua função é de transparência e disciplina institucional, não de revisão plena do mérito.
As fontes reunidas para este briefing incluem páginas e documentos oficiais, mas versões atuais, emendas, datas de vigência e formulações citadas devem ser verificadas antes de serem usadas para uma conclusão jurídica específica.
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Apenas para Strategic Circle
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance

