Resumo

  • A documentação pública da API NIR da APNIC mostra uma requisição assíncrona a /nir-delegations/asn, mas o tutorial a descreve como uma delegação a partir do pool do NIR, não como prova da entrega posterior de delegação direta.
  • Relatórios ao Conselho Executivo passaram de atualizações do registro e da API em setembro de 2024 para QA final em dezembro. O item atual, listado em 2025, continua sem data-alvo e sem changelog.
  • Um recibo de implantação e verificação poderia ligar a intenção do produto à versão do esquema, à data de corte, aos NIRs participantes, à migração dos registros antigos e à conferência das projeções Whois/RDAP.

Imagine o caminho de uma solicitação de ASN. Uma organização apresenta sua necessidade a um Registro Nacional da Internet. O NIR avalia o pedido no idioma e no contexto local. Um cliente autenticado envia dados à APNIC. O sistema devolve o endereço de uma tarefa. Mais tarde, a tarefa aparece como SUCCESSFUL, e os dados de contato alimentam os registros públicos de Whois e RDAP.

Esse roteiro existe na documentação pública da API NIR da APNIC. Ele é concreto o bastante para um engenheiro entender a mecânica. A rota /nir-delegations/asn aceita a criação de uma delegação. As operações que alteram estado são assíncronas. E a API aceita uma Idempotency-Key, recurso importante quando a conexão cai e o cliente precisa repetir o pedido sem correr o risco de produzir duas mutações.

Mas o roteiro não responde a uma pergunta institucional: qual versão da política operacional e do registro foi executada?

O nome da rota permanece; a semântica pode mudar

O tutorial descreve uma delegação de recursos proveniente dos pools delegados ao NIR. Já a folha de produto apresenta um projeto específico, “NIR ASN Direct Assignments”, para dar ASN diretamente a titulares de subcontas dos NIRs. A solução proposta é desenvolver a função no registro e expô-la por MyAPNIC e pela API NIR. O resultado esperado é maior consistência e validade dos dados.

As duas descrições podem hoje apontar para o mesmo código. Também podem registrar gerações diferentes de um serviço mantido sob a mesma URL. Ou “direta” pode significar apenas que a decisão do NIR passa a gravar o registro central, embora o recurso continue associado a uma reserva do NIR. Os documentos capturados não permitem escolher uma interpretação.

Essa incerteza não autoriza dizer que a APNIC deixou de implantar a funcionalidade. Um endpoint público é evidência de capacidade técnica, mas não fornece, sozinho, a identidade de uma entrega. Para isso faltam uma versão, uma data de corte e uma definição de quais semânticas mudaram.

No mundo de APIs, preservar o endereço de uma rota é uma virtude. Clientes não deveriam quebrar a cada melhoria interna. No mundo da governança do registro, porém, a estabilidade do endereço cria uma obrigação complementar: publicar quando a mesma rota passou a aplicar uma regra diferente. Compatibilidade de cliente e memória institucional são problemas distintos.

A trilha chega ao QA e perde o número da versão

A APNIC publicou vários marcos do projeto. Em setembro de 2024, as atualizações do registro central e da API NIR estavam em andamento. Em dezembro, a iniciativa de delegação direta de ASN estava em QA final. O conjunto de relatórios divulgado no início de 2025 ainda a classificava entre os trabalhos em curso.

Na versão atual dos dados da folha de rota, o item aparece em 2025, sob a equipe Registry e associado a ARMS e MyAPNIC. A descrição preserva a ambição de delegação direta. O campo de alvo, entretanto, está vazio. O changelog também está vazio.

O Relatório Anual de 2025 diz que as metas trimestrais de produto foram alcançadas. Ao exemplificar entregas do registro, cita a atualização da autorização de Whois, os objetos RPKI Signed Checklist e uma prova de conceito da nova arquitetura de RDAP. O documento completo não cita a iniciativa de ASN dos NIRs.

Silêncio não é sinônimo de cancelamento. O changelog público em branco não demonstra que a APNIC não mantém registros internos. E um tutorial hospedado em um ambiente público de testbed não comprova que uma transação de produção ocorreu. A conclusão segura é bem mais limitada: os materiais públicos não vinculam o projeto que chegou ao QA final a uma implantação datada, com escopo e semântica definidos.

O problema é um join ausente. A folha de rota tem a intenção. As atas têm o estágio. A documentação tem a forma da requisição. Como nenhuma peça carrega o mesmo identificador imutável, quem lê precisa decidir que todas descrevem a mesma entrega. Isso é uma inferência, não uma propriedade verificável do sistema.

Um ASN carrega mais autoridade do que a resposta da tarefa

ASN não é apenas um número disponível. Ele identifica um sistema autônomo capaz de trocar informações de roteamento segundo uma política definida. A política da APNIC permite que a organização peça o ASN à própria APNIC ou ao NIR relevante. Todo ASN atribuído deve ficar publicamente registrado na base Whois da APNIC ou do NIR.

