Resumo

  • A versão 3 exige um processo de participação com todas as comunidades dos RIRs depois do início de um Arranjo Temporário de Continuidade de Emergência, mas diz que os RIRs podem optar por um processo adicional após a renovação.
  • A renovação ainda precisa de decisão, justificativa e escopo publicados; pela via externa, também requer ICANN e dois terços dos demais RIRs, após discussão com o RIR afetado e sua comunidade quando isso for razoavelmente possível.
  • Um recibo de renovação pode preservar a velocidade da recuperação e mostrar o tempo acumulado, as mudanças de escopo e por que uma nova participação global foi — ou não foi — aberta.

Os primeiros 90 dias e os 90 seguintes não carregam a mesma regra de participação.

Essa é a pequena, mas importante, mudança no artigo 5.1 da versão 3 recomendada do RIR Governance Document, publicada em 1º de setembro pela AFRINIC e pela Number Resource Organization. O texto prevê um Temporary Emergency Continuity Arrangement (TECA) quando um Registro Regional da Internet não consegue prestar adequadamente todos ou parte de seus serviços. Um operador temporário qualificado pode assumir as funções afetadas.

O documento continua sendo um projeto final recomendado. As fontes examinadas não provam que ele foi adotado, substituiu o ICP-2 ou entrou em vigor. Tampouco dizem que a AFRINIC ou qualquer outro RIR esteja hoje submetido a esse tipo de arranjo.

A regra muda na renovação

O artigo 5.1 oferece dois caminhos de início. Um RIR afetado pode ativar o arranjo para todos ou parte de seus próprios serviços. O TECA também pode ser iniciado ou renovado com o acordo da ICANN e de dois terços dos outros RIRs, depois de discussão com o registro afetado e sua comunidade quando as circunstâncias tornarem isso razoavelmente possível.

Cada período não pode exceder 90 dias, salvo renovação nos termos do mesmo artigo. A ICANN deve publicar prontamente a decisão de iniciar ou renovar, incluindo a justificativa e o escopo. A extensão, portanto, não deveria acontecer de forma invisível.

A participação se divide em três superfícies distintas. Depois do início, um processo com todas as comunidades dos RIRs deve ser aberto assim que for razoavelmente viável. O RIR afetado e sua comunidade fazem parte da discussão antes do início ou da renovação, com a ressalva da urgência. A ICANN se envolve com sua própria comunidade conforme seus estatutos e procedimentos.

Após a renovação, entretanto, o projeto diz que os RIRs “podem optar” por processos adicionais com as comunidades. O primeiro circuito global é obrigatório; outro circuito global é discricionário. Isso não autoriza ignorar a comunidade afetada nem elimina a publicação. Muda o estado de um canal específico de retorno entre regiões.

O limite importa porque não é só o relógio que pode mudar. O artigo 5.1(f) permite ampliar ou reduzir, durante o arranjo ou na renovação, os serviços prestados pelo operador temporário. O segundo período pode durar mais e cobrir algo diferente do primeiro. O texto limita cada intervalo a 90 dias, mas não traz, nas cláusulas verificadas, um teto numérico acumulado de renovações.

A velocidade é a defesa mais forte

A continuidade de emergência existe porque, em certos momentos, atrasar causa mais dano do que uma consulta imperfeita. Alocações, cadastros, diretórios, DNS reverso e serviços técnicos relacionados não podem esperar um processo longo quando a capacidade operacional falha. O primeiro processo global talvez ainda esteja aberto na data da renovação, e suas contribuições podem continuar atuais. Repetir tudo automaticamente pode gerar ruído, criar espaço para atrasos táticos e desviar equipes da restauração.

O projeto mantém outras salvaguardas. A decisão de renovar, sua justificativa e seu escopo devem ser divulgados prontamente. A via externa exige a ICANN e dois terços dos demais RIRs. A discussão com o registro afetado e sua comunidade permanece necessária quando razoavelmente possível. A ICANN mantém seus próprios deveres de participação. E, quando o arranjo termina, o artigo 5.2 exige revisão conjunta com relatório público, avaliação do operador temporário, contribuições das comunidades e recomendações.

A resposta, portanto, não é um referendo a cada 90 dias. É um registro capaz de mostrar como a discricionariedade foi usada.

Um recibo para a renovação

Cada decisão deveria vir acompanhada de um recibo breve. Ele identificaria o arranjo e o número do período; a autoridade responsável; as datas de início e fim; o total acumulado de dias; o operador temporário; o escopo antes e depois; e o motivo de qualquer mudança.

Também registraria quando o RIR e a comunidade afetados foram procurados ou, se isso não ocorreu, por que a discussão não era razoavelmente possível. Ligaria o último processo com todas as comunidades e informaria se outro foi aberto. Se não, explicaria se o processo anterior seguia ativo, se o escopo não mudou, se atrasar ameaçava a restauração ou qual outra razão orientou a escolha. O estado da participação da ICANN, o teste de recuperação e a próxima data decisória completariam a cadeia.

Informações sensíveis não pertencem a esse recibo. Credenciais, dados privados de registro, arquitetura explorável e provas protegidas do incidente podem permanecer reservados. O documento tampouco deve virar uma porta de aprovação prévia. Sua função é mais estreita: manter autoridade de renovação, participação e escopo no mesmo registro reconstruível.

A versão 2 já previa 90 dias, participação comunitária e renovação. A versão 3 deixa a via de renovação mais explícita, reduz o limiar externo e distingue, no texto operacional, a participação inicial obrigatória da participação adicional opcional. O relatório de justificativa descreve a mudança como uma forma de responder mais rapidamente, preservando o limite de 90 dias e acrescentando salvaguardas de transparência.

É um objetivo defensável. Mas um prazo só limita o poder de emergência se cada reinício permanecer visível. Quando um processo público obrigatório passa a ser eletivo, a decisão de não reabri-lo também faz parte do registro da emergência.

Fontes