Resumo

  • Em 28 de agosto de 2026, a ICANN notificou a IPIP INC. de que seu Contrato de Credenciamento de Registradores seria encerrado com base na seção 5.5.4, com efeito em 13 de setembro.
  • O documento identifica quatro violações remanescentes: falhas no RDAP, depósitos de dados em custódia, taxas de credenciamento em atraso e ausência do link para o processo de solicitação de dados de registro não públicos.
  • Uma passagem seguinte chama outras questões de “preocupações adicionais”; transferência de nomes, revogação da licença da marca e deveres pós-encerramento formam ainda uma terceira classe.
  • Um quadro público de tratamento por item permitiria saber qual regra, evidência, prazo, resposta e decisão correspondem a cada questão, sem revelar comunicações privadas nem dados pessoais.

A precisão começa com dois verbos e duas datas

A ICANN tomou uma decisão em 28 de agosto. O encerramento previsto nessa decisão produz efeitos em 13 de setembro. Não são duas formas de dizer a mesma coisa.

O aviso dirigido à IPIP INC., registrador IANA número 3774, informa o encerramento do Contrato de Credenciamento de Registradores de 2013 nos termos da seção 5.5.4. Em seguida, fixa a eficácia para 13 de setembro, 16 dias corridos após a notificação, conforme a seção 5.6.

No corte factual deste artigo, 30 de agosto, há portanto uma decisão emitida e uma data futura. Ainda não constam do registro público o registrador receptor, a quantidade de nomes patrocinados, a data de uma transferência em massa nem uma confirmação de conclusão. O material também não registra arbitragem, suspensão dos efeitos, correção posterior ou saneamento aceito.

A página de avisos da ICANN liga a notificação de violação de 5 de agosto ao aviso de encerramento de 28 de agosto. Ela comprova a progressão do processo de fiscalização. Não comprova que cada etapa operacional decorrente já tenha ocorrido.

Quatro constatações, quatro superfícies de controle

O aviso afirma que as violações indicadas em 5 de agosto não foram sanadas até o prazo de 26 de agosto e enumera quatro que permaneceram abertas.

A primeira trata do RDAP Directory Service. Segundo a ICANN, a IPIP não mantinha um serviço que fornecesse os dados de registro exigidos para todos os nomes gTLD ativos sob seu patrocínio e que seguisse o guia de implementação e o perfil de resposta vigentes. O aviso anterior esclarece que a IPIP havia cadastrado uma URL-base, mas que as consultas de teste feitas pela ICANN não devolveram dados de registro.

A segunda diz respeito aos depósitos de dados do registrador em custódia: entregas tempestivas, no calendário, nos termos e no formato exigidos. A terceira é financeira: taxas de credenciamento vencidas. A quarta é informacional: faltava na página inicial um link direto ao mecanismo e ao processo para solicitar a divulgação de dados de registro não públicos.

Somar os quatro itens sob o rótulo geral de “compliance” não é falso, mas é pouco útil. O RDAP é um serviço público de consulta; a custódia de dados é uma medida de continuidade mantida por terceiro aprovado; as taxas são uma obrigação de pagamento; o link de divulgação é a porta pública para pedidos abrangidos pela seção 10.1 da Registration Data Policy. Evidência, parte afetada e forma de saneamento mudam de uma linha para outra.

As normas são verificáveis. A ICANN informa que o perfil gTLD RDAP de fevereiro de 2024 passou a ser obrigatório em 21 de agosto de 2025. A especificação de custódia de 2025 entrou em vigor na mesma data. A política de dados exige que a página de divulgação explique o formato do pedido, o método de resposta e o prazo previsto.

As constatações específicas sobre a IPIP, porém, continuam atribuídas à ICANN. O BTW não refez consultas sobre todo o universo de nomes patrocinados, não examinou a conta de custódia e não auditou faturas. A linguagem correta é: a ICANN registrou quatro violações remanescentes.

A mudança de substantivo importa

Depois dos quatro itens, o aviso abre outra passagem com “In addition” e afirma que a IPIP não resolveu “additional concerns”. A escolha de palavras delimita uma nova lista.

Nela aparecem a ausência de formulário público ou endereço dedicado para denúncias de abuso; o processo de recebimento, tratamento e acompanhamento dessas denúncias; nomes e cargos de dirigentes; endereço para correspondência; políticas de exclusão e renovação automática; taxas de restauração; métodos de envio dos avisos de renovação; e medidas corretivas prometidas com suas datas de implantação.

Nada disso é necessariamente secundário. Vários pontos se relacionam a deveres expressos de informação ou operação previstos no RAA. A designação “preocupação adicional” também não impede que uma questão se transforme em violação formal em outro momento. O limite é documental: neste aviso, a ICANN não colocou esses pontos na frase anterior que identificou as quatro violações remanescentes como base do encerramento.

Duas leituras seriam excessivas. A primeira diria que as preocupações não têm qualquer peso contratual. A segunda reclassificaria cada subitem como um fundamento independente já decidido no ato de encerramento. O texto público não sustenta nenhuma delas.

