Resumo

  • Em 19 de outubro, a RIPE NCC colocou no ar a página Resources do site RIPE Database, com árvore e verificações. A integração aos fluxos Assisted Registry Check no portal LIR ainda foi apresentada como passo futuro.
  • A tela precisa separar “verificado”, “revisar” e “não verificado”. A falta de uma rota exata não prova, sozinha, que há um erro.

O pai está verde. E os filhos?

Em 19 de outubro, Edward Shryane comunicou ao grupo de trabalho da RIPE Database que a página Resources do site da base já estava no ar. A tabela plana saiu de cena; entraram uma árvore e verificações de recursos. Segundo ele, a mesma função também aparecerá nos fluxos Assisted Registry Check do portal LIR. Esse segundo anúncio fala do próximo destino, não de outro recurso já lançado naquele dia.

Dois dias depois, a equipe de design da RIPE NCC descreveu o ponto em que a árvore pode enganar: conferir um pai não é conferir todos os filhos. Uma hierarquia grande exige muitas chamadas à API. Parte dos filhos pode continuar sem verificação. Se o verde escorrer do topo aos ramos, a página vende como resultado um trabalho ainda na fila.

O painel lateral descrito pela equipe reúne registro, utilização, objetos do RIPE Database e roteamento. A interface passa a ordenar a atenção do membro. Por isso, precisa indicar com precisão onde terminou a checagem.

O perigo aparece na leitura rápida. Um membro abre a alocação, vê o pai marcado como regular e segue para outra tarefa. Se os filhos ainda estão na fila de checagem, o quadro poupou um clique e cobrou a diferença em falsa tranquilidade. A tela deve identificar cada resultado pela unidade que foi conferida: um filho não recebe o resultado do pai como se fosse o seu.

Também há uma diferença entre pedir revisão e registrar uma falha. A primeira chamada exige olhos humanos; a segunda soa como conclusão do registro. Quando a checagem ainda não ocorreu, o campo deve dizer isso sem cor de aprovação nem de alarme.

O que a verificação consegue encontrar

Os exemplos publicados incluem alocações IPv6 anunciadas sem uso registrado; assignments IPv6 menores que o tamanho esperado; alocações com assignments registrados mas não anunciados; ASNs que não aparecem na tabela BGP; e espaço em uso que talvez precise de mais um registro de assignment.

Esses sinais não provam a mesma coisa. Um registro ausente pede conferência. Um ASN fora de uma tabela BGP descreve primeiro a visibilidade naquela tabela. Um route object sem correspondência exata pode estar representado por prefixo mais específico, rota agregada ou outra configuração intencional. A RIPE NCC diz que transformar a ausência de uma correspondência exata em alerta pode induzir o membro ao erro; a proposta usa informação neutra quando não dá para estabelecer um problema.

É melhor que desenhar um triângulo vermelho para cada forma diferente. Em uma equipe de rede, alerta consome a tarde de alguém. Se toda diferença for chamada de problema, as pessoas param de ler os avisos. Se uma checagem nunca executada aparecer em verde, o painel pede confiança em uma caixa vazia.

A documentação pública da API My Resources lista ASN, alocações e assignments IPv4/IPv6 e recursos IPv4 legados. Um registro pode trazer status, data de registro e link para o objeto correspondente no RIPE Database. A interface acrescenta comparação e contexto; o membro precisa saber o que foi comparado, o que apareceu e quem age em seguida. O comunicado de lançamento não traz a lista de cada checagem ativa em produção.

“Revisar” já é uma decisão pequena

“Revisar” preserva espaço para o contexto. “Problema” parece uma sentença. “Nenhuma correspondência exata encontrada” relata o que o sistema viu sem fingir conhecer toda a arquitetura de roteamento.

O redesenho separa itens acionáveis de informações que exigem interpretação. As notificações devem explicar o que foi detectado, por que importa e qual ação pode vir depois. Objetos de rota relacionados poderão aparecer em uma hierarquia. A RIPE NCC também planeja testar o desenho com membros durante a RIPE 93 para saber se eles entendem a árvore, as verificações e o caminho até o Registry Check existente.

O registro público ainda não traz o resultado desses testes nem um relatório de cobertura em produção; um relatório datado e a definição do estado de verificação por recurso permitiriam reavaliar o desenho.

Deixe a caixa vazia à vista

Um portal de recursos não é uma janela passiva. Quando organiza achados e recomenda o próximo passo, ele distribui a atenção de membros e equipes. Isso é trabalho operacional, e exige que uma configuração incomum não vire automaticamente uma decisão do registro.

A nota de Lu Heng sobre continuidade do registro separa a proteção de dados e serviços confiáveis das escolhas de poder da instituição. Aqui, a distinção é prática: o portal pode ajudar a manter registros atualizados sem transformar uma rota sem correspondência exata em veredito de conformidade.

Cada recurso deve mostrar o que foi conferido, quando, o que apareceu e se o estado é regular, merece revisão ou ainda não foi verificado. Numa árvore grande, o andamento deve ficar ao lado de cada ramo. Se o sistema ainda não chegou a um recurso filho, dê a ele uma caixa vazia — não empreste o sinal verde do pai.

Fontes: comunicado de lançamento da RIPE NCC; atualização de outubro da RIPE NCC aos membros; RIPE Labs: Redesigning My Resources; API My Resources da RIPE NCC; Assisted Registry Check da RIPE NCC.