Resumo

  • A documentação atual da ARIN separa objetos IRR simples, criados pelo Online ou por XML REST, de objetos avançados, criados por RPSL REST ou migrados do IRR-email. A origem determina o canal de gestão.
  • Um objeto migrado pode ser visto e excluído no Online, mas sua edição fica no caminho RPSL. Excluir e criar novamente pelo formulário muda o objeto para outra classe de proveniência.
  • A visão geral e as notas de implementação divergem sobre o acesso RPSL REST a objetos nascidos no Online. Sem uma operação autenticada e representativa, a divergência não pode ser resolvida por suposição.
  • Um recibo enxuto pode ligar hash anterior, classe, versão de permissões, tipo de autoridade, canal, resultado e hash sucessor, sem revelar chave de API, nome de funcionário ou topologia privada.

Quando corrigir exige retirar o estado válido

A documentação do IRR da ARIN descreve uma escolha desconfortável. O responsável encontra no ARIN Online um objeto que veio do sistema IRR-email. Pode consultá-lo. Pode apagá-lo. O que não pode fazer é alterar seus campos naquela interface. Para editar, o guia aponta para REST; para passar a administrá-lo pela web, as notas de implementação mandam excluir e recriar. Guia do usuário do IRR da ARIN

Do ponto de vista humano, o trabalho talvez seja corrigir uma linha. Para o registro, o caminho remove uma asserção existente e submete outra. O prefixo, o ASN de origem e os demais atributos públicos podem ser digitados de forma idêntica. A biografia de gestão, porém, mudou: o sucessor nasceu no formulário moderno e já não é o objeto migrado que justificava a limitação original.

Não há, nas fontes examinadas, um caso de perda, falha de rota ou dano a uma organização. Nenhuma conta, credencial ou chave de objeto foi testada. Não houve leitura de NRTM nem medição de BGP. A evidência é o contrato de controle publicado, não o resultado de uma operação em produção.

Essa cautela também impede uma crítica rasa. Se o formulário não consegue preservar todos os atributos e relações de uma expressão RPSL, permitir uma edição parcial pode ser pior. O usuário veria uma mudança local enquanto o sistema normalizaria ou descartaria informação fora da tela. Bloquear a edição pode proteger a semântica.

Portanto, a solução não é necessariamente liberar todos os botões. É oferecer uma conversão consciente, com preimagem canônica, validação do candidato e uma prova de sucessão. A fronteira pode continuar; o fio entre os estados não precisa desaparecer.

A matriz da ARIN classifica gestão, não veracidade

A visão geral atual chama de simples os objetos criados no ARIN Online ou por REST com XML. Sua tabela permite criar, consultar, editar e excluir nesses dois caminhos e não atribui permissões a RPSL REST. Os objetos avançados são criados por REST com RPSL ou migrados do IRR-email. Eles têm as quatro operações em RPSL REST, nenhuma em XML REST e apenas consulta e exclusão no Online. Visão geral do IRR da ARIN

Os nomes não são um selo. “Avançado” não significa que a rota é mais legítima, mais recente ou mais visível. “Simples” não reduz a complexidade da política expressa. A classe indica a representação e o canal sob os quais a ARIN aceita mudanças.

A própria ARIN diz que a consulta pública retorna RPSL independentemente da classe. Faz sentido. Um consumidor precisa ler o conteúdo de um route, route6, aut-num, as-set ou route-set; não precisa receber a chave usada pelo mantenedor. O histórico da escrita, por outro lado, importa ao auditor que quer saber qual validador e qual autoridade produziram o estado.

A RFC 2622 define a Routing Policy Specification Language para descrever políticas e objetos de IRR. Ela organiza uma declaração; não observa a tabela BGP. Um objeto bem formado não demonstra que o anúncio existe, que todos os vizinhos o aceitam ou que um gerador de filtros já o consumiu. RFC 2622

É possível, assim, defender uma proveniência rigorosa sem apresentar o IRR como prova da rota real. O recibo deve dizer o que ocorreu no registro, e parar exatamente ali.

A separação nasceu de uma migração que não era neutra

As notas de implementação mostram que o passado por e-mail não foi simplesmente renomeado. Objetos ligados às condições de autoridade e validação da ARIN foram levados ao ambiente correspondente; outros ficaram em ARIN-NONAUTH. A ARIN informa que os objetos migrados passaram pela validação mais estrita do sistema novo e aparecem com uma nota na interface. Notas de implementação do IRR Online

Preservar a marca é uma virtude. Importar com sucesso não faz um registro antigo ter sido criado retroativamente no Online. A origem explica por que dois resultados públicos em RPSL podem ter superfícies diferentes de manutenção.

Há outra decisão de mão única. A primeira ação web ou REST de uma organização desativa permanentemente seu antigo canal de atualização por IRR-email. Isso reduz o risco de escritores concorrentes com credenciais, parsers e regras distintas. Depois que o controle moderno é escolhido, não há dois sistemas disputando qual alteração vale.

O argumento a favor da ARIN é forte: manter codificações separadas pode evitar uma conversão silenciosa e inexata. XML e um formulário estruturado impõem um conjunto de campos; RPSL possui sua gramática e atributos. Antes de oferecer edição cruzada, o serviço precisa provar que cada objeto suportado sobrevive à ida e à volta.

