Resumo

  • AFPUB-2026-ASN-001-DRAFT02 exigiria nomes hierárquicos para novos AS-SETs da AFRINIC, mas preservaria objetos planos existentes e suas edições.
  • Preservar, editar, restaurar um objeto excluído e criar um novo são operações diferentes.
  • A equipe da AFRINIC alerta que a restauração pode deixar uma porta operacional aberta; a BTW recomenda um recibo por caso e dados agregados sem conteúdo sensível.

A proposta é uma regra prospectiva, não uma limpeza do acervo de nomes planos existentes. Ela alcançaria a criação de um AS-SET no banco WHOIS da AFRINIC. A seção 5 da RFC 2622 descreve nomes de conjuntos hierárquicos como componentes separados por dois-pontos, que podem começar com um ASN. Pela regra de controle do espaço de nomes, apenas o mantenedor do objeto pai pode criar um nome filho.

O texto protege deliberadamente o estado legado. AS-SETs não hierárquicos existentes não devem ser renomeados; podem continuar em uso e ser editados sem mudança de nome. A justificativa é que uma renomeação em massa criaria grandes inconsistências e que não existe método programático confiável para determinar a qual ASN cada AS-SET existente da AFRINIC corresponde. A proteção também mantém referências já instaladas em políticas de roteamento.

Preservar mantém a identidade. Editar altera conteúdo permitido sem mudar o nome. Criar estabelece um novo registro sob a regra proposta. Restaurar tenta recuperar uma identidade que já existia depois de sua exclusão. Por isso, a restauração precisa provar o que existia, o que aconteceu e por que a continuidade é necessária.

O exemplo obrigatório da proposta é restaurar um AS-SET não hierárquico excluído por engano. A redação apresentada pela equipe diz que exceções podem ser concedidas quando necessárias e que a AFRINIC documentará o motivo. A equipe também alerta que chamar de volta um objeto plano excluído pode criar uma brecha operacional e reduzir a eficácia da política. As atas da AFRINIC 37 registram que isso deixa uma porta lateral aberta e que a exclusão exige autenticação contra o mantenedor.

As evidências disponíveis não definem como provar a exclusão acidental, por quanto tempo uma restauração poderia permanecer, quem aprovaria, quais campos o registro teria, se restaurações repetidas seriam permitidas ou se haveria divulgação agregada. Também não comprovam qualquer restauração real.

O guia público de IRR da AFRINIC documenta criação por portal e WHOIS-web e proteção por mantenedor. O material não testa esses caminhos de produção e não mostra que a restrição proposta esteja ativa. A proposta identifica WHOIS e MyAFRINIC/IRR como sistemas afetados e prevê validação no servidor e em formulários ou APIs expostos. A equipe afirma que a implementação seria priorizada depois do MyAFRINIC v2; isso é um plano condicionado, não evidência de implementação.

Análise da BTW: o recibo deveria registrar a identidade e o hash anteriores, data e hora da exclusão e ator autenticado, evidências de exclusão acidental, referências de políticas de roteamento afetadas, alternativas consideradas, revisor aprovador, horário da decisão, prazo ou condição de migração e registro de encerramento. Assim, continuidade não se confunde com reabertura indefinida do estado plano.

Outra análise da BTW recomenda informar contagens e resultados de exceções de forma agregada, sem segredos de mantenedores ou configurações de roteamento sensíveis. Isso não é um produto existente da AFRINIC nem um requisito adotado.

Nota de publicação: “Publicado” é a data editorial programada, 7 de setembro de 2026, em Asia/Shanghai. O horário efetivo de publicação no servidor ainda não está definido.

Fontes

  1. https://www.afrinic.net/policy-proposals.html
  2. https://www.afrinic.net/afpub-2026-asn-001-draft02
  3. https://www.afrinic.net/ppm-afrinic-37.html
  4. https://www.rfc-editor.org/rfc/rfc2622.html
  5. https://afrinic.net/irr-guide