O aviso tampouco hierarquiza as quatro violações. A seção 5.5.4 permite o encerramento se o registrador não sanar qualquer violação dentro de 21 dias da notificação. O documento afirma que as quatro continuavam abertas, mas não diz qual delas teve peso decisivo, nem se uma delas, isoladamente, teria bastado. Uma manchete não deve criar a teoria causal que a autoridade não publicou.

Uma cronologia de procedimento, não uma biografia da empresa

Os avisos reúnem várias sequências de contato iniciadas em março e junho. A ICANN descreve notificações sucessivas ou escaladas, mensagens rejeitadas, ausência de resposta, telefonemas e uma resposta de 2 de abril considerada insuficiente. Em 5 de agosto, enviou a notificação formal por correio eletrônico e serviço expresso. A entrega física foi confirmada em 7 de agosto. Houve lembretes em 19 de agosto e o prazo encerrou-se em 26 de agosto. Dois dias depois, a ICANN declarou que o saneamento exigido não ocorrera.

Isso sustenta uma afirmação delimitada: a ICANN documentou tentativas de notificação, uma oportunidade de correção e sua avaliação do estado das respostas. A cronologia não explica por que mensagens foram recusadas ou ficaram sem retorno. Não prova abandono, insolvência, fraude, invasão de sistemas nem intenção de evitar supervisão.

Há boas razões para não publicar todo o dossiê. Uma entidade contratual pode exercer um poder expresso sem expor endereços pessoais, dados de clientes, detalhes de segurança ou aconselhamento jurídico interno. A economia do aviso, contudo, não obriga o público a misturar observações, pedidos de informação, violações formais, preocupações, efeitos e deveres sobreviventes.

Consequências não são novas violações

Na parte seguinte, o documento passa da razão para o que acontece depois. A ICANN afirma que seguirá o De-Accredited Registrar Transition Procedure para transferir os nomes administrados pela IPIP a um registrador credenciado qualificado. A licença para uso da marca ICANN será revogada em 13 de setembro. Permanecem obrigações relativas, entre outras, à retenção de dados de registro, a taxas, à solução de controvérsias e a limitações de reparações monetárias. Valores vencidos e outros montantes especificados continuam devidos.

Essas frases não aumentam a contagem de violações. Elas respondem a questões diferentes: como a carteira passa a outro operador, quando acaba a autorização de marca e quais cláusulas continuam produzindo efeitos após o fim do credenciamento.

O BTW já publicou análises específicas sobre a seleção de um registrador receptor e sobre a distância entre um arquivo em custódia e um serviço capaz de atender clientes. Repetir esse terreno eliminaria a novidade desta matéria. O ponto aqui é anterior: a arquitetura pública da decisão deixa claro o que foi constatado, o que ainda era uma preocupação e o que decorre do encerramento?

Um registro que preserve o tipo de cada item

A lista pública de avisos oferece bom acompanhamento por caso. Uma tabela de tratamento por item acrescentaria a granularidade necessária para que resumos futuros não transformem categorias.

Cada linha poderia conter um identificador; sua classe; a disposição exata de contrato, especificação ou política; uma fonte pública de evidência e data de observação; a correção ou informação solicitada; prazo e extensão; estado da resposta; decisão em cada aviso; papel declarado na medida atual; e eventual correção, contestação, arbitragem ou suspensão pública.

Depois do encerramento, a mesma linha indicaria o responsável pelo passo seguinte e a data de nova revisão. Uma violação pode ser encerrada, sobreviver como dívida, seguir para controvérsia ou deixar de influir na transferência. Uma preocupação pode ser respondida, formalizada posteriormente ou mantida apenas como nota histórica. A tabela mostraria a transição sem pedir ao leitor que a deduza de parágrafos separados.

Não seria necessário abrir mensagens privadas, nomes pessoais, registros técnicos brutos ou opiniões jurídicas. O que precisa de luz é a ligação entre classe, autoridade, evidência, decisão e responsável.

O ensaio de Heng Lu entra aqui somente como disciplina analítica. Poder institucional com efeitos altos deve permanecer ligado a autoridade identificável, evidência, responsabilidade e revisão. O poder da ICANN vem do contrato, não do ensaio. A contribuição do ensaio é recordar por que a recontagem pública não pode aumentar silenciosamente o alcance do poder ou das constatações.

A conclusão imediata é contida. A ICANN emitiu uma notificação de encerramento contra a IPIP. Identificou quatro violações não sanadas. Registrou outras preocupações em separado. A eficácia está prevista para uma data futura. O relato responsável começa por não transformar essas classes em uma só acusação indiferenciada.

Fontes

  1. ICANN — Aviso de encerramento à IPIP INC., 28 de agosto de 2026
  2. ICANN — Aviso de violação à IPIP INC., 5 de agosto de 2026
  3. ICANN — Avisos de violação, suspensão, encerramento e não renovação
  4. ICANN — Contrato de Credenciamento de Registradores e materiais relacionados
  5. ICANN — Registration Data Policy
  6. ICANN — Perfil gTLD RDAP
  7. ICANN — Programa de custódia de dados de registradores
  8. ICANN — Abordagem e processos de Contractual Compliance
  9. ICANN — Encerramento de um credenciamento
  10. ICANN — De-Accredited Registrar Transition Procedure
  11. Heng Lu — Quando o poder de registro se separa da responsabilidade