Resumo

  • O anúncio da APNIC de 1º de setembro tornou públicos a minuta recomendada v3.4 do NRO NC, o redline e o relatório de justificativa.
  • O artigo 7.2 impediria a alteração do documento enquanto um RIR estiver sob um Temporary Emergency Continuity Arrangement ou houver uma proposta de Derecognition pendente.
  • A justificativa declarada é impedir mudanças apressadas para um caso específico ou o enfraquecimento de exigências em um momento difícil; trata-se de uma minuta, não de prova de emergência ou de regra já adotada.

Uma das disposições mais reveladoras da versão 3.4 é também uma das mais curtas. O artigo 7.1 prevê que uma alteração exigiria concordância unânime da ICANN e dos RIR, após consulta às respectivas comunidades. O artigo 7.2 acrescenta uma trava: o documento não poderia ser alterado quando um RIR estiver sujeito a um Temporary Emergency Continuity Arrangement ou quando uma proposta de Derecognition estiver pendente.

O aviso da APNIC deixa claro o status desse texto. É uma minuta recomendada pelo Number Council da NRO, disponibilizada com uma versão comparada e uma explicação das mudanças. Não há anúncio de adoção final, implementação ou ativação de caso algum. As fontes também não dizem que um RIR esteja em continuidade de emergência, enfrente Derecognition ou tenha tentado alterar o documento.

Ainda assim, a finalidade do novo limite é explícita. O relatório de justificativa afirma que ele evita alterações feitas às pressas para circunstâncias particulares e que requisitos sejam diluídos em momentos difíceis. É uma cautela institucional estreita: as partes não deveriam reescrever a moldura de uma continuidade de emergência ou de um processo de Derecognition enquanto dependem dela para lidar com o próprio caso.

O artigo 5 define a fronteira. Um Temporary Emergency Continuity Arrangement é uma ferramenta temporária para a prestação dos serviços de RIR afetados. O próprio RIR afetado poderia iniciá-lo para todos ou parte de seus serviços. A ICANN e dois terços dos demais RIR também poderiam iniciá-lo ou renová-lo após discutir a medida com o RIR e sua comunidade quando isso for razoavelmente possível. O prazo não pode passar de 90 dias, salvo renovação pela mesma seção, e a ICANN teria de publicar prontamente a razão e o escopo de cada início ou renovação. Isso descreve procedimentos possíveis, não um episódio ocorrido.

Para o bloqueio ter valor público, é preciso saber quando ele está em vigor. A minuta exige algumas publicações, mas não apresenta um registro único que conecte o arranjo ou a proposta ao estado do artigo 7.2. Um recibo de estado enxuto bastaria: RIR afetado, tipo de evento, decisão e hora de vigência, escopo, link para o aviso, renovação ou encerramento, responsável pela publicação e histórico de correções. Nada disso exigiria expor parecer jurídico, detalhes técnicos sensíveis ou posições de negociação.

Esse registro não transformaria a minuta em regra vinculante nem resolveria uma crise. Ele apenas separaria uma salvaguarda futura de um bloqueio realmente ativo. Essa é a diferença que impede que uma descrição de procedimento seja lida, sem prova, como um fato operacional atual.

Fontes