Resumo

  • O planejamento do RIPEstat para o terceiro trimestre de 2026 indica o Routing History como a próxima visualização de alto valor a ser refeita e cita manutenção de longo prazo e habilitação de Content Security Policy.
  • A Data API pública é a única fonte da interface, mas limite flexível de linhas, quantidade mínima de peers, primeiro salto, normalização de visibilidade, período consultado e ausência de dados interferem no que o usuário conclui.
  • Um registro de paridade deve ligar as duas versões a respostas congeladas, documentar parâmetros e diferenças intencionais, testar casos de fronteira e guardar a decisão de correção ou retirada.

O intervalo que some sem a rota desaparecer

Imagine um anúncio visto por nove peers RIS de tabela completa e, algum tempo depois, por onze. Com o padrão de dez peers do endpoint Routing History, o primeiro período fica de fora. Ao reduzir o limiar, ele volta. A rede não precisa ter mudado entre as duas consultas; o que mudou foi a regra de inclusão. Ainda assim, uma captura pode sugerir que o anúncio começou mais tarde.

É esse tipo de diferença que merece ser controlado na próxima fase do RIPEstat. O plano do terceiro trimestre de 2026 diz que Routing History será a próxima visualização atualizada e que ela tem grande valor para usuários internos e externos. O RIPE NCC pretende reconstruir outras visualizações legadas com tecnologias novas e aparência renovada, tanto para manutenção futura quanto para habilitar Content Security Policy, ou CSP. O item está em andamento.

O melhor argumento a favor da mudança vem primeiro. Front-ends antigos carregam dependências e modos de inserir scripts, estilos ou recursos que podem impedir uma política moderna do navegador. A especificação CSP do W3C define mecanismos para controlar o que uma página pode buscar ou executar e outras decisões relevantes de segurança. Há inclusive uma modalidade report-only, útil para observar violações antes de aplicar as restrições. Eliminar o código que bloqueia essa defesa é manutenção responsável, não evidência de que houve ataque.

Também não faz sentido exigir que a nova visualização copie cada pixel. Acessibilidade por teclado, cores mais distinguíveis e uma boa redução para celular podem alterar o arranjo. Os planos arquivados do RIPEstat mostram experiência anterior com paridade entre UI antiga e nova, testes automatizados, implantação cuidadosa de dependências de widgets e monitoramento do efeito de uma migração no processamento RIS. Nada nas fontes prova ausência de controles internos.

Mas a segurança da execução e a continuidade do significado não são a mesma prova. CSP responde se o aplicativo novo obedece a uma política mais estrita. A paridade semântica responde se o operador recebe os mesmos fatos materiais ao olhar para a mesma evidência. Uma página pode passar no primeiro teste e mover o início aparente de uma rota no segundo.

Uma API pública ainda exige escolhas de apresentação

O RIPEstat expõe uma divisão de responsabilidades útil. A documentação da Data API afirma que ela é a interface pública e a única fonte de dados para widgets e UI. A página O que é RIPEstat diz que a API fornece dados e responde a consultas, enquanto a interface mostra como eles podem ser visualizados.

A resposta da API é, portanto, uma âncora natural para comparar versões. Ela não produz sozinha o significado da tela. O endpoint Routing History, atualmente na versão 2.3, usa dados de coletores RIS e organiza períodos de anúncio por origem e prefixo. Vários controles merecem entrar na prova.

max_rows é um limite flexível, com padrão 3.000. Quando atingido, todas as rotas registradas de uma origem já incluída são devolvidas, mas novas origens deixam de entrar. Ordenação e aviso de truncamento passam a influenciar a conclusão. include_first_hop inclui o ASN do primeiro salto e pode desdobrar uma origem em várias séries. normalise_visibility acrescenta a proporção de peers RIS de tabela completa que veem a rota. min_peers vale dez por padrão e exclui anúncios localizados ou pouco visíveis abaixo desse número. starttime e endtime definem a janela, cujo final, se não for informado, acompanha o último dado BGP disponível.

O resultado ainda possui um estado delicado: a visibilidade normalizada pode ser -1 quando os dados de peers estão ausentes ou não são confiáveis. Isso não é zero. Colocá-la na linha de base sugere ausência medida; escondê-la sem indicação sugere continuidade; interpolar entre os lados inventa uma observação. A solução visual pode ser nova, mas a distinção entre desconhecido e zero precisa sobreviver.

O alcance dos coletores também faz parte do significado. Routing History declara a origem RIS. A documentação de Routing Status descreve o estado como observado pelos coletores RIS e lembra que um AS pode ter vizinhos não observados ali. A visualização é evidência pública relevante a partir de um sistema definido, não um mapa onisciente da Internet.

Há ainda a armadilha do tempo. Segundo o RIPEstat, a atualidade depende da frequência de coleta, atualização do armazenamento, atraso de processamento, falhas e cache. Duas telas abertas em momentos diferentes podem receber backends diferentes. Compará-las ao vivo não isola o front-end. O ensaio semântico deve usar uma resposta capturada, com horário, hash e intervalo fixo. Testes ao vivo continuam essenciais para saúde e atualidade, mas respondem outra pergunta.

Como seria o registro mínimo

Não se trata de criar um novo órgão de governança nem de manter dois produtos indefinidamente. Um registro versionado pode acompanhar a implantação com um conjunto reduzido de casos representativos.

Cada caso deve indicar builds antigo e novo, versão do endpoint e da metodologia, recurso, intervalo UTC, fuso exibido, parâmetros enviados, padrões efetivamente resolvidos, horário e hash da resposta fixa. Deve explicar como cada UI agrupa, ordena, trunca e apresenta valores ausentes.

Os testes precisam procurar diferenças que alterem decisões: um prefixo de origem única, um caso multi-origem, um resultado grande o suficiente para exercer o limite flexível, períodos dos dois lados do limiar de peers, primeiro salto ligado, informações de peers não confiáveis, último intervalo em aberto, navegação por teclado e leitura em tela estreita.

Diferenças esperadas devem ser registradas como melhorias, não tratadas como defeitos. Uma paleta acessível pode mudar; a legenda pode ser reorganizada; UTC pode substituir hora local, desde que interface, tooltip e exportação sigam a mesma regra. A justificativa escrita impede que um mantenedor futuro restaure uma limitação antiga em nome de uma paridade falsa.

O registro termina com responsável, exceções pendentes, data de revisão, correções, substituições e critério de desligamento. A UI legada não precisa esperar igualdade cosmética. Pode sair quando diferenças capazes de alterar uma decisão estiverem resolvidas ou aceitas, os caminhos acessíveis funcionarem e a nova visão puder ser reproduzida a partir da consulta preservada.

O que não foi demonstrado

As fontes não dizem que a visualização atual está errada, que a nova já foi lançada ou falhou, que CSP altera rotas, que existe vulnerabilidade explorável ou que o RIPE NCC perdeu dados. O plano trimestral não é relatório de conclusão; a documentação pública da API não descreve todos os testes internos.

A recomendação é preventiva. Ela preserva a separação entre observação RIS, contrato da API e escolha de apresentação de um build específico. Assim, a modernização da segurança não depende de uma promessa implícita de que o significado permaneceu igual.

Fontes