Resumo

  • A versão 3 acrescenta uma via para que o RIR afetado inicie uma transição temporária dos próprios serviços; outra via permite que ICANN e dois terços dos demais RIR iniciem ou renovem o arranjo.
  • O teto de 90 dias e o direito do RIR afetado de reassumir os serviços após a recuperação verificada estão claros. Não está claro quem renova uma transferência que começou por iniciativa do próprio registro.

Muda o operador; não necessariamente muda o registro

Quando um RIR não consegue prestar adequadamente todos ou parte dos seus serviços, o RIR Governance Document proposto permite que um Temporary Emergency Operator qualificado assuma temporariamente as funções afetadas. O texto não diz que esse operador substitui institucionalmente o RIR. A transferência envolve serviços determinados: delegação de recursos numéricos, manutenção de registros e diretórios ou funções técnicas das quais titulares de recursos e outras redes dependem. O arranjo pode cobrir apenas parte das funções e pode mudar de escopo.

Em 1º de setembro de 2026, a AFRINIC compartilhou o projeto recomendado pelo ASO AC, a comparação entre versões e o relatório de justificativas. A página do NRO identifica a Versão 3 como FINAL DRAFT; a cronologia do NRO registra que o ASO AC/NRO NC entregou o documento ao NRO Executive Council em 28 de julho. Em 14 de outubro, a finalização ainda está em curso e a aprovação/adoção do quarto trimestre ainda está à frente. Trata-se, portanto, de uma regra proposta para o sistema de RIR, não de um procedimento vigente. O comunicado e o projeto não demonstram que a AFRINIC ou qualquer outro RIR esteja atualmente sem capacidade de prestar serviços. A AFRINIC compartilhou o pacote; as regras analisadas estão no texto da Versão 3 do NRO.

Dois caminhos para começar

O item 5.1(a) muda de modo relevante a Versão 2. Se não consegue prestar todos ou parte dos serviços, o RIR afetado pode iniciar um Temporary Emergency Continuity Arrangement para os próprios serviços. Na versão anterior, a iniciação dependia da concordância unânime dos demais RIR e da ICANN. A Versão 3 mantém um caminho de coordenação externa no item 5.1(b), mas reduz esse patamar: ICANN e dois terços dos outros RIR também podem iniciar ou renovar o arranjo, após discussão com o RIR afetado e sua comunidade quando isso for razoavelmente possível.

O relatório de mudanças descreve uma finalidade operacional. Uma iniciativa do próprio RIR pode ser útil durante um desastre natural; a redução do limiar externo pode acelerar a resposta. O limite de 90 dias foi mantido para impedir que uma solução temporária se torne o modo padrão. A lógica é compreensível: em uma disrupção, esperar uma autorização mais ampla antes de solicitar apoio pode prolongar a incerteza sobre quem pode manter uma função registral necessária.

Mas iniciar e renovar são decisões diferentes. O item (a) identifica o RIR afetado como agente que pode começar a transferência dos seus serviços. O item (b) é o único que menciona expressamente iniciar ou renovar com concordância da ICANN e de dois terços dos demais RIR. O item (c) estabelece que o arranjo não pode passar de 90 dias, salvo renovação conforme as condições da seção. Não diz de forma explícita se o RIR que iniciou pelo item (a) pode renovar sozinho ou se a renovação precisa seguir o acordo externo do item (b).

Há mais de uma leitura possível. Como (b) é o único ponto que menciona renovação, ele pode ser interpretado como a única via expressa. Outra leitura é que a autorização para o RIR iniciar em (a) também abrange renovar a transferência que ele próprio abriu. O item 5.1(f), que atribui alterações de escopo à parte ou às partes iniciadoras relevantes de acordo com (a) ou (b), liga os dois caminhos sem resolver a dúvida. O texto deve esclarecer essa ambiguidade, sem transformar uma interpretação em conclusão jurídica já definida ou afirmar que a transferência não pode continuar.

O escopo distribui poder operacional

O conjunto de serviços não fica congelado no primeiro dia. O item 5.1(f) permite ampliá-lo ou reduzi-lo durante o arranjo ou na renovação, conforme considere necessário a parte iniciadora relevante. Se o RIR afetado deu início à transição e um grupo externo depois autorizou sua renovação, o documento precisa indicar quem pode acrescentar uma função, reduzir o mandato do operador temporário ou reorganizar a divisão de trabalho.

Isso não é burocracia de registro. Cada serviço entregue ao operador temporário muda aquilo que o RIR ainda controla diretamente; cada serviço devolvido exige passos de retorno e evidências de que o registro está pronto para reassumi-lo. O critério inicial — não conseguir prestar adequadamente todos ou alguns serviços — também exige avaliação operacional. O registro da decisão deve mostrar qual função não atendia ao critério e qual evidência demonstrará que ela voltou a funcionar, sem publicar credenciais ou detalhes sensíveis de segurança.

O projeto traz proteções importantes. O item 5.1(d) exige que a ICANN publique prontamente a decisão de iniciar ou renovar, seus motivos e seu escopo. Após o início, prevê engajamento com todas as comunidades dos RIR assim que razoavelmente possível; depois da renovação, os RIR podem escolher se farão engajamento adicional. Pelo item 5.1(e), o RIR afetado coopera com a transferência, mas mantém o direito de reassumir os serviços quando sua capacidade operacional estiver restaurada e verificada.

O item 5.2 exige uma revisão conjunta posterior, com relatório público sobre circunstâncias, serviços, duração e retorno, além da avaliação do operador, comentários comunitários e recomendações.

Essas salvaguardas deixam o operador temporário sujeito a uma função definida e tornam a decisão visível. Não substituem, porém, uma regra de renovação após o caminho local. A comunidade pode fornecer evidências, experiência e alertas; o poder decisório institucional continua com os atores que o documento identifica.

O procedimento deve deixar o percurso rastreável

O item 1.3 prevê procedimentos conjuntos de implementação, mas afirma que sua ausência não impede a aplicação do documento. Cada RIR mantém margem para definir sua forma de cumprir as obrigações gerais. O item 1.4 remete as decisões às regras de cada entidade, inclusive às possibilidades aplicáveis de contestação ou recurso. Um manual comum pode detalhar as operações, mas não deveria deixar a divisão básica de autoridade para ser reconstruída durante a emergência.

Um registro curto da via de autoridade tornaria o mecanismo verificável. Ele poderia identificar o item invocado e o decisor; os serviços afetados e a data de início; o vencimento dos 90 dias; quem pode renovar e quem precisa aprovar; as mudanças de escopo e quem as autorizou; a discussão e a publicação; o teste para reassumir as funções; e o responsável e a data da revisão posterior. A proposta não é acrescentar uma nova aprovação em cada etapa. É diferenciar um pedido local de apoio de uma decisão coletiva de manter ou ampliar a transferência.

Na cronologia do NRO, a finalização ainda está em andamento, com atualizações programadas em próximas reuniões de RIR e da ICANN e aprovação/adoção prevista para o quarto trimestre. A próxima versão deveria responder a três perguntas: o RIR que usa 5.1(a) pode renovar? Se não, que decisão de 5.1(b) é necessária? Quem controla o escopo se o caminho de iniciação mudar? Respostas claras preservariam a rapidez buscada pela Versão 3 e permitiriam rastrear a responsabilidade quando o prazo de 90 dias se aproxima do fim.

Fontes