Resumo

  • A página canônica de prop-174 usa prop-174 no título, na URL e no nome do anexo. O arquivo prop-174-v001.txt, porém, começa com prop-173, embora repita o mesmo título substantivo e identifique o mesmo autor.

  • A divergência não permite decidir, por inferência externa, qual superfície errou primeiro ou se apenas o cabeçalho precisa mudar. O corpo torna reconhecível o texto sobre Prop-125 e contatos de abuso, mas isso não concede a um leitor autoridade para corrigir o identificador oficial da APNIC.

  • O número da proposta é a chave que une índice, página, anexo, mensagem de lista, versão, avaliação, reunião e decisão. Se essa chave divergir, uma referência pode ser formalmente exata em sua superfície e, ainda assim, apontar para outro objeto institucional.

  • A resposta adequada é uma cadeia de correção, não uma normalização silenciosa: original e SHA-256 preservados, ID autorizado declarado, diferença classificada, arquivo corrigido ou versão sucessora, aviso atribuível e propagação para todos os registros posteriores.

O conflito está nas duas primeiras linhas de prova

A página canônica se intitula prop-174: Align implementation of Prop-125 in APNIC Policy (APNIC-127). Sua URL contém /prop-174/, e o link da primeira versão se chama prop-174-v001.

O anexo correspondente é prop-174-v001.txt. Sua primeira linha substantiva, entretanto, diz prop-173: Align implementation of Prop-125 in APNIC Policy (APNIC-127).

Depois do número, as palavras coincidem. As duas superfícies também nomeiam Alban Kwan. A divergência está, portanto, no identificador que deveria manter página e arquivo sob a mesma identidade.

O corpo vinculado trata de Prop-125 e de obrigações propostas para contatos de abuso. Ele descreve abuse-mailbox funcional e monitorada, relatórios automáticos, proibição de formulário web como único canal e validação semestral.

Também prevê a marca Invalid, limitação de MyAPNIC, avisos graduais e possível encaminhamento às breach provisions do Membership Agreement. O vocabulário de IRT, abuse-mailbox, abuse-c, MyAPNIC e Whois ajuda a reconhecer o objeto substantivo anexado.

Essa coerência de título, autoria e corpo permite identificar o arquivo como o texto de abuso ligado à página. Não permite reescrever, por conta própria, o número que a APNIC publicou dentro do anexo.

A cautela é indispensável porque a navegação lista separadamente prop-173: Copyright and Acceptable Use Terms for APNIC Directory Services. A APNIC já atribuiu prop-173 a outro objeto institucional, com outro tema.

O problema não é que o corpo do anexo de prop-174 seja o texto sobre termos do diretório. As provas apontam o contrário. O problema é que o próprio arquivo usa uma chave já ocupada por outra proposta.

O estado atual não resolve a identidade

A página marca a proposta como Published to Mailing List. A versão 1 foi publicada em 17 de agosto de 2026. Não há versão anterior indicada nem Secretariat impact assessment disponível nas superfícies verificadas.

Também não há errata explícita, aviso de correção, anexo sucessor ou explicação pública para a divergência. O pacote mostra o conflito; não mostra uma resolução atribuível.

Isso não prova qual superfície errou primeiro. A página pode refletir o ID autorizado e o arquivo conter um cabeçalho incorreto. O inverso também não pode ser excluído apenas com as duas fontes.

Nem sequer é seguro concluir que o número seja o único elemento a corrigir. O título e o corpo são coerentes entre si, mas somente a APNIC pode declarar se a diferença é de cabeçalho, metadados, versão ou substância.

O conflito tampouco prova que participantes tenham confundido os dois textos. Não há evidência de avaliação, consenso, adoção, implementação, violação real ou revogação sob a proposta.

A investigação deve parar nesse limite. O fato verificável é uma divergência oficial não acompanhada, nas superfícies examinadas, por uma cadeia pública de correção.

O número é uma chave de junção

Uma proposta de política não vive em uma única página. Seu número costuma permitir que objetos publicados em momentos diferentes sejam reconhecidos como partes da mesma trajetória institucional.

O índice aponta para uma página. A página aponta para um anexo. Uma mensagem de lista anuncia uma versão. Uma avaliação pode examinar essa versão. Materiais de reunião podem registrar discussão, e uma decisão posterior pode citar a proposta.

O identificador faz a junção entre esses registros. O título ajuda, mas não substitui a chave. Títulos podem ser abreviados, traduzidos, ajustados ou repetidos em documentos diferentes.

Quando duas superfícies oficiais usam números distintos, a exatidão formal deixa de garantir identidade. Uma ata que cite prop-174 pode ser fiel à página, enquanto o anexo arquivado que os participantes abriram se identifica como prop-173.

Uma avaliação futura pode declarar que examinou a versão 1 de prop-174. Sem uma relação de correção, permanece a pergunta: foi avaliado o arquivo original com cabeçalho prop-173, uma cópia corrigida ou outro texto?

