Resumo
- As cartas da ICANN de junho e julho de 2025 dirigidas ao administrador judicial da AFRINIC alertavam que uma revisão de conformidade poderia ser necessária, ligavam as irregularidades eleitorais e as preocupações com os registros às obrigações da ICP-2, e exigiam respostas fundamentadas. Era um aviso de reconhecimento, não um plano de substituição completo.
- A regra ausente não diz respeito apenas a quem pode ser um operador de emergência. Ela define como os serviços de registro, a autoridade dos membros, os registros, o material RPKI, o DNS reverso, as transferências, a cobrança, os dados confidenciais, os litígios e as restrições judiciais são transferidos durante uma emergência sem prejudicar os detentores de recursos comuns.
- Uma regra de substituição deve exigir gatilhos definidos, consentimento do operador, escopo dos serviços, sequestro de dados, testes de portabilidade, aviso público, contribuição da comunidade, limites de tempo, retrocessão, revisão independente e relatório pós-evento antes que uma ameaça de reconhecimento possa ser convertida em uma transição de serviço.
Uma ameaça sem ponto de recepção
A frase mais importante após a falha de um registro não é 'o registro está em revisão'. É 'aqui é onde o serviço funcionará amanhã'. Uma região pode sobreviver a um conflito de conselho de administração, a um processo judicial, a uma eleição atrasada ou mesmo a um administrador provisório se os dados de registro, os serviços de suporte, o DNS reverso, o RPKI, os registros de consulta públicos, as transferências, a cobrança e as comunicações com os membros permanecerem estáveis. Ela se torna frágil quando a revisão de reconhecimento é mencionada sem um ponto de recepção visível para a função pública.
A AFRINIC tornou essa distinção inevitável. Em junho de 2025, o registro regional africano já estava atolado há anos em uma crise jurídica e de governança. Os tribunais de Maurício haviam nomeado um administrador judicial. O registro carecia de governança ordinária por um conselho de administração. Uma eleição destinada a restabelecer o conselho foi suspensa e depois cancelada após alegações sobre poderes de voto e procurações. A ICANN então escreveu ao administrador nomeado e notificou a AFRINIC de que uma revisão de conformidade poderia ser necessária.
O aviso não foi trivial. Na correspondência de25 de junho de 2025, a ICANN vinculou as alegações às obrigações decorrentes do ICP-2, fez treze perguntas detalhadas, exigiu uma resposta fundamentada em um dia, solicitou a preservação dos registros e declarou que a situação poderia levantar sérias questões sobre a capacidade da AFRINIC de continuar agindo como uma entidade capaz de gerenciar de forma responsável os recursos de numeração. Na correspondência de3 de julho de 2025, a ICANN declarou que o cancelamento da eleição não respondia a muitas de suas perguntas e novamente se reservou todos os direitos de iniciar uma revisão.
Essa correspondência tinha um motivo legítimo de continuidade. Um registro regional não é uma associação privada comum. Ele mantém uma superfície de dependência pública para os registros de endereços e sistemas autônomos. Se um processo eleitoral é comprometido ou se os registros não são preservados, os danos podem ir muito além das pessoas que lutam nos tribunais. A ICANN estava certa em fazer perguntas sobre o apoio aos membros, igualdade de tratamento, imparcialidade, independência e salvaguardas dos registros.
Mas o aviso também revelou a regra de substituição ausente. Se a ICANN tivesse passado do aviso para uma revisão formal, e se essa revisão tivesse revelado não conformidade significativa, o que aconteceria exatamente em seguida? A AFRINIC perderia imediatamente seu reconhecimento? Outro RIR operaria apenas os serviços técnicos? O administrador permaneceria no cargo? Os membros continuariam a pagar a AFRINIC? As transferências continuariam? Os certificados RPKI permaneceriam válidos? As modificações no DNS reverso seriam processadas? Os registros confidenciais seriam copiados para um operador temporário?
As ordens judiciais nacionais vinculariam esse operador? Os detentores de recursos teriam uma maneira de contestar uma transferência errônea de seus arquivos?
A resposta pública não foi clara o suficiente. As reportagens da imprensa na época captaram o risco. The Register noticiou em 26 de junho de 2025 que a carta da ICANN alertava sobre uma possível revisão de conformidade e que, se a AFRINIC falhasse nessa revisão, a ICANN poderia pedir a outro RIR que interviesse como registro de emergência para a África. Essa frase é uma ideia poderosa. No entanto, não é um procedimento. Uma regra de substituição confiável não pode ser uma explicação jornalística de um possível suporte de emergência. Ela deve ser um documento que os operadores possam executar e que os membros possam testar.
O problema não é que a substituição de emergência deva ser impossível. O problema é que ela deve ser difícil, restrita e predefinida. Um operador temporário pode preservar o serviço se a entidade jurídica atual não puder fazê-lo. O mesmo operador temporário pode criar uma crise de legitimidade se a seleção, o consentimento, a transferência de dados, o escopo, o limite de tempo e a retrocessão forem vagos. Em uma região já desconfiada do poder externo, 'outro RIR intervirá' pode parecer menos uma continuidade do que um deslocamento, a menos que a regra seja explícita.
O ponto de recepção deve, portanto, ser identificado antes que a ameaça seja usada. Não necessariamente nomeando um sucessor permanente com antecedência, mas definindo que tipo de entidade pode servir, quem deve concordar, quais serviços ela pode operar, quais dados pode receber, o que ela não pode decidir, por quanto tempo pode agir e como a comunidade afetada é ouvida. A revisão de reconhecimento sem regra de substituição é metade de uma ponte sobre um rio profundo.
A crise eleitoral tornou a continuidade uma questão prática
A crise da eleição do conselho de administração da AFRINIC não era simplesmente um assunto interno da associação. O conselho de administração de um registro regional controla os orçamentos, a nomeação de dirigentes, a supervisão, a postura jurídica, a responsabilidade dos membros e o ambiente de confiança em torno dos serviços técnicos. Uma eleição contestada pode, portanto, se tornar um problema de serviço de registro, mesmo que os servidores de banco de dados continuem respondendo.
A questão da eleição de junho de 2025 tinha várias facetas. A ICANN descreveu relatos de que os membros enfrentavam dificuldades de inscrição. Ela descreveu uma diferença entre os limites ordinários das procurações e os poderes de voto presenciais. Ela relatou que algumas procurações haviam sido obtidas fraudulentamente ou depositadas sem autorização. Ela perguntou se as listas de membros votantes autorizados haviam sido compartilhadas externamente e se um terceiro havia sido autorizado a usar o logotipo da AFRINIC em comunicações de apoio a candidatos.
Ela também perguntou sobre o estado da conservação dos registros e dos backups dos dados de registro e dos arquivos dos membros.
Essas perguntas mostram por que a integridade eleitoral e a continuidade do serviço estão ligadas. Uma procuração falsificada não é a mesma coisa que uma transferência de recursos corrompida, mas ambas dependem da capacidade da instituição de reconhecer quem pode vincular um membro. Uma lista de membros divulgada não é a mesma coisa que uma corrupção de banco de dados, mas sugere uma fraqueza de controle em torno de informações confidenciais ou sensíveis dos membros. Uma investigação pouco clara não é a mesma coisa que uma falha de serviço, mas enfraquece a confiança de que as decisões futuras serão imparciais e documentadas.
Ao mesmo tempo, o vínculo tem limites. Uma eleição ruim não significa automaticamente que cada registro de endereço não é confiável. Um voto cancelado não exige automaticamente um novo registro. Uma comunicação ruim do administrador não significa necessariamente que o serviço de suporte não possa processar tickets de rotina. Um vazio temporário no conselho de administração não justifica necessariamente a transferência de arquivos confidenciais para outra organização. A regra de substituição deve respeitar essas distinções.
É aí que muitos argumentos de crise falham. Um lado diz que a continuidade exige deixar o operador atual em paz, porque qualquer intervenção externa corre o risco de desestabilizar os serviços. O outro lado diz que a falha de governança prova que o operador atual deve ser substituído. Nenhuma das duas respostas é suficientemente precisa. A continuidade exige um mapeamento de serviços. Quais serviços estão funcionando? Quais serviços estão em risco? Quais decisões estão contaminadas pela falha de governança? Quais registros precisam de preservação independente? Quais direitos dos membros devem ser verificados?
Quais mudanças podem continuar com segurança? Quais mudanças devem ser suspensas?
Para a AFRINIC, um mapeamento de serviços incluiria os dados públicos de registro, os arquivos de contas e membros não públicos, as delegações de DNS reverso, o estado da certificação de recursos, as transferências pendentes, a cobrança, as comunicações com os membros, os arquivos de autoridade da empresa, os registros de políticas, as filas do serviço de suporte, as ordens judiciais, os contratos com fornecedores, o acesso a bancos e os identificadores.
Incluiria também as dependências que outros atores usam para se apoiar nos registros da AFRINIC: integração em nuvem, filtros de roteamento, due diligence, compras públicas e pareceres jurídicos em transações de endereços.
O NRO reconheceu a continuidade desde a nomeação do administrador. Suadeclaração de 14 de setembro de 2023saudou o administrador como um caminho para uma governança funcional e afirmou que a nomeação ajudaria a garantir que os membros continuassem recebendo os serviços de registro. Esse era o quadro correto: preservar os serviços enquanto a governança é restabelecida. Mas uma crise prolongada transforma a preservação temporária em uma questão mais difícil. Se a própria preservação falhar, quem assume apenas as partes que precisam continuar?
A regra deve ser capaz de responder sem dramatizar cada falha como uma substituição. Ela deve começar pela triagem dos serviços, e não pela condenação institucional.
O serviço de emergência não é uma governança de sucessão
Um operador de emergência não é um novo governo regional. Deve ser um provedor de serviços temporário com autoridade estritamente limitada. Ele pode operar um serviço de suporte, manter os registros atualizados, processar as mudanças de rotina definidas, preservar a continuidade do DNS reverso e do RPKI, reter dados com segurança e relatar indicadores de serviço. Não deve reescrever a política regional, reestruturar os direitos dos membros, resolver litígios privados sobre recursos, tomar partido em eleições ou se tornar a instituição de serviços permanente por padrão.
O projeto de documento de governança de RIR versão 2 do NRO está alinhado com essa distinção. Ele define um operador de emergência como uma entidade qualificada selecionada para fornecer temporariamente serviços de RIR. Indica que a continuidade de emergência pode ser acionada quando um RIR não consegue fornecer adequadamente todos ou parte de seus serviços.
Exige o acordo unânime de todos os outros RIRs e da ICANN, uma discussão com o RIR afetado e sua comunidade na medida do possível, a publicação rápida da justificativa e do escopo, participação da comunidade, cooperação durante a transição, o direito do RIR afetado de retomar os serviços uma vez que a capacidade seja restabelecida e verificada, e um limite inicial de noventa dias, renovável sob a mesma seção.
Esse quadro é útil porque rejeita a ideia de que a substituição é apenas uma tomada de controle institucional. Trata o serviço de emergência como temporário, delimitado e revisável. Também exige uma revisão pós-evento, incluindo um relatório público sobre as circunstâncias, os serviços prestados, a duração, o processo de retorno, o desempenho do operador, o feedback e as melhorias.
Os detalhes continuam decisivos. A operação temporária sempre requer identificadores, registros, conhecimento da equipe, procedimentos, limites de proteção de dados, autoridade para responder a solicitações, expectativas de nível de serviço e regras de conflito. Se esses não estiverem preparados, um operador de emergência pode estar tecnicamente disposto, mas praticamente cego.
Pode não ter uma cópia atualizada dos arquivos de autoridade dos membros, estado validado das transferências pendentes, meios seguros de assinar ou modificar elementos de certificação de recursos, conhecimento de contas sujeitas a restrições judiciais e meios de verificar quem pode lhe dar instruções.
O operador de emergência também precisa de um mandato de não governança. Deve ser capaz de processar uma atualização de contato de rotina se a autoridade do membro for verificada. Não deve decidir se um candidato contestado ao conselho de administração foi legalmente excluído. Deve ser capaz de preservar o estado de uma transferência pendente. Não deve julgar os méritos comerciais da transferência se o registro atual não tomou uma decisão. Deve ser capaz de manter as delegações de DNS reverso ativas. Não deve impor uma nova política regional de DNS reverso. Deve ser capaz de publicar uma página de status.
Não deve fazer campanha para uma facção de governança.
A crise da AFRINIC é precisamente o caso em que esse limite seria importante. Se outro RIR tivesse sido convidado a fornecer serviços de emergência, os membros africanos perguntariam razoavelmente se esse RIR estava apenas mantendo a função utilitária ou absorvendo a autoridade regional. Os tribunais de Maurício perguntariam se o operador temporário respeitava as ordens locais. Os outros RIRs perguntariam se estavam assumindo responsabilidade pelos registros contestados. Os detentores de recursos perguntariam se seus registros confidenciais haviam sido movidos e com que base jurídica.
A regra deve estipular que o serviço de emergência não é uma governança de sucessão. A questão da governança de sucessão pode surgir posteriormente em caso de perda de reconhecimento, mas não deve ser introduzida clandestinamente em uma ponte de serviço de noventa dias. Essa ponte deve manter as luzes acesas, preservar as evidências, evitar danos irreversíveis e ganhar tempo para uma restauração legal ou para uma transição justificada separadamente.
O consentimento do operador não pode ser presumido
A frase 'outro RIR poderia intervir' esconde um problema difícil de consentimento. Um registro regional não é uma instância de nuvem reserva. É uma entidade jurídica com seu próprio conselho de administração, seus membros, suas leis, seu apetite por risco, suas capacidades de pessoal, seu orçamento, seus seguros, suas obrigações de proteção de dados e sua responsabilidade regional. Pedir a ele que opere serviços para outra região durante uma crise levanta riscos operacionais e políticos.
O operador deve consentir de forma informada. Deve entender o escopo dos serviços, os registros a receber, as restrições legais, o financiamento, a indenização, as obrigações de confidencialidade, as tarefas técnicas, as necessidades linguísticas, os limites de tempo, as obrigações de relatório e as condições de saída. Deve saber se deve fornecer apenas continuidade técnica ou gerenciar decisões voltadas para os membros. Deve saber se seus próprios membros arcarão com os custos. Deve saber se a região afetada pode contestar suas ações.
O consentimento dos outros RIRs também conta coletivamente. O projeto do NRO exige o acordo unânime de todos os outros RIRs e da ICANN para a continuidade de emergência. É uma salvaguarda sólida. Reduz o risco de um ator externo poder instalar um operador favorecido. Também obriga o sistema a confrontar a capacidade e a legitimidade antes de agir.
Mas a unanimidade tem um custo. Em uma falha rápida, obter acordo unânime pode ser lento. Em um caso politicamente carregado, um RIR pode hesitar devido à responsabilidade ou reputação. A regra deve, portanto, distinguir a preparação da ativação. A preparação pode ser feita com antecedência: inventário de serviços, expectativas de sequestro, condições padrão de confidencialidade, qualificações de operadores temporários, fórmulas de financiamento, modelos de comunicação, listas de verificação legais e testes. A ativação pode então ser mais restrita e mais rápida porque os atores não estão inventando as condições sob pressão.
O consentimento do registro afetado é mais complicado. Se o registro puder cooperar adequadamente, o suporte de emergência deve ser discutido com ele e sua comunidade. Se o registro for incapaz de cooperar devido a paralisia de governança, restrição judicial ou má-fé, a regra pode exigir um caminho sem consentimento total do operador atual. Mas esse caminho deve ser excepcional e explicado. Deve identificar por que a cooperação não foi razoavelmente possível, com que base legal a transição limitada é autorizada e como o registro afetado pode retomar os serviços assim que a capacidade for restabelecida.
O consentimento dos membros também não é monolítico. Os membros da região afetada não falam com uma só voz. Alguns podem temer o operador atual, alguns podem temer o controle externo, alguns podem querer uma restauração rápida do serviço, alguns podem ser litigantes, e muitos podem simplesmente precisar de estabilidade de rotina. Uma regra que exija consenso regional total tornaria a ação de emergência impossível. Uma regra que ignore os pontos de vista dos membros careceria de legitimidade.
A melhor resposta é uma contribuição estruturada: um aviso, breves janelas de feedback quando possível, canais protegidos para evidências, um resumo publicado das preocupações e uma revisão pós-evento.
Na AFRINIC, o consentimento do operador e a legitimidade dos membros seriam particularmente sensíveis porque a crise já envolvia alegações sobre poderes de voto, procurações e listas de membros. Qualquer operador de emergência deve evitar depender dos mesmos arquivos de autoridade contestados sem verificação. Também precisaria de um plano de comunicação que alcance os membros diretamente por meio dos contatos mantidos, protegendo ao mesmo tempo a confidencialidade.
O consentimento não é, portanto, uma assinatura cerimonial. É a diferença entre a continuidade do serviço e a ocupação contestada. A regra de substituição deve tratá-lo como uma infraestrutura.
A portabilidade dos registros é o ativo central
A coisa mais importante que se move em uma emergência de registro não é a marca, o escritório ou as atas do conselho de administração. É o estado atual dos registros. Se os registros estiverem incompletos, desatualizados, contestados, não portáveis ou juridicamente inacessíveis, nenhum operador de emergência pode fornecer um serviço crível. Ele herdará uma névoa.
A portabilidade dos registros tem várias camadas. A camada pública inclui as entradas de registro visíveis pelos serviços de diretório, as atribuições e alocações de recursos, as funções de contato, as referências relacionadas ao roteamento e as delegações de DNS reverso. A camada protegida inclui os identificadores de conta, as provas de autoridade, os arquivos dos membros, os registros de cobrança, os documentos jurídicos, as verificações de identidade, os contatos não públicos, os tickets pendentes, as provas de transferência, os arquivos de litígio e as restrições judiciais.
A camada de confiança técnica inclui o material de certificação de recursos, o estado do repositório, os acordos de assinatura, os detalhes de zona reversa e os identificadores operacionais. A camada de governança inclui o status dos membros, a autoridade de voto, os registros do conselho e comitês, os documentos de política e o histórico de decisões.
Cada camada tem um problema de portabilidade diferente. Os dados públicos podem ser copiados, mas podem não indicar quem pode ordenar modificações. Os dados protegidos podem ser necessários, mas devem ser tratados respeitando as regras de confidencialidade e proteção de dados. O material de confiança técnica pode exigir gerenciamento cuidadoso de chaves e do repositório; um movimento descuidado pode quebrar a validação ou criar autoridade duplicada. Os registros de governança podem ser contestados; movê-los sem anotação pode transformar uma autoridade contestada em fato aceito.
O texto do ICP-2 de 2001 já reconhecia a manutenção de registros como essencial. Exigia registros apropriados das atividades do registro e o arquivamento das informações coletadas dos LIRs durante a alocação de espaços de endereçamento, descrevendo esses dados como necessários para a avaliação futura e a verificabilidade de operações neutras responsáveis. Essa exigência não foi redigida como uma regra de portabilidade completa, mas indica a verdade central: a continuidade do registro depende de registros que possam ser auditados.
A carta da ICANN de 2025 à AFRINIC pedia ao administrador que confirmasse o estado da conservação dos registros e dos backups dos dados de registro e dos arquivos dos membros. Essa questão está no centro de qualquer regra de substituição. Se os backups forem mantidos apenas dentro da instituição em dificuldade, a continuidade de emergência pode ser impossível. Se os backups existirem mas não puderem ser usados legalmente, a continuidade é teórica. Se os backups estiverem atualizados mas faltarem provas de autoridade, as consultas de rotina podem continuar enquanto as ações dos membros se tornam perigosas.
A portabilidade deve ser testada antes da crise. Um registro deve ser capaz de produzir um inventário de serviços e um conjunto de sequestro criptografado atualizado sob controles claros. O conjunto de sequestro não deve ser um dump de dados públicos. Deve ser suficientemente estruturado para que um operador de emergência possa identificar os registros públicos atuais, as mudanças pendentes, os arquivos de autoridade, as categorias de confidencialidade, o material de confiança técnica, o estado do DNS reverso, os tickets de serviço e os litígios. Deve ser testado para restauração em um ambiente controlado.
O teste não é a mesma coisa que o uso. Um operador de emergência não precisa acessar os registros confidenciais em tempos normais. Mas um auditor independente pode verificar se o sequestro existe, se está atualizado, se os controles de acesso estão funcionais e se uma restauração seria possível se o gatilho ocorrer. O relatório pode publicar categorias de sucesso, falha e exceção sem expor os segredos dos membros.
A AFRINIC mostrou por que isso não é abstrato. Uma crise envolvendo autoridade de voto, possível acesso a listas e backups de registros levanta imediatamente a questão de saber se o estado dos registros é suficientemente confiável para ser movido. Uma regra de substituição deve dizer como os registros contestados são transferidos: com anotação, congelamento, validação independente ou exclusão da ação de rotina até resolução. Deve impedir que uma transferência lave uma autoridade incerta em um estado operacional limpo.
A portabilidade dos registros é, portanto, o ativo central da substituição. Sem ela, o operador de emergência é apenas um nome. Com ela, a substituição se torna um ato de preservação disciplinado, em vez de um ato político.
O estado dos dados deve viajar antes da autoridade
A autoridade deve seguir o estado dos dados, não precedê-lo. Em uma emergência de registro, o sistema deve primeiro definir o estado do serviço a ser preservado, depois decidir qual operador pode legal e tecnicamente preservá-lo. Se a autoridade for movida primeiro, o novo operador pode ser forçado a tomar decisões sem saber o que controla.
Um dossiê de migração deve conter um mapeamento atual dos serviços. Deve listar os serviços de registro públicos, os arquivos não públicos dos membros e detentores de recursos, os serviços de confiança técnica, as responsabilidades de DNS reverso, as solicitações pendentes, os litígios em andamento, as ordens judiciais, as dependências de pessoal e fornecedores, os identificadores, o monitoramento, o estado dos backups e os canais de comunicação. Para cada categoria, deve indicar se o serviço não é afetado, está em risco, congelado, restrito, contestado ou indisponível.
O dossiê também deve identificar os estados das transações. As transferências pendentes são particularmente sensíveis. Uma transferência pode ser solicitada, em análise, aguardando provas, aprovada mas não finalizada, contestada, bloqueada por uma ordem judicial ou atrasada por taxas. Se esses estados forem perdidos, os compradores e vendedores podem enfrentar duplo depósito, promessas contraditórias ou perda de prioridade. Um operador temporário não deve ter que deduzir o estado a partir de fragmentos de e-mails.
O RPKI e o DNS reverso exigem seus próprios dossiês de transição. Para a certificação de recursos, o operador deve conhecer as relações de autoridade de certificação, os pontos de publicação, o estado do repositório, os ROAs, as expectativas de validação e os limites de revogação de emergência. Para o DNS reverso, o operador deve conhecer as delegações de zona pai, os registros DS, se houver, o estado dos servidores de nomes e as modificações pendentes. Esses serviços podem afetar a segurança do roteamento, a reputação do e-mail, os diagnósticos de rede e a integração em nuvem.
Eles não podem ser transferidos apenas por uma linguagem geral de negócios.
A cobrança e a situação dos membros também importam. Se os membros precisam continuar pagando para preservar o serviço, eles devem saber para quem pagar e como os pagamentos são creditados. Se a situação regular de um membro for contestada porque contas bancárias foram congeladas ou faturas atrasadas, um operador temporário não deve transformar essa incerteza em perda de direitos de voto ou serviço sem revisão.
O dossiê de migração deve preservar o contexto jurídico. As ordens judiciais nacionais podem restringir ativos, decisões de governança, comunicações ou ações sobre recursos. O operador de emergência deve saber quais ordens existem e como elas afetam o serviço. Não deve presumir que uma decisão da ICANN ou do NRO anule o direito local. Uma ordem local também não deve ser interpretada como destruindo a continuidade do serviço global quando uma conformidade mais restrita estiver disponível.
A regra deve definir um ponto de congelamento. No momento em que a continuidade de emergência começa, as mudanças ordinárias podem exigir uma breve pausa controlada enquanto o estado é reconciliado. A pausa deve ser curta e publicada. As mudanças de emergência que impedem a perda de serviço devem permanecer possíveis. Uma vez confirmado o estado, os serviços de rotina de baixo risco devem retomar sob o mandato limitado do operador temporário.
É por isso que a regra de substituição não pode ser apenas jurídica. Ela é operacional. É um procedimento para mover um sistema de registro vivo sem perder o presente. A regra deve ser testada como um exercício de emergência. Se os atores não conseguirem reconstituir o estado atual durante um teste, não podem prometer continuidade em caso de crise.
Os membros precisam de um procedimento de migração, não de um slogan
Para os membros e detentores de recursos, a substituição se traduz em uma sequência de perguntas práticas. Onde devo fazer login? Quem pode assinar? Minha fatura conta? Posso atualizar um contato de abuso? Posso modificar uma delegação de DNS reverso? Meu estado RPKI é válido? Uma transferência pendente pode ser concluída? Meus documentos confidenciais serão movidos? Qual lei protege meus dados? O que acontece se o registro antigo e o operador temporário derem respostas diferentes?
Uma regra de substituição deve responder a essas perguntas com antecedência. O aviso público deve indicar o operador de emergência, a hora de início, o escopo dos serviços, os serviços não afetados, os serviços suspensos, os contatos de emergência, o método de autenticação dos membros, o resumo da proteção de dados, a marcação de litígios, o tratamento da cobrança, a duração prevista e a via de recurso. Deve evitar afirmações gerais de resgate institucional e focar na continuidade do serviço.
A autenticação merece atenção especial. Se a crise envolver autoridade de membro contestada, o operador temporário não pode confiar cegamente nos usuários existentes do portal ou nas procurações. Deve usar um método de verificação em camadas: registros atuais do registro, contatos previamente verificados, provas de autoridade corporativa, se necessário, confirmação multicontato para mudanças de alto risco e indicadores de litígio quando a autoridade for contestada. Correções públicas de baixo risco podem exigir provas mais leves. Transferências de alto risco ou modificações na confiança técnica exigem provas mais sólidas.
O procedimento deve preservar os direitos existentes sem estendê-los. Um detentor de recursos não deve adquirir um direito de transferência simplesmente porque a continuidade de emergência começa. Também não deve perder um serviço reconhecido apenas porque a governança está em revisão. O operador temporário deve manter o status quo dos registros, a menos que uma mudança definida e verificada seja autorizada. Esse status quo deve incluir a marcação de litígios quando o registro for contestado.
As comunicações devem ser diretas e multilíngues quando a região exigir. Uma crise na região da AFRINIC abrange muitos países, sistemas jurídicos e comunidades de operadores. O inglês pode continuar sendo o idioma oficial do sistema de registro para a revisão principal, mas a continuidade voltada para os membros exige avisos claros e acessíveis. A regra deve definir canais mínimos de comunicação: aviso no site, e-mail direto para contatos verificados, página de status pública, instruções do serviço de suporte e relatórios periódicos.
Os membros também precisam de uma maneira de enviar evidências. Se o arquivo de contato de um membro estiver errado, se uma solicitação pendente estiver faltando, se uma procuração for falsificada, se um estado de transferência estiver mal registrado ou se uma ordem judicial afetar seus recursos, o operador temporário precisa de uma via de triagem. A via deve ser rápida, documentada e limitada aos fatos de continuidade. Não deve se tornar um fórum geral para argumentos políticos.
O procedimento também deve proteger a equipe. Em muitas crises de registro, a equipe mantém os serviços funcionando enquanto os conselhos, tribunais e facções públicas lutam. Um operador temporário pode precisar da cooperação da equipe atual, mas esta pode enfrentar instruções conflitantes. A regra deve indicar como a equipe pode fornecer informações de continuidade, preservar os registros e evitar exposição pessoal. Não deve obrigar funcionários individuais a escolher entre ordens nacionais e expectativas de continuidade global sem clareza jurídica.
Um slogan diz 'outro RIR pode intervir'. Um procedimento de migração diz como cada membro vive a segunda-feira de manhã. É este último que é necessário para a continuidade.
O que a ICANN pode legitimamente exigir
A exigência legítima da ICANN em uma crise do tipo AFRINIC é a prova da capacidade de serviço, neutralidade e continuidade. Ela pode perguntar se os registros são preservados, se os membros são tratados em pé de igualdade, se a governança pode ser restabelecida, se a influência indevida é contida, se os serviços básicos funcionam, se os backups estão atualizados, se a equipe tem autoridade para agir e se a comunidade da região recebe informações verdadeiras. Essas solicitações estão alinhadas com a função que a ICANN exerce na coordenação do sistema reconhecido de RIRs.
A ICANN não deve exigir lealdade política, um resultado eleitoral privilegiado, a derrota de um litigante particular ou uma posição política escolhida em Los Angeles. Não deve usar o reconhecimento para punir uma região que discorda de um ator global. Não deve converter uma preocupação sobre a influência de um membro em autoridade para aprovar cada modificação dos estatutos. O limite é o risco de serviço e o dever reconhecido.
A carta de junho de 2025 era mais forte onde nomeava deveres concretos: apoio à comunidade, igualdade de tratamento, imparcialidade, independência, abertura de filiação, manutenção de registros e backups. Era mais vulnerável onde mencionava preocupações sobre influências que poderiam levar a política da AFRINIC a posições contrárias à coordenação global. Isso pode ser uma preocupação legítima se a influência comprometer o serviço imparcial ou o sistema de numeração. Isso requer uma declaração de prova precisa para evitar dar a impressão de polícia política.
Uma regra de substituição ajuda a ICANN a formular melhores exigências. Em vez de fazer perguntas gerais sob pressão, a ICANN pode associar cada solicitação a um gatilho conhecido e a uma consequência de serviço.
'Fornecer o estado dos backups dos registros porque a continuidade de emergência requer portabilidade verificada dos registros.' 'Fornecer os resultados da investigação sobre a autoridade dos membros porque a governança de rotina e as ações de alto risco dos membros dependem de autoridade verificada.' 'Fornecer métricas de serviço porque a revisão formal requer prova da capacidade operacional.' Isso torna a solicitação menos política e mais responsável.
A ICANN também pode exigir preservação. A destruição ou alteração de registros eleitorais, registros de recursos, provas de autoridade, backups, logs de tickets ou material de confiança técnica ameaçaria a revisão e a continuidade. Um aviso de preservação é justificado quando evidências críveis de crise aparecem. O aviso deve indicar as categorias, os depositários, o método de preservação e a confidencialidade.
A ICANN pode exigir transparência do administrador ou do órgão diretivo porque a confiança do público faz parte da legitimidade do serviço do RIR. Mas a transparência deve ser calibrada. Alguns detalhes de investigação, dados pessoais, identificadores e arquivos confidenciais dos membros não podem ser publicados. A solicitação deve ser por um relatório de estado público, e não por uma divulgação imprudente.
Finalmente, a ICANN pode exigir um plano de remediação. Se o registro afetado puder restabelecer a governança, verificar a autoridade dos membros, preservar os registros, reparar os serviços e se submeter a uma auditoria, a substituição deve permanecer desnecessária. A regra deve fazer da remediação o resultado preferido. A substituição não é uma vitória. É uma resposta a uma falha controlada.
O que uma regra de substituição deve dizer
A regra de substituição deve começar com gatilhos. A continuidade de emergência só deve estar disponível quando um RIR não puder fornecer adequadamente todos ou uma parte definida de seus serviços, ou quando a prestação contínua criar um risco significativo para os registros, neutralidade ou integridade do serviço que não possa ser resolvido por medidas mais restritas. A perda de reconhecimento formal deve exigir um limite distinto e mais alto.
Ela deve definir os operadores elegíveis. Um operador deve ser um RIR qualificado ou outra entidade aprovada com capacidade técnica, capacidade jurídica, controles de proteção de dados, capacidade financeira, independência em relação ao litígio, divulgações de conflitos, experiência de serviço e concordância com o mandato temporário. O órgão diretivo do próprio operador deve aprovar o papel de acordo com suas próprias regras.
Ela deve definir consentimento e aprovação. A operação de emergência deve exigir o acordo da ICANN e dos outros RIRs, uma discussão com o RIR afetado e sua comunidade na medida do possível, e razões publicadas se uma discussão completa não for possível. A sucessão permanente ou perda de reconhecimento deve exigir uma via de proposta distinta e recomendações publicadas.
Ela deve definir o escopo dos serviços. O aviso deve listar os serviços que o operador fornecerá: consulta pública, serviço de suporte, atualizações de contatos, processamento de transferências, DNS reverso, certificação de recursos, cobrança, comunicações, preservação de registros, suporte político ou apenas um subconjunto. Tudo o que não estiver listado permanece fora do mandato temporário.
Ela deve definir o movimento de dados. O registro afetado deve sequestrar regularmente um conjunto atual e restaurável de registros necessários sob controles independentes. O acesso deve ser acionado por um evento, registrado em log, limitado pela confidencialidade e revisado após o uso. Os registros contestados devem ser movidos com anotação, em vez de serem silenciosamente normalizados.
Ela deve definir a autenticação dos membros. Solicitações de rotina de baixo risco, modificações de recursos de alto risco, instruções de transferência, litígios de cobrança e autoridade de voto exigem cada um provas diferentes. Uma crise envolvendo procurações não deve usar as procurações como única via de autoridade sem verificação.
Ela deve definir a continuidade da confiança técnica. O RPKI, o DNS reverso e os serviços de diretório exigem etapas de transição específicas, incluindo pontos de congelamento, verificações de validação, estado do repositório, estado das delegações, contatos de emergência, preservação dos serviços antigos e critérios de retorno.
Ela deve definir limites de tempo e renovação. O período inicial de noventa dias do projeto do NRO é uma base útil, mas a renovação deve exigir razões atualizadas, evidências de desempenho, feedback da comunidade e um plano de retrocessão ou escalada.
Ela deve definir a revisão. O registro afetado, os detentores de recursos afetados e o operador temporário devem ter meios de contestar o escopo, erros, excessos ou instruções perigosas. A revisão deve ser rápida o suficiente para ser útil durante a emergência.
Ela deve definir a retrocessão. O RIR afetado deve retomar os serviços assim que a capacidade operacional for restabelecida e verificada. A retrocessão deve incluir reconciliação de estado, auditoria, aviso aos membros, verificações técnicas, relatório de incidentes e lições para a próxima emergência.
A regra deve ser suficientemente detalhada para ser executável, mas suficientemente restrita para não centralizar a autonomia ordinária do registro. Esse é o equilíbrio que a AFRINIC destacou.
A dependência ordinária precisa de sua própria proteção
O círculo eleitoral menos visível em uma crise de reconhecimento é frequentemente o mais importante: o detentor de recursos comum que não causou o litígio. Um pequeno provedor de acesso, uma rede universitária, uma entidade em um ponto de troca regional, um provedor de hospedagem de conteúdo, um banco, um hospital, uma rede de pesquisa ou um órgão público pode não ter nenhum papel em uma luta de conselho de administração e nenhum apetite por um argumento institucional global.
Ele ainda depende do registro para manter registros precisos, contatos acessíveis, modificações de DNS reverso, estado de certificação de recursos, dados de contato de abuso, situação da conta e a prova de que seus recursos de numeração permanecem legitimamente detidos.
Essa dependência ordinária é a razão pela qual a substituição não pode ser projetada apenas para conselhos, administradores, tribunais e organismos de coordenação globais. A regra deve proteger as pessoas que sofrem a falha do registro como uma interrupção, incerteza e risco transacional.
Se a única mensagem pública é que a ICANN pode revisar o reconhecimento e que outro operador pode intervir, os membros ficam a adivinhar se seus serviços diários serão interrompidos, se seus identificadores existentes permanecem válidos, se uma transferência já em análise será honrada, se os documentos confidenciais serão copiados e se as mudanças de rotina se tornam evidências em um conflito político.
O problema da dependência é prático. Os operadores de rede usam os registros do registro para filtrar rotas, avaliar clientes, investigar abusos, demonstrar seus direitos de recursos aos provedores, responder a perguntas de aquisição, provar continuidade a bancos e seguradoras e satisfazer a due diligence em transações. Mesmo quando os pacotes continuam a fluir, uma crise de legitimidade do registro pode fazer terceiros hesitarem. Um provedor de nuvem pode solicitar provas de recursos mais claras. Um comprador pode atrasar uma transferência. Um credor pode depreciar os ativos de endereços.
Um comprador governamental pode duvidar do controle de recursos por um provedor. Uma equipe de segurança pode considerar registros de registro desatualizados como um sinal de risco. Esses efeitos não são falhas espetaculares, mas são custos reais.
Uma regra de substituição deve, portanto, definir um escudo de dependência. Durante a operação de emergência, nenhum detentor de recursos deve perder o serviço reconhecido, a situação da conta ou os direitos de rotina apenas porque o reconhecimento está em revisão. O operador temporário deve preservar o último estado verificado dos recursos, marcar os registros contestados, se necessário, e manter os serviços de rotina de baixo risco assim que uma breve pausa de reconciliação for concluída.
Mudanças de alto risco podem exigir provas mais sólidas, mas a dependência ordinária não deve ser congelada indefinidamente porque um registro eleitoral é contestado.
O escudo também deve dizer o que permanece válido. Os registros públicos de registro existentes devem permanecer acessíveis publicamente, a menos que um registro específico seja conhecido por ser perigoso. O estado existente da certificação de recursos deve ser preservado durante as verificações de transição. As delegações de DNS reverso existentes devem permanecer ativas, a menos que haja uma razão de segurança ou legal para modificá-las. Os tickets existentes devem manter seu lugar na fila com status visível. As faturas e pagamentos existentes devem ser reconciliados em vez de rejeitados.
As submissões confidenciais existentes devem permanecer confidenciais sob as obrigações do operador temporário.
Essa abordagem protege ambos os lados do argumento de legitimidade. Impede que um operador falido faça reféns os membros dizendo que qualquer apoio externo destruiria o serviço. Também impede que um ator externo use a continuidade do serviço como pretexto para reorganizar os direitos dos membros. A base é a preservação. A mudança requer uma razão definida, uma via de autoridade definida e um registro que possa ser examinado.
O escudo de dependência deve incluir uma suspensão de ações punitivas. Durante o período inicial de emergência, o operador temporário não deve suspender recursos, cancelar filiação, rejeitar renovação, concluir uma transferência ou alterar a situação de um membro devido a registros afetados pela crise, a menos que segurança imediata, cumprimento de uma ordem judicial ou fraude evidente exijam ação. As taxas ainda podem ser cobradas e as obrigações de rotina ainda podem ser mantidas, mas o operador não deve converter confusão administrativa em perda de direitos.
A marcação de litígios é preferível à normalização silenciosa. Se duas partes reivindicam autoridade sobre a mesma conta de membro, o operador temporário deve marcar a conta como litigiosa, permitir serviços de continuidade de baixo risco quando seguro e exigir provas mais sólidas para mudanças de alto risco. Se um arquivo de transferência estiver incompleto porque uma ordem judicial ou um problema de acesso da equipe interrompeu a revisão, o arquivo deve ser preservado com seu estado descrito. Se uma procuração for questionada, não deve ser aceita ou rejeitada por padrão apenas porque estava no conjunto de registros.
Deve ser examinada de acordo com a regra de autenticação de emergência.
A mesma proteção deve se aplicar aos dados. Os membros devem saber quais categorias de suas informações podem ser acessadas pelo operador de emergência, por que o acesso é necessário, quais obrigações de confidencialidade se aplicam, onde os dados serão armazenados, como o acesso é registrado em log, quando os dados serão retornados ou excluídos e como um membro pode relatar um erro. Isso não é uma higiene jurídica opcional. Em uma região de serviços multinacionais, a confiança no tratamento de dados faz parte da confiança na própria substituição.
A dependência ordinária também precisa de métricas públicas. Um operador temporário deve relatar volumes de tickets, disponibilidade do serviço, tempo de resposta para solicitações de rotina, categorias de serviços suspensos, número de litígios, estado da confiança técnica e marcos de retrocessão esperados. O relatório não deve expor arquivos sensíveis dos membros. Deve dar aos membros informações suficientes para decidir se a ponte está funcionando. O silêncio gera rumor, e o rumor aumenta os custos de transação.
A crise da AFRINIC mostra por que essa proteção é central. Os detentores de recursos da região não precisavam de um debate teórico sobre autoridade de reconhecimento. Precisavam que o registro funcionasse, que os registros permanecessem críveis e que qualquer plano de continuidade externo respeitasse os direitos regionais. Uma regra de substituição que ignore a dependência ordinária será julgada não por sua teoria institucional, mas pela questão de saber se os membros ainda podem operar suas redes na segunda-feira de manhã.
O risco de não fazer nada
O risco não é apenas que um registro falido possa prejudicar a região. O risco é que um poder de resgate não definido prejudique a região ao tentar ajudar. Uma ameaça vaga pode aumentar os custos de transação, aprofundar facções, alarmar tribunais, congelar investimentos, encorajar litígios oportunistas e levar cada membro comum a se perguntar se seu serviço está prestes a mudar. Um operador de emergência vago pode criar problemas de dados, responsabilidade e legitimidade que sobrevivem à crise.
Não fazer nada também protege demais os operadores atuais. Se nenhuma regra de substituição existir, um registro em crise pode argumentar que qualquer movimento seria muito perigoso. Pode usar a ausência de plano como escudo contra a revisão. Isso cria risco moral. Quanto pior o plano de continuidade, mais indispensável parece o operador atual. Uma instituição crítica não deve se tornar imune porque a substituição seria difícil.
A resposta certa não é a intervenção agressiva. É a preparação. O sistema deve tornar a substituição menos atraente, mas mais possível. Menos atraente, porque a remediação, a auditoria e salvaguardas restritas devem resolver a maioria dos problemas antes da transição. Mais possível, porque os registros, os mapeamentos de serviços e as regras dos operadores devem existir se a função pública realmente não puder continuar.
A crise da AFRINIC já mostrou o custo de um design tardio. As cartas, os depósitos judiciais, as reportagens da mídia, as alegações dos membros e os conceitos de emergência chegaram enquanto os serviços ainda precisavam funcionar. É o pior momento para decidir quem pode deter registros, quem pode autenticar membros, quem paga pelo operador, quem responde a um ticket de transferência ou como restaurar os serviços ao operador atual.
A ICANN e os RIRs devem considerar o aviso da AFRINIC como um prazo de design. A revisão de reconhecimento agora tem um precedente visível. O próximo passo deve ser uma regra de substituição que os membros possam ler antes de precisar dela. A regra deve ser suficientemente operacional para engenheiros, suficientemente jurídica para tribunais, suficientemente delimitada para autonomia regional e suficientemente pública para mercados.
O objetivo não é facilitar a perda de reconhecimento. É tornar a continuidade crível. Se um registro puder ser restaurado, restaure-o com evidências. Se um operador temporário for necessário, limite-o. Se registros precisarem ser movidos, mova-os com anotação e confidencialidade. Se a autoridade precisar mudar, publique as razões e os direitos de revisão. Se o operador atual retornar, faça-o de forma ordenada. Se não puder, use uma via de sucessão distinta e motivada.
A ameaça da ICANN à AFRINIC foi, portanto, um aviso para todo o sistema, e não apenas para um administrador. A camada de reconhecimento agora precisa da regra ausente abaixo. Enquanto essa regra não existir, cada ameaça de revisão carregará uma segunda ameaça desnecessária: não apenas que o operador atual possa falhar, mas que ninguém ainda escreveu a maneira segura de substituir o serviço sem substituir os direitos da região.
Fontes
- Correspondência da ICANN de Kurt Erik Lindqvist para Gowtamsingh Dabee, 25 de junho de 2025.
- Correspondência da ICANN de Kurt Erik Lindqvist para Gowtamsingh Dabee, 3 de julho de 2025.
- ICANN, ICP-2: Critérios para a criação de novos registros Internet regionais.
- Declaração do NRO sobre a nomeação de um administrador judicial para a AFRINIC, 14 de setembro de 2023.
- NRO, Documento de governança para o reconhecimento, operação e perda de reconhecimento de registros Internet regionais, versão 2 do projeto.
- The Register, Eleição da AFRINIC cancelada após carta de ira da ICANN, 26 de junho de 2025.

