Resumo

  • A migração da RIPE NCC ocorreu por etapas: começou em 23 de abril de 2001, tornou auto-dbm exclusivo para RPSL em 14 de maio e encerrou a conversão de RIPE-181 em 15 de outubro.
  • Os registros públicos situam Andrei Robachevsky no trabalho como Database Group Manager: ele apresentou as mudanças de consulta da versão 3 em 2000 e assinou o aviso de conclusão da primeira fase em abril de 2001.
  • Converter um objeto muda como o registro o armazena e aceita. Isso não determina quem possui um bloco de endereços, se um prefixo está sendo anunciado hoje nem por onde passam os pacotes.

Um formato novo não troca todas as portas de uma vez

O aviso de 14 de maio descreveu três caminhos. auto-dbm aceitaria apenas RPSL. auto-181 receberia objetos em RIPE-181 e os converteria até 15 de outubro. auto-rpsl continuaria aceitando RPSL. A mesma separação valia para a base de testes.

A pergunta prática para quem operava o sistema não era somente se a base já havia sido migrada. Era preciso identificar o formato produzido por cada cliente, o endereço para o qual ele enviava a atualização, as verificações aplicadas nesse caminho e a data em que a conversão acabaria. Os comunicados não informam quantos scripts precisaram de alteração nem afirmam que todos os usuários enfrentaram uma interrupção. Mostram, porém, que a mudança foi exposta como um contrato verificável entre usuário e serviço.

Em 23 de abril, Robachevsky assinou uma mensagem dizendo que a nova versão estava funcionando e que todos os objetos haviam sido convertidos automaticamente para RPSL e carregados. Isso não significava que todas as entradas já aceitavam apenas o novo formato. Na primeira fase, auto-dbm ainda aceitava RIPE-181 com restrições: atributos vazios ou grafados incorretamente eram recusados, PGP não era aceito naquele caminho e as regras de autorização do RPSL continuavam valendo. auto-rpsl recebia o formato novo. A operação mudou tanto os dados quanto as maneiras autorizadas de atualizar esses dados.

O resultado de uma consulta depende da pergunta

Em agosto de 2000, Robachevsky, apresentado como Database Group Manager, descreveu mudanças na interface de consulta v3 e pediu comentários ao grupo de trabalho. A consulta exata buscava um objeto igual à faixa informada; a consulta menos específica retornava a menor faixa superior que a contivesse. -K limitava a resposta às chaves principais. A consulta de fontes expunha detalhes do banco e do espelhamento, como intervalos de números de série, enquanto as consultas inversas podiam pesquisar atributos de contato.

Essas opções não certificam que um registro é verdadeiro. Elas definem o que o programa perguntou e o recorte que recebeu. Uma resposta apenas com chaves pode simplificar uma rotina automática, mas deixa menos contexto. Um objeto que contém a faixa consultada não é uma correspondência exata. Dados de espelhamento descrevem a interface de replicação de uma fonte; não medem a tabela global de rotas. Portanto, uma mudança na interface pode alterar ferramentas de monitoramento mesmo quando um objeto continua parecendo familiar.

A minuta das atas do RIPE 38 registra uma apresentação de vinte minutos de Robachevsky sobre a migração e enumera usuários de consultas, usuários de atualização, scripts e espelhos quase em tempo real entre os afetados por RPSL, controles de acesso, formato do banco e protocolo de espelhamento. Como a própria página marca as atas como minuta, ela serve para mostrar o que aquele rascunho registrou sobre a reunião, não para provar que todos os prazos depois foram cumpridos. Os avisos publicados e o relatório anual são evidências mais fortes da conclusão.

A janela de compatibilidade tinha um responsável

O relatório anual da RIPE NCC descreveu a transição como um processo de seis meses, iniciado em 23 de abril e concluído em 15 de outubro. Durante esse período, a organização manteve o conversor e publicou instruções; os mantenedores precisavam conferir seus geradores de atualização; quem operava espelhos tinha de validar formato e sincronização; e os clientes precisavam interpretar corretamente o que recebiam. As fontes não calculam as horas ou custos de cada parte. Elas deixam claros os pontos controlados pelo serviço: formato aceito, autorização, endereço de entrada e data de encerramento da ponte.

Manter um registro compartilhado exige mais que carregar objetos. Os usuários precisam saber como enviar uma mudança, quem está autorizado a fazê-la, que tipo de resultado uma busca apresenta, como acompanhar uma réplica e quando uma exceção termina. São obrigações do serviço. Não transformam a organização que opera a base em proprietária dos recursos registrados nem lhe conferem autoridade política automática sobre cada usuário.

A RFC 2622 separa ainda a linguagem da administração da base. Ela define RPSL para descrever políticas de roteamento e explica a função do objeto maintainer na autorização de alterações. Os autores listados são Alaettinoglu, Villamizar, Gerich, Kessens, Meyer, Bates, Karrenberg e Terpstra; Robachevsky não está entre eles. Seu trabalho documentado na migração não deve ser confundido com autoria da linguagem ou da RFC.

Cadastro, política e anúncio BGP não são equivalentes

Um objeto de cadastro da RIPE Database, um objeto de política do Internet Routing Registry e uma observação BGP respondem a perguntas distintas. O objeto convertido informa o que a base registrava naquele momento. O objeto RPSL expressa uma política declarada. Um coletor de rotas pode mostrar que certo ponto de observação viu um anúncio em determinado instante. Nenhum desses sinais substitui os outros. O cadastro sozinho não comprova acessibilidade atual, entrega de pacotes, titularidade jurídica nem que todos os roteadores sigam a política registrada.

Se um objeto estiver desatualizado, é preciso investigar qualidade dos dados e autorização. Se um prefixo sumir de uma visão de rotas, são necessárias observações de roteamento. Se houver disputa sobre quem pode atualizar o objeto, converter o formato não resolve a questão. A importância documentável dessa migração está em outro lugar: tornar interfaces, prazos e deveres de um registro público verificáveis, sem confundir o sistema que guarda as referências com os recursos e a rede que ele descreve.

O que a documentação permite atribuir

Em agosto de 2000, Robachevsky assinou como Database Group Manager uma mensagem que explicava consultas v3. Em abril de 2001, assinou um aviso de que a primeira fase estava concluída, com conversão automática e limites temporários para RIPE-181. A minuta do RIPE 38 o identifica como apresentador previsto. Isso sustenta o retrato de um gestor que comunicou a transição e procurou ouvir os usuários. Não demonstra que ele escreveu o software de conversão, decidiu sozinho cada regra ou verificou individualmente os objetos.

Operar a infraestrutura de um cadastro público traz um dever de acesso previsível e de mudanças rastreáveis. Não torna o operador dono do que foi registrado. A documentação dá base sólida para descrever datas, formatos, entradas e regras; não mede o custo de cada participante, não comprova que todos adotaram a nova configuração e não informa o estado atual de qualquer rota.

Fontes