O mesmo vale para uma mensagem de lista. Ela pode usar o número da página, anexar o arquivo divergente ou reproduzir seu cabeçalho. Cada elemento pode estar transcrito corretamente e, ainda assim, formar uma cadeia ambígua.

Isso é deriva de identidade. Não exige alteração maliciosa, armazenamento corrompido ou discussão inválida. Basta que registros posteriores adotem superfícies diferentes sem documentar a relação entre elas.

Por que uma edição silenciosa não basta

A correção mais simples parece ser trocar prop-173 por prop-174 no arquivo existente. Esse gesto pode limpar o presente, mas cria um problema histórico se os bytes anteriores desaparecerem.

Os primeiros participantes teriam visto uma versão diferente daquela disponível depois no mesmo endereço. Uma comparação futura não conseguiria provar a mudança, seu momento ou seu alcance sem uma cópia preservada e um hash do original.

A URL estável não resolve esse problema. Ela localiza um recurso, mas não demonstra que o conteúdo recuperado hoje é idêntico ao conteúdo disponível em 17 de agosto de 2026.

Por isso, o original precisa ser preservado como registro. Seu SHA-256 deve ser publicado ou referenciado de maneira verificável. O valor não está fornecido no pacote e não deve ser inventado.

A APNIC pode então escolher entre uma errata, uma versão sucessora ou uma republicação claramente identificada. As opções têm custos diferentes, mas todas precisam conservar a relação entre antes e depois.

Se houver correção no mesmo local, a página deve dizer que o conteúdo foi alterado, quando, por quem e com qual hash anterior. Se houver versão 2, ela deve apontar para prop-174-v001.txt como predecessora.

Se a solução for uma errata sem substituir o arquivo, o aviso deve declarar qual ID é autorizado e como os registros posteriores devem citar a versão original. A errata precisa ficar visível nas duas direções.

O que não funciona é a normalização silenciosa. Ela melhora a aparência atual e enfraquece a prova do que os participantes realmente receberam.

Cabeçalho, metadados ou substância

A correção precisa classificar o que mudou. “Erro de digitação” é uma conclusão informal; não informa se a alteração atingiu somente a primeira linha, outros metadados ou o conteúdo normativo.

Uma classe de cabeçalho indicaria que o texto substantivo permaneceu byte a byte igual, exceto pelo identificador declarado. Uma classe de metadados poderia incluir nome, versão, data ou referência externa sem alterar as disposições.

Uma alteração de substância exigiria outro tratamento. Mesmo uma frase ajustada para coerência não deveria ser absorvida pela mesma correção sem um diff e uma nova versão claramente identificada.

O arquivo atual parece substantivamente coerente com a página sobre Prop-125. Ainda assim, um observador externo não deve transformar essa impressão em autoridade para certificar que apenas a primeira linha está errada.

O recibo deve resolver a dúvida com um diff completo. Se só o número mudou, o diff provará isso. Se houve outras alterações, elas se tornarão visíveis antes que avaliações e decisões dependam da versão corrigida.

Um recibo compacto de correção

O objetivo do recibo não é burocratizar um ajuste pequeno. É fixar a identidade autorizada e preservar o que já foi publicado, para que cada ato posterior saiba exatamente qual objeto recebeu.

Campo do recibo Conteúdo mínimo Pergunta que resolve
ID do evento Chave pública da correção Qual correção deve ser citada?
ID e título autorizados Número e título declarados pela APNIC Qual é a identidade institucional vigente?
Superfícies afetadas Página, anexo, mensagem de lista e outros registros alcançados Onde a divergência apareceu?
Original URL, momento de captura e SHA-256 de prop-174-v001.txt Quais bytes estavam disponíveis antes da correção?
Identificador conflitante prop-173 e sua localização no arquivo Qual elemento produziu a divergência?
Corrigido URL, versão, momento e SHA-256 posteriores Qual conteúdo deve ser usado depois?
Classificação Cabeçalho, metadados ou substância Qual foi o alcance material da mudança?
Diff Comparação completa entre original e corrigido O que mudou além do número?
Responsável e momento Unidade ou função responsável, data e hora Quem autorizou a correção e quando?
Aviso na lista Referência ao anúncio enviado aos participantes Como os primeiros leitores foram informados?
Propagação Relações com avaliação, APNIC 62, atas e decisão Quais registros posteriores herdaram a correção?
Sucessão Predecessor, sucessor e regra de citação Como versões antigas e novas se relacionam?
Incerteza restante Questões que o recibo não resolveu Que limite ainda deve acompanhar a referência?

O ID do evento evita que a correção fique conhecida apenas por uma frase solta na página. Ele permite que avaliação, reunião e decisão apontem para a mesma disposição corretiva.