Quando um provedor solicita um ASN para um cliente, a cadeia inclui responsabilidades adicionais. O cliente precisa atender aos critérios. O solicitante mantém o registro. Se a conectividade com o provedor termina, o número deve ser devolvido ou transferido por um caminho permitido. Assim, a operação liga elegibilidade, vínculo de serviço, proveniência do recurso, dados públicos e identidade de roteamento.

Uma tarefa SUCCESSFUL não pretende certificar toda essa cadeia. Ela diz que o processamento chegou ao fim. Não informa, por si só, qual ator aprovou o mérito, de qual pool veio o número, qual versão do esquema aceitou os dados, se a escrita ocorreu exatamente uma vez ou se Whois e RDAP passaram a mostrar a mesma organização.

A idempotência reduz um risco muito específico: a repetição acidental. Ela não reduz a ambiguidade de política. Uma requisição pode ser executada uma única vez sob uma regra antiga. Pode terminar com sucesso e ainda exigir reconciliação de uma projeção. Pode funcionar para um NIR que já migrou e ter outro significado para um NIR em transição.

Direto no registro não quer dizer sem NIR

O desenho institucional dos NIRs explica por que a automação não deve ser confundida com centralização. A APNIC reconhece os NIRs para prestar serviços de registro adequados ao idioma e à cultura locais. Eles respondem pelo cumprimento das políticas aplicáveis aos recursos sob sua gestão e podem adotar regras locais que não conflitem com as regionais ou globais. A APNIC, ao mesmo tempo, deve continuar aceitando associações diretas.

Uma organização pode até manter vínculos com um NIR e com a APNIC, mas só obtém serviços de recursos de uma fonte por vez. Logo, uma escrita direta no registro regional pode preservar o NIR como porta de entrada, avaliador e ponto de suporte. Ela apenas elimina um repasse de bloco, uma segunda digitação ou uma defasagem entre bancos.

Essa divisão pode ser o melhor dos dois mundos: decisão próxima do membro e estado regional consistente. Para auditá-la, é necessário dizer exatamente o que mudou. A fonte do pool? O ato de aprovação? O transporte? A criação do objeto público? A estrutura de subconta? Sem essa definição, “direta” vira uma palavra capaz de acomodar arquiteturas diferentes.

A história da APNIC com IPv4 mostra o risco. Em 2019, a organização explicou que, desde 2004, as alocações e atribuições de endereços dos NIRs passaram a sair do pool regional comum e a ocorrer diretamente no registro APNIC, em vez do antigo modelo de confederação. Restaram blocos legados, e a reconciliação posterior corrigiu datas, identidades de titulares e transferências.

Essa mudança histórica não prova nada sobre o novo fluxo de ASN. Ela ensina que a fonte do recurso, a responsabilidade de atendimento e a representação no registro podem evoluir em ritmos diferentes. Um recibo de implantação deve impedir que uma analogia com IPv4 substitua a definição do mecanismo ASN.

A revisão pública mede IPv4, não essa entrega

A APNIC também realiza um programa de revisão de delegações. Ele abrange análise de dados, verificações de conformidade, revisão de processos, exatidão de contas, apoio aos NIRs e uma futura revisão dos acordos. Na atualização do segundo trimestre de 2026, JPNIC, TWNIC e KRNIC apareciam com análises concluídas, enquanto outras continuavam.

O escopo principal publicado, porém, é explícito: dez anos de delegações e transferências de IPv4. Esses resultados não podem ser usados como denominador para a delegação direta de ASN. Eles não dizem quantos NIRs adotaram o novo caminho, quantos ASN passaram por ele ou quais discrepâncias foram encontradas. Também não provam que a APNIC não faça controles internos de ASN. Apenas tratam de outra população.

O sistema público oferece, portanto, três provas parciais. A API registra o andamento de uma transação. A revisão testa dados históricos de IPv4. A folha de rota descreve uma mudança de produto. Falta um artefato que amarre a mudança à versão executável e ao seu resultado inicial.

Um recibo sem expor o membro

O recibo necessário não precisa revelar documentos de elegibilidade, credenciais, nomes de operadores ou notas internas. A primeira seção identificaria o lançamento: chave imutável do projeto, versão da API e do esquema, horário de corte, serviços afetados, possibilidade de rollback e definição precisa de delegação direta.

A segunda registraria adoção e migração. Quais NIRs foram incluídos? O lançamento foi simultâneo ou em etapas? O modelo de pool continuou disponível? Registros ASN anteriores foram convertidos para novas subcontas? Que exceções ficaram fora do lote?

A terceira apresentaria garantia agregada durante um período definido: operações tentadas, aceitas, rejeitadas, revertidas e reconciliadas; consistência entre registro central, Whois e RDAP; duplicidades absorvidas pela Idempotency-Key; pendências ainda abertas. Os números poderiam ser agrupados sem identificar qualquer membro.

O ganho não é mais documentação por si mesma. É separar três verdades. A verdade do lançamento identifica a semântica implantada. A verdade transacional descreve o que uma requisição fez. A verdade do estado mostra o que o registro público contém agora. Quando essas verdades têm versões e referências comuns, um endpoint deixa de ser obrigado a provar uma reforma inteira.

Fontes