Resumo

  • O aviso de manutenção de 28 de julho de 2026 disse que Whois, Whois-RWS, RDAP, IRR e o repositório RPKI continuariam operacionais, mas que nenhuma atualização seria publicada na janela.
  • ARIN Online, RESTful Provisioning, RPKI Up/Down e RPKI Repository Publication ficariam indisponíveis; chamadas REST poderiam entrar em fila e talvez precisassem ser reenviadas.
  • O Apêndice C do relatório anual de 2025 traz seis resultados de disponibilidade—99,9, 99,9, 99,9, 100, 100 e 99,9%—sem campo de frescor, idade dos dados, última publicação ou atualização autoritativa.
  • Uma ficha pública de dois relógios pode separar consulta, aceitação de escrita, publicação e reconciliação, sem revelar arquitetura interna nem transformar manutenção planejada em incidente.

Uma página de status é mais útil quando deixa claro o alcance da frase que está fazendo. Se diz que um serviço está operacional, ela informa que a superfície observada pode responder. Não precisa, por isso, prometer que toda cadeia de mudança está avançando.

Foi essa a separação feita pela ARIN ao anunciar a manutenção de 28 de julho de 2026. ARIN Online, RESTful Provisioning, RPKI Up/Down e RPKI Repository Publication seriam indisponíveis. Whois, Whois-RWS, RDAP, IRR e o repositório RPKI permaneceriam operacionais. Mas haveria uma condição adicional: atualizações não seriam publicadas. Chamadas ao RESTful Provisioning poderiam ser enfileiradas e, depois da manutenção, talvez tivessem de ser submetidas novamente.

Uma chamada enfileirada não é uma chamada perdida. Um período sem publicação não é prova de resposta desatualizada. A fonte tampouco prova dano a operador algum, falha de recuperação ou problema oculto. O valor do aviso está exatamente em ser mais modesto: ele identifica uma operação em que o acesso de leitura, o recebimento de escrita, a publicação externa e o acerto posterior não andam no mesmo passo.

O leitor disponível ainda tem valor

Há uma boa razão para não desligar tudo. Um operador que consulta uma informação já publicada pode continuar precisando dela. Um serviço de diretório pode ser útil sem que aceite uma alteração naquele instante. Um repositório pode continuar a entregar objetos já publicados quando a publicação de objetos novos foi intencionalmente suspensa.

No caso de RPKI, essa diferença é mais do que semântica. A documentação de RPKI hospedado, Repository Publication Service, Trust Anchor Locator e termos RPKI distingue funções de certificação, publicação, repositório e parte confiadora. Validadores trabalham com material assinado publicado e com cache local. Isso explica por que material verificável pode continuar disponível enquanto uma nova publicação espera.

Não decorre daí uma idade aceitável única para todos, nem uma presunção de que cada resposta é a mais recente possível. Decorre apenas que preservar o leitor é uma escolha operacional defensável. A página pública deve conservar essa utilidade sem transformar o leitor em certificado de que a escrita foi aceita, de que a publicação avançou ou de que a fila acabou.

A Statuspage da ARIN já apresenta componentes. Essa observação é pontual: não demonstra métricas internas, dependências privadas, metas de recuperação ou identidade de fornecedor. Mostra, porém, que a instituição já reconhece publicamente que serviços têm contornos distintos.

A tabela anual responde a uma pergunta importante

O Apêndice C do Relatório Anual de 2025 apresenta seis categorias: ARIN Online, Whois/RDAP, Resource Public Key Infrastructure, RDAP Bootstrap, Internet Routing Registry e Registration Transaction Service. Os resultados de 2025 aparecem na ordem de 99,9, 99,9, 99,9, 100, 100 e 99,9%, acompanhados de números por componente.

Disponibilidade não é um indicador decorativo. Se uma interface pública não responde, importa pouco ao leitor saber que uma atualização foi processada em algum lugar. A tabela dá uma medida legítima da capacidade de alcançar os serviços nomeados.

O limite é específico. Na tabela congelada da página 24, não há coluna ou rótulo para freshness, data age, last published ou authoritative update. Isso não autoriza concluir que a ARIN não acompanhe tais dados internamente, que nenhuma outra superfície os exiba ou que a organização não tenha controle de recuperação. Diz apenas que o relatório público observado não entrega ao leitor uma medida de quando o estado autoritativo avançou pela última vez.

É aí que o aviso de julho se torna instrutivo. O relatório de disponibilidade pode dizer “a consulta chega”. Ele não consegue, sozinho, responder “qual é a idade do estado autoritativo que sustenta esta consulta?”. Ambas as perguntas merecem um bom resultado; são perguntas diferentes.

Um cartão de serviço para duas promessas

O objeto necessário não é um painel técnico novo, mas uma ficha concisa. Seu primeiro relógio deve trazer o componente, a interface de leitura e a disponibilidade de consulta. Seu segundo relógio deve indicar se escritas são aceitas, qual é a cadência esperada de publicação, quando ocorreu a última publicação autoritativa bem-sucedida e qual é a idade máxima esperada no estado atual.

Em manutenção, a ficha deve dizer também se um pedido foi recusado, entrou em fila, foi reproduzido, exige novo envio ou está reconciliado. Um identificador de versão e um registro de correção permitiriam explicar uma mudança posterior sem apagar o estado que havia sido comunicado.

Isso não pede senhas, topologia, procedimentos de segurança ou listas de contatos. Tampouco força RPKI, RDAP, IRR e uma transação de registro a compartilhar o mesmo limiar de tempo. Define o que a borda pública consegue afirmar. O resumo da Statuspage pode declarar os sistemas operacionais no instante da consulta; a última publicação autoritativa e a reconciliação da fila são fatos adicionais, não acusações.

Fontes

  1. Aviso de manutenção da ARIN
  2. Relatório Anual da ARIN de 2025, Apêndice C
  3. Relatórios de nível de serviço da ARIN
  4. Statuspage da ARIN e resumo
  5. RPKI hospedado, RPS, TAL e termos RPKI