O hash original fixa a evidência histórica. O hash corrigido fixa o novo objeto. O diff explica a passagem entre ambos. Nenhum dos três substitui os demais.

A declaração do ID autorizado é a parte que um editor externo não pode produzir. Ela precisa vir da APNIC e deve indicar como citar o arquivo original e a versão posterior.

A correção precisa viajar com a proposta

Publicar um recibo apenas na página canônica pode não alcançar quem recebeu a versão pela lista. O aviso de correção deve seguir o mesmo canal pelo qual a proposta foi apresentada aos participantes.

Uma futura Secretariat impact assessment, caso seja publicada, deve declarar qual versão e qual hash foram examinados. Citar apenas prop-174-v001 não bastaria se esse nome já tiver apontado para conteúdos sucessivos.

Materiais da APNIC 62 deveriam manter a mesma disciplina. Uma pauta, apresentação ou registro de discussão precisa indicar se se refere ao original divergente, à errata ou a uma versão sucessora.

Atas posteriores não precisam reproduzir todo o recibo. Basta usar o ID autorizado e apontar para a relação de correção, de modo que o leitor reconstrua qual texto estava em discussão.

Se houver uma determinação de consenso, ela deve identificar a versão recebida. O mesmo vale para qualquer etapa posterior de adoção ou implementação. Isso não presume que essas etapas ocorrerão.

A propagação também deve alcançar a navegação que já distingue prop-173 de prop-174. O objetivo não é fundir os objetos, mas impedir que a chave conflitante do anexo contamine referências futuras.

Cenários que o recibo precisa distinguir

No primeiro cenário, a APNIC conclui que prop-174 é o ID autorizado e que somente o cabeçalho do arquivo estava incorreto. O original permanece disponível, e uma versão corrigida mostra um diff de uma linha.

No segundo, a APNIC publica uma errata sem substituir o arquivo. A página e a lista passam a informar que o anexo original se identifica de modo conflitante, mas deve ser relacionado ao ID autorizado declarado.

No terceiro, uma versão 2 incorpora a correção e talvez outras mudanças. O recibo precisa separar o ajuste de identidade das alterações substantivas, para que ninguém atribua todo o diff ao número.

No quarto, a revisão institucional conclui que a situação é mais ampla do que o cabeçalho. O recibo registra a incerteza restante e impede que uma correção parcial seja apresentada como solução completa.

No quinto, nenhuma correção é publicada antes de uma avaliação. Nesse caso, a própria avaliação deveria declarar a divergência e identificar os bytes examinados, sem presumir qual número está certo.

Esses cenários não descrevem eventos ocorridos. Eles testam como a cadeia pode permanecer verificável sem antecipar a decisão da APNIC.

O que as provas não permitem dizer

As duas fontes não demonstram que o arquivo tenha sido alterado depois da publicação. Também não mostram que a divergência resultou de corrupção, intenção maliciosa ou interferência no processo.

Não há prova de que participantes, avaliadores ou decisores tenham usado a identidade errada. Não há Secretariat impact assessment para comparar, nem versão sucessora ou ata vinculada no pacote.

O estado Published to Mailing List não equivale a avaliação concluída, consenso, adoção ou implementação. As disposições sobre validação semestral, marca Invalid, limitações em MyAPNIC, avisos e encaminhamento ao Membership Agreement continuam sendo texto proposto.

Também não se deve converter etapas propostas em política atual da APNIC. O corpo serve aqui apenas para identificar o objeto substantivo anexado e separar esse objeto da proposta de copyright e termos de uso dos serviços de diretório.

A divergência tampouco invalida automaticamente a discussão. O problema analisado é anterior: sem uma identidade corrigida e preservada, atos futuros podem acumular referências que não demonstram qual versão receberam.

O ponto de correção

A APNIC ainda está em uma posição documental favorável. A página indica uma primeira versão, não lista antecessora e não contém uma avaliação de impacto. A cadeia institucional ainda parece curta nas superfícies verificadas.

Isso torna a correção agora mais barata do que depois. Original e hash podem ser preservados antes que novas versões, avaliações, materiais de reunião e decisões criem dependências sobre a chave divergente.

O objetivo não é apagar prop-173 do arquivo histórico. É impedir que esse identificador continue sem explicação dentro de um anexo chamado prop-174-v001.txt, enquanto outra proposta oficial já ocupa prop-173.

Uma correção atribuível deve declarar o ID autorizado, classificar o alcance, mostrar o diff, preservar os dois hashes e indicar como todos os registros posteriores devem citar original e sucessor.

Assim, a APNIC não precisaria fingir que a divergência nunca existiu. Poderia convertê-la em um evento documentado, delimitado e verificável antes que o número passe a sustentar avaliações e decisões.

A falha relevante não seria um caractere trocado. Seria perder a capacidade de provar qual proposta cada ato institucional recebeu. O recibo de correção existe para evitar essa perda.

Fontes