Mas uma migração bem governada precisa de uma saída verificável. A tela deveria identificar a classe, explicar por que a edição não está disponível, permitir a exportação da forma canônica, verificar se o sucessor é válido e registrar que a exclusão pertence à mesma intenção da recriação. Sem isso, a preservação da origem termina justamente no momento em que o operador segue a orientação oficial.

Excluir e criar são duas oportunidades de falha

O guia REST da ARIN separa GET, POST, PUT e DELETE. PUT altera; DELETE remove. As operações cobrem os tipos IRR aceitos e as cargas RPSL ou XML, conforme a permissão. A distinção de protocolo continua existindo mesmo quando a interface chama os dois passos de uma única tarefa. API REST do IRR da ARIN

Uma alteração em lugar pode ligar o hash canônico anterior ao posterior sob a mesma continuidade. A dupla exclusão/criação gera mais estados: objeto antigo ausente, candidato rejeitado, candidato aceito com conteúdo normalizado, ou sucessor ainda não observado em algum caminho de publicação.

Nenhum desses estados foi medido neste trabalho. Não há contagem de objetos migrados, frequência de conversão, distribuição de tempo ou exemplo de serial NRTM. Não se pode dizer que uma lista de filtros leu o intervalo. O ponto é arquitetural: duas operações falíveis exigem uma prova que uma operação única não exige.

A reentrada manual aumenta a ambiguidade. Um comentário pode desaparecer, a ordem de expressões pode mudar, uma regra nova de validação pode exigir correção. Reutilizar a chave pública faz a classe mudar sob uma identidade aparentemente estável. Criar outra chave torna a sucessão ainda menos óbvia. Um chamado de suporte não é uma ligação durável para o próximo mantenedor ou para uma ferramenta.

Uma boa transação de conversão poderia primeiro verificar a preimagem, o formato de destino e a capacidade de criação. Só então retiraria o objeto antigo e confirmaria o sucessor, de modo atômico ou com um estado recuperável. Se a arquitetura não permite atomicidade, o recibo deve ao menos mostrar cada passo e oferecer correção ou retomada.

Duas páginas atuais não formam uma única regra RPSL

A matriz da visão geral afirma que os objetos simples não têm permissão em RPSL REST. As notas de implementação, numa página com atualizações listadas até 17 de janeiro de 2025, dizem que objetos criados no ARIN Online podem ser consultados, atualizados e excluídos via REST usando RPSL ou XML.

É uma divergência material. Talvez os textos se refiram a versões, tipos ou condições diferentes. Talvez uma página não acompanhe o sistema. As fontes não permitem escolher. Até um teste autenticado em um único route provaria apenas aquele caso, não todas as classes e operações.

O texto histórico de fevereiro de 2021 ajuda a ver que as limitações e planos mudaram durante a chegada do REST. Hoje ele está no Vault da ARIN, com aviso de que pode estar desatualizado. Serve para cronologia, não para decidir o contrato atual. ARIN Vault: chegada da API REST

A solução documental é pequena: uma matriz única, versionada e com data de vigência, cruzando classe, tipo de objeto, ação, canal e codificação. A execução observada continua sendo a realidade de um caso; a matriz diz o que o serviço se compromete a suportar. Se divergirem, o operador preserva a requisição e a resposta e não precisa arbitrar duas prosas.

Enquanto isso não ocorrer, esta análise registra a incerteza. Não afirma que RPSL funciona para objetos Online nem que necessariamente falha.

Uma prova útil não precisa vigiar o mantenedor

O recibo pode conter somente o tipo e a chave pública do objeto, classe e proveniência anteriores, versão da matriz, hash canônico antes da ação, natureza do ato, classe do ator autorizado, canal e codificação, resultado, classe e hash posteriores e vínculo entre exclusão e recriação. Uma observação de publicação ou serial NRTM pode ser incluída quando for conhecida com precisão. Correções devem acrescentar eventos, não apagar o anterior.

Não há razão para publicar a chave API, o nome de um funcionário, a estrutura interna da organização ou topologia privada. A ARIN comprova apenas o que controla: que aceitou, recusou ou removeu uma declaração por determinado caminho. O documento não comprova que todos os espelhos sincronizaram, que alguém refez filtros ou que os pacotes seguiram o RPSL.

O guia atribui a gestão do IRR a POCs Admin, Tech e Routing, não a Resource POCs. A autorização da pessoa e a classe do objeto são duas verificações. Um ator pode ter o papel correto e ainda encontrar o canal Online indisponível por causa da origem. Registrar as duas dimensões evita tratar uma incompatibilidade de representação como falha de identidade.

O achado, portanto, não é um objeto ruim. É uma regra que mantém a origem ligada à capacidade de correção. A ARIN tem bons motivos para fazê-lo. A mesma disciplina pede que uma conversão preserve a relação entre o estado que desaparece e o que passa a substituí-lo.

Fontes

  1. ARIN: visão geral do Internet Routing Registry
  2. ARIN: guia do usuário do IRR
  3. ARIN: notas de implementação do IRR Online
  4. ARIN: API REST do IRR
  5. ARIN Vault: histórico da API REST do IRR
  6. RFC 2622: Routing Policy Specification Language