Resumo

  • prop-167-v002 reuniu duas entregas: estatísticas públicas horárias de WHOIS/RDAP e uma função no MyAPNIC para o titular observar consultas aos próprios recursos.
  • A Resolution 2025-32 endossou o fluxo público. Para o MyAPNIC, o EC disse que custo, alocação de recursos e possíveis preocupações de privacidade superavam o benefício imediato, tornando a função inviável naquele momento.
  • A entrega endossada é verificável: o arquivo começa em 30 de junho de 2026 e o JSON corrente separa RDAP e WHOIS.
  • O estado geral Implemented resume o escopo executado, mas não informa sozinho que o texto de consenso continha uma segunda saída com disposição diferente.

O sinal mais forte de que uma política chegou à operação não é uma apresentação de projeto. É um artefato que outra pessoa consegue buscar. No FTP da APNIC há um JSON corrente, seu checksum e um arquivo por ano. Em junho de 2026, a listagem começa no dia 30 e apresenta arquivos compactados hora a hora.

O conteúdo atual tem dois blocos principais, RDAP e WHOIS. Cada um declara a janela de uma hora, totais, tipos de consulta e distribuição por ASN, incluindo contagem de IPs de origem distintos. A publicação é concreta o suficiente para permitir inspeção sem acesso aos sistemas internos.

A página de prop-167 associa 30 de junho a Implementation Complete e marca o estado como Implemented. O feed público, portanto, tem anúncio, data e produto.

O encerramento fica incompleto quando se volta ao objeto aprovado pela comunidade. A versão 2 propunha duas saídas, e o EC não lhes deu a mesma disposição.

Saída Disposição do EC em 4 de dezembro de 2025 Evidência pública em agosto de 2026
Estatísticas públicas horárias e legíveis por máquina Endossada na Resolution 2025-32 JSON atual e arquivos horários desde 30 de junho
Visão, no MyAPNIC, de consultas aos recursos do titular Considerada inviável naquele momento pelos motivos publicados Nenhuma fonte verificada prova implementação ou nova decisão

A segunda linha não autoriza chamar a primeira de parcial no sentido de defeituosa. O EC definiu o escopo executável; a APNIC o entregou. O problema é outro: uma palavra no nível da proposta não guarda a diferença entre o que foi endossado e o que parou na etapa anterior.

O texto criou um produto público e um produto autenticado

prop-167-v002 foi publicado em 21 de agosto de 2025. Segundo a proposta, com base em dados internos da APNIC, os serviços responderam a aproximadamente 5,5 bilhões de consultas entre 1º de abril e 30 de junho daquele ano. Em algumas horas, RDAP teria recebido consultas de mais de 365 mil IPs únicos.

Esses números têm uma fronteira de proveniência. O material público analisado não reproduz a conta de 2025 e não permite apontar abuso por um ASN. A proposta menciona como possibilidades mineração, coleta em massa e análise automatizada; não transforma nenhuma delas em conclusão sobre usuários específicos.

O produto público pretendido atualizaria a cada hora dados em JSON ou CSV. Deveria separar WHOIS e RDAP, incluir pelo menos os mil principais ASNs de origem, a quantidade de IPs de origem por ASN e metadados de tipo e método de consulta.

O segundo produto exigia autenticação e vínculo com a titularidade. Dentro do MyAPNIC, cada detentor veria quantas vezes seus endereços ou ASNs foram consultados, com divisão por tipo e, se possível, por ASN de origem. O nível de detalhe e o público da informação eram diferentes.

A avaliação de impacto acompanhou essa diferença. Para a publicação geral, falou em extração e distribuição best-effort, sem SLA. Para a emenda do MyAPNIC, registrou que, se viável, haveria grande volume de trabalho de logging nos sistemas WHOIS subjacentes.

Em 11 de setembro, v002 chegou a consenso no APNIC 60. O período final terminou em 14 de outubro e levou o texto ao EC. O consenso preserva as duas propostas de entrega; não elimina o filtro institucional seguinte.

A etapa de endorsement escolheu o que avançaria

O PDP da APNIC diz que, mantido o consenso, o SIG Chair solicita endorsement ao EC. Depois, o Secretariat implementa. Não há base para tratar o papel do EC como uma intrusão que o leitor possa ignorar.

Na Resolution 2025-32, o EC endossou v002 com respeito à publicação de estatísticas em tempo real ou quase real. Em seguida, isolou o pedido do MyAPNIC. Custo, recursos e possíveis questões de privacidade superavam o benefício imediato; por isso a função não era considerada viável naquele momento. A decisão foi unânime.

Esse vocabulário impede atalhos. With respect to marca escopo. As três razões pertencem ao registro público e não podem ser substituídas por suspeita. At this time fixa a avaliação em uma data; não promete retomada e tampouco declara abandono permanente.

