Resumo

  • A ARIN concedeu US$ 17.350 à Virginia Tech para um painel de saúde operacional da RPKI, apoiado em um armazém declarado de 14 anos, 3,9 bilhões de observações e 139 GB.
  • O resumo fornecido pelo beneficiário situa a conformidade de revogação entre 9% na AFRINIC e mais de 99% na ARIN desde 2023, além de relatar uma mudança de 14 para 80 dias na cadência de nova assinatura da ARIN.
  • A página pública não revela o numerador, o denominador, o intervalo nem as exclusões dessa conformidade. A API beta define métricas vizinhas, mas não permite reproduzir diretamente os dois percentuais.
  • Cada comparação deve trazer um comprovante versionado com pergunta, população, estado de validação, cobertura, versão do código, correções e resumo exato do resultado.

O financiador, o medidor e o revisor

O anúncio da ARIN registra o projeto da Virginia Tech e o valor de US$ 17.350. A página detalhada acrescenta os resultados técnicos e avisa que os resumos foram fornecidos pelos beneficiários. Essa atribuição separa papéis que um título curto pode misturar: a ARIN escolheu financiar; a equipe fez a medição; o trabalho ainda está sob avaliação no IMC 2026.

Segundo o texto, o armazém acompanha objetos dos cinco RIRs desde aproximadamente 2012 e reúne 3,9 bilhões de observações em 139 GB de Apache Parquet. A série longa pode revelar mudanças que uma fotografia atual não mostra. Mas uma observação não é, por definição, uma unidade comparável. O mesmo objeto observado diariamente gera muitas linhas; uma CA que publica mais pode pesar mais no conjunto.

O resumo passa então a métricas de comportamento. As janelas de validade de CRLs variariam sete vezes; a cadência de nova assinatura, dezesseis vezes; a conformidade de revogação, de 9% na AFRINIC a mais de 99% na ARIN desde 2023. Para a ARIN, o texto associa 2023 à passagem de 14 para 80 dias, à redução de dez anos para 825 dias na vida de certificados CA e ao salto de menos de 5% para mais de 99%.

Pode ser uma descoberta robusta. O estado público, contudo, é “em revisão”. A concessão não equivale a revisão pelos pares, e a ARIN não diz ter reproduzido a fórmula. A forma responsável de usar o número é tratá-lo como resultado do beneficiário com uma fronteira metodológica ainda necessária no espaço público.

Vinte e quatro horas também aparecem sob “cadência”

O RPKI Warehouse hoje disponível se identifica como observatório beta alimentado por retratos diários dos cinco RIRs. Oferece consultas de ROA, ciclos de vida e cobertura, além de avisar que dados e funções podem mudar. Não há base para chamar essa superfície de entrega final do novo grant.

Mesmo assim, seu OpenAPI expõe uma definição útil. “Signing cadence” é o intervalo entre valores consecutivos de this_update de CRLs por CA, identificada pelo AKI. Na consulta de 25 de setembro, o resultado agregado para a ARIN apresentou mediana de 24 horas.

Isso não prova que os 80 dias estejam errados. Uma medida pode tratar de CRLs atuais; a outra, de outro objeto assinado, janela histórica, subconjunto de CAs ou forma de agregação. O que a diferença demonstra é mais básico: o nome “cadência de nova assinatura” não preserva sozinho a identidade do cálculo.

O endpoint de atraso de CRL é mais específico. Considera CRLs atualmente vivas e define atraso como o tempo presente menos next_update. É uma métrica operacional clara, mas não uma fórmula de conformidade de revogação. No esquema público inspecionado, não havia endpoint com esse nome nem elementos suficientes para refazer 9% e 99%.

Presente no repositório não significa aceito pelo RP

O RFC 6487 perfila certificados de recursos e CRLs. Cada CA publica uma CRL que cobre os certificados emitidos, e o relying party a consulta durante a validação. O documento define objetos e testes; não cria um placar regional único.

O RFC 9286 liga a CRL ao manifesto do ponto de publicação. O manifesto lista objetos, inclui thisUpdate e nextUpdate e ajuda a detectar ausência ou repetição de versões antigas. Quando uma coleta falha, um RP pode continuar com o cache até uma tentativa bem-sucedida ou até o material ficar obsoleto.

Assim, uma CRL pode aparecer num retrato do repositório e não pertencer ao conjunto validável de um RP. Pode estar no manifesto, mas fora da janela. Pode ser recuperável para um coletor e temporariamente indisponível para outro. O painel deve dizer se conta presença, atualidade, coerência de manifesto ou aceitação final por determinada implementação.

A unidade também distribui peso. Contar observações favorece quem aparece mais vezes. Contar CAs iguala estruturas de tamanhos diferentes. Contar eventos exige definir qual fato cria a obrigação de revogar. Atribuir CAs hospedadas e delegadas a um RIR exige uma regra que não pode ficar escondida no código.

Todo percentual traz uma teoria do denominador

Uma conformidade possível pergunta se o certificado substituído entrou na próxima CRL. Outra verifica se todo certificado revogado e não expirado consta na CRL atual. Uma terceira testa se a CA publicou uma lista nova dentro de certo prazo após o evento. As três podem ser úteis e gerar porcentagens incompatíveis.

Dados ausentes abrem outras escolhas. Falha de coleta conta como descumprimento, como desconhecido ou como continuidade do último cache? Um certificado deixa o denominador ao expirar? Uma recuperação histórica reescreve a curva ou gera nova versão? Uma mudança de validador pode alterar o conjunto sem qualquer CA ter agido.

Essas decisões têm efeito institucional. A distância entre 9% e mais de 99% pode orientar confiança, auditoria, grants futuros e reputação. O leitor precisa separar conduta operacional, arquitetura, cobertura do coletor e convenção estatística antes de atribuir causa.

É aí que o financiamento pode gerar seu maior benefício. Um painel semanal comum permite observar reparos e regressões cedo. Só precisa preservar procedência. Uma linha contínua com população ou código trocado silenciosamente não é uma única série longitudinal.

Um comprovante que acompanha a nota

O comprovante começaria com um identificador estável e a versão semântica da métrica. Registraria a pergunta em linguagem direta, o objeto ou evento, o perfil RFC, o coletor, o retrato e a janela. Publicaria unidade, numerador, denominador, inclusões, exclusões, deduplicação e atribuição ao RIR.

Também explicaria coletas falhas, cache, objetos expirados, retratos ausentes e backfills. Separaria CAs hospedadas de delegadas e objeto presente de objeto válido para o RP. Versões de código e dados, consulta reproduzível, limitações, histórico de correções e digest do resultado completariam a trilha.

A interface pode continuar enxuta. “Mais de 99%, RC-2.1, população N, período X” é suficiente se levar à receita. Quando a cobertura cair, o painel pode mostrar desconhecido em vez de fabricar sucesso ou falha.

Versionar não congela o beta. Permite melhorar sem apagar o sentido anterior. O valor raro de catorze anos de dados é justamente distinguir uma mudança da operação de uma mudança na lente de observação.

Fontes

  1. ARIN — anúncio dos grants de 2026
  2. ARIN — página detalhada dos beneficiários
  3. RPKI Warehouse beta
  4. OpenAPI do RPKI Warehouse
  5. Cadência de assinatura da ARIN
  6. Atraso de CRL da ARIN
  7. Saúde dos dados do RPKI Warehouse
  8. RFC 6487 — perfil de certificados de recursos
  9. RFC 9286 — manifestos da RPKI