Resumo

  • Em 29 de agosto, dois links sem extensão para atas do IETF 84 não recuperavam os documentos de AVTCORE e MMUSIC, embora arquivos correspondentes aparecessem numa cópia via rsync.
  • A equipe da IETF ampliou o conjunto de extensões testadas pelo servidor, incluindo PDF, HTM e outras variantes encontradas nos dados; em 6 de setembro, as duas rotas respondiam com HTTP 200.
  • Existência em armazenamento, acesso público, identidade do objeto devolvido e integridade dos bytes são quatro estados diferentes, mesmo quando a tela mostra apenas “funcionou” ou “falhou”.
  • Um manifesto legível por máquina deve vincular cada item a identificador estável, caminho exato, formato, tamanho, hash, versão, correção, sucessão e última verificação pública.
  • A proposta não substitui as atas nem declara que elas são completas ou corretas. Ela torna auditável a escolha que o servidor faz ao resolver um endereço histórico.

O espelho enxergava o que o site não alcançava

Jörg Ott relatou em 29 de agosto que os ponteiros do IETF 84 não abriam as atas de AVTCORE e MMUSIC, enquanto alguns outros grupos escolhidos ao acaso pareciam normais. No relato original, sugeriu uma verificação automática de links. Também registrou uma resposta 1015 da Cloudflare durante a investigação feita de uma conexão móvel remota ruim.

Isso documentava uma falha diante do leitor, não o desaparecimento do material. Carsten Bormann consultou uma cópia diferente e encontrou arquivos de ambos os grupos num acervo sincronizado por rsync que disse ocupar 68 GB. É evidência sobre dois artefatos em um retrato local, e não garantia de que todo o passado foi preservado ou que cada réplica sempre teve os mesmos bytes. Ainda assim, mostrou que presença e navegabilidade haviam se separado.

Ott depois relacionou o problema às variantes de sufixo PDF e HTM. Em 2 de setembro veio a explicação operacional. Páginas antigas apontavam para nomes de atas sem extensão, e o servidor tentava apenas uma lista limitada. A equipe da IETF expandiu essa lista para .pdf, .htm e outras variantes existentes nos dados, informando que os casos citados e vários semelhantes deveriam voltar a funcionar.

A resposta também disse que o limite de requisições era alto e difícil de atingir por navegação comum, pedindo o Ray ID da Cloudflare se o evento se repetisse. Esse esclarecimento não nega o 1015 observado e não sustenta uma alegação de indisponibilidade geral. Uma resolução de nome incompleta e uma barreira de acesso são falhas diferentes.

Um conteúdo errado também pode chegar com sucesso

Numa checagem limitada em 6 de setembro, a rota de AVTCORE devolveu um PDF de 242.140 bytes, com Last-Modified de 2012. O SHA-256 observado foi 937e224285a7eae6bf1cbeb9106e5eb0bf4df7b34bf02a10587f6da9ef4e49e1. A rota de MMUSIC serviu HTML, também datado de 2012, com SHA-256 88a6f5fd2d5459bfa1c66dc7d24b54e441a4e05507e009adf99409486c19a214.

Esses hashes são observações de uma data, não identidades canônicas garantidas para sempre. Endereços diretos terminados em avtcore.html e mmusic.html também respondiam, mas traziam bytes diferentes, data de 2021 e páginas de resumo do grupo — não as atas. Acrescentar .html por intuição teria produzido uma resposta tecnicamente bem-sucedida para o objeto errado.

O índice dos anais do IETF 84 é uma interface de leitura. A tentativa de múltiplas extensões preserva links antigos sem reconstruir página por página. Esse benefício não deve ocultar quatro perguntas independentes:

  1. Existência: algum armazenamento ou espelho possui um item associado à sessão?
  2. Alcance: uma requisição pública consegue obter algo agora?
  3. Identidade: a resposta é a ata declarada, e não uma página de grupo ou outra candidata?
  4. Integridade: os bytes correspondem à versão declarada naquele momento?

O reparo atuou diretamente sobre o alcance. O espelho deu evidência limitada de existência. Formato, tamanho e hash ajudam a testar identidade e integridade. Nada disso, isoladamente ou em conjunto, certifica que a ata seja completa, fiel à reunião ou aprovada além do procedimento que a produziu.

O registro nasce antes de ser publicado e muda depois

O RFC 2418 exige relatório de cada sessão de grupo de trabalho, atribui ao chair a responsabilidade de garantir a produção das atas e inclui arquivos públicos de listas no registro do trabalho. Também orienta que decisões importantes e seu histórico sejam resumidos e preservados. A rota de acesso, portanto, afeta a capacidade futura de reconstruir a deliberação.

A orientação atual para chairs torna obrigatório o envio das atas, define formatos aceitos e distingue a janela de submissão da janela de correções. Em 13 de agosto, um lembrete da Secretaria sobre o IETF 126 listou sessões ainda sem atas antes do prazo do dia 14 e indicou 8 de setembro para correções. Aquela lista não prova o estado final. Ela mostra que ainda não enviado, recebido, publicado, corrigido, substituído e hoje acessível são etapas que não podem ser reduzidas a uma coluna binária.

Um vínculo público entre nome e bytes

O manifesto de integridade deve registrar, para cada item, número da reunião, grupo ou sessão, tipo de material e identificador lógico estável. Esse nome seria ligado ao caminho concreto do objeto, tipo MIME, tamanho em bytes e hash criptográfico.

Também devem constar datas de recebimento e publicação, versão, condição atual, corrigida ou substituída, referência à sucessora, última checagem pública bem-sucedida e evento de reparo ou migração que mudou a forma de acesso. A proveniência pode identificar um papel quando isso for seguro, sem divulgar mensagens privadas, informações pessoais de rede, credenciais ou detalhes de proteção.

Uma correção acrescentaria nova versão e relação explícita de sucessão. Não faria um hash antigo passar silenciosamente a significar bytes novos. O link amigável pode continuar levando o leitor à versão corrente; cada objeto histórico permanece citável e verificável pelo manifesto.

O alcance dessa ferramenta é propositalmente estreito. Ela não reescreve a ata, não avalia se o relato é fiel e não confere autoridade. Permite classificar falhas como artefato ausente, objeto presente com link não resolvido, candidato incorreto, formato inesperado, controle de acesso, divergência de checksum, versão substituída ou causa desconhecida.

As verificações públicas devem ser espaçadas, para não gerar a carga que tentam observar. Verde significaria apenas que, em horário registrado, o objeto declarado foi obtido e correspondeu em formato, tamanho e hash. É uma afirmação menor do que “o arquivo está perfeito”, mas muito mais útil.

Fontes

  1. Relato inicial de Jörg Ott
  2. Carsten Bormann sobre a cópia via rsync
  3. Detalhe sobre extensões PDF e HTM
  4. Explicação e ajuste da equipe da IETF
  5. Lembrete sobre atas do IETF 126
  6. Orientação da IETF sobre materiais de reunião
  7. RFC 2418
  8. Anais do IETF 84
  9. Rota das atas de AVTCORE
  10. Rota das atas de MMUSIC
  11. Lu Heng sobre a primazia do código em funcionamento