Separar as entregas pode ter sido exatamente o que permitiu que o fluxo público saísse no prazo. Uma função agregada e uma visão autenticada de consultas não precisam compartilhar a mesma arquitetura, risco ou custo. Um bom histórico deveria proteger essa distinção, inclusive para não atribuir ao time técnico uma obrigação que o EC não encaminhou.

O resultado entregue merece ser contado como sucesso

A atualização de APNIC 61 ainda colocava o trabalho em implementação, com conclusão prevista para o fim do segundo trimestre. A descrição pública se concentrava em estatísticas de diretório para interessados. O roadmap atual fala em implementar os requisitos endossados.

O arquivo fecha essa sequência. Os primeiros arquivos de 30 de junho ligam uma data de produção à data de conclusão. O JSON atual prova continuidade da superfície e uma estrutura reconhecível. A análise não depende de supor o que uma equipe quis dizer com “completo”.

Isso não garante perfeição. Uma captura não demonstra que nunca houve lacuna, que o schema permanecerá igual ou que cada nuance do texto foi satisfeita. Como a avaliação exclui SLA, uma interrupção também não deve ser rotulada automaticamente como violação. O histórico de 2026 não refaz o cálculo de 2025.

Mas permite uma conclusão segura: a APNIC publicou a saída pública em formato estruturado e horário. A lacuna documental está no nível de estado, não no nível do feed.

Um rótulo pode resumir, mas precisa mostrar sua base

Na página canônica, a versão 2 e a avaliação ainda exibem o requisito do MyAPNIC. A história registra consenso, fim da chamada, endorsement e conclusão. O visitante, porém, não encontra nas linhas finais a separação feita pela Resolution 2025-32.

Se Implemented quer dizer “o escopo endossado foi entregue”, o termo é sustentado pelos fatos. Se for entendido como “todo o texto de consenso está em produção”, a leitura é ampla demais. O problema não é a existência do resumo; é a ausência de uma regra pública que mostre como ele foi derivado.

Uma proposta tem um identificador. Suas saídas podem ter decisões independentes. Em sistemas de dados, isso é uma questão de cardinalidade: uma linha-pai não substitui os estados das linhas-filhas. Em governança, a consequência é histórica: a decisão mais específica some da superfície mais consultada.

O estado do MyAPNIC deve evitar vocabulário acusatório. Failed pressupõe uma obrigação de entrega. Abandoned remove o limite temporal. O registro pode dizer: não endossado em 4 de dezembro de 2025; inviável naquele momento pelas razões declaradas; reconsideração posterior não estabelecida.

Guardar o escopo não exige abrir logs

O remédio não é publicar consultas individuais nem construir a função rejeitada por via editorial. É expor uma relação curta entre texto, autoridade, disposição e produto.

Para cada saída, a página poderia registrar versão e fingerprint, estado comunitário, resolução do EC e decisão. Na saída endossada, apontaria o diretório FTP, formato e primeira produção verificável. Na outra, preservaria a razão datada e qualquer novo gatilho de reconsideração, se ele aparecer.

Campo Por que importa
Versão e hash Identifica o texto efetivamente submetido às etapas
Saída e trecho Evita tomar a proposta inteira como unidade mínima de decisão
Consenso e final comment Mantém o estado comunitário separado da execução
Resolução e disposição Mostra quem encaminhou qual escopo
Artefato e início de produção Liga autorização a resultado observável
Estado da saída não endossada Diferencia decisão temporária, revisão e substituição
Correção e supersession Permite mudança sem apagar a história
Derivação do estado geral Explica o conteúdo de Implemented

Esse registro não duplica o PDP. Apenas projeta o resultado do processo já concluído. Custos, testes detalhados, logs e avaliação de privacidade podem continuar protegidos.

O que as fontes não resolvem

Não há prova pública de que a APNIC tenha reavaliado a visão por recurso, nem de que jamais o tenha feito internamente. Um release genérico do MyAPNIC não demonstraria a função; seria necessário citar o mecanismo de visibilidade de consultas.

Não há caso de dano a titular, vazamento, breach de SLA ou incidente de segurança. Também não se pode concluir que as preocupações de privacidade eram artificiais. O artigo examina o registro de escopo, não o mérito técnico de uma arquitetura que não foi publicada.

As fontes tampouco definem a convenção geral de status da APNIC após endorsement limitado. Manter o rótulo geral e acrescentar suas linhas de base seria compatível com uma convenção que considere concluído o escopo endossado.

O feed é um resultado real. A decisão sobre MyAPNIC também é real. Um histórico institucional fiel não precisa escolher entre eles: precisa mostrar onde cada um terminou.

Fontes