Resumo

  • draft-sparysh-pala-audit-00 foi anunciado em 3 de setembro de 2026. O Datatracker o classifica como Internet-Draft individual, sem endosso ou posição formal da IETF, sem RFC stream e sem Area Director responsável.
  • O texto apresenta o PALA-1 como wire format já existente e congelado na versão 1.0. O projeto Palimpsests fez esse freeze em 9 de agosto, antes do envio à IETF.
  • O draft relata cinco implementações, mas diferencia a referência dos autores de quatro reproduções baseadas no texto e verificadas com vetores fornecidos pelo próprio projeto.
  • Um run posterior contra a tag v1.0 encontrou ambiguidades e uma lacuna no pareamento de spans. O draft diz que a especificação mudou após o freeze, sem afirmar que bytes ou vetores foram alterados.
  • Um recibo enxuto deve identificar o objeto congelado, a autoridade do projeto, o estado na IETF, a issue, a classe da mudança, o decisor e o efeito para readers e writers existentes.

Duas decisões que não devem ser fundidas

O anúncio da IETF tornou o PALA-1 público em 3 de setembro. A página no Datatracker estabelece o limite institucional: qualquer pessoa pode apresentar um I-D, e este documento não tem endosso nem posição formal no processo da IETF. No corte da apuração, não havia RFC stream ou Responsible AD; o estado perante o IESG era apenas “I-D Exists”.

O cabeçalho interno aponta para Informational, enquanto o resumo do Datatracker não mostrava intended RFC status. Nenhum campo equivale a aprovação. O RFC Editor explica que um Internet-Draft é documento de trabalho, não RFC, e que sua publicação não garante aprovação futura. Mesmo uma eventual adoção por Working Group abriria outra etapa de discussão e revisão.

O projeto tomou sua decisão antes. Em 9 de agosto, o commit 50b47edb1ed8 mudou a especificação de Draft para “Frozen — v1.0”. O compromisso é definido em termos de wire: uma alteração incompatível exige novo format_version; profiles podem continuar alocando extensões em seus espaços. O I-D de setembro apresenta o formato como existente e diz que não o revisa.

Essa ordem pode ser saudável. Um projeto pode estabilizar uma interface para seus adotantes e depois submetê-la a uma comunidade mais ampla. O freeze pertence ao projeto e sua base instalada. A revisão institucional pertence aos atores e estados previstos no processo da IETF. Uma coisa não autentica a outra.

Implementações são evidência com procedência

A seção Implementation Status lista cinco implementações: a referência dos autores; uma criação de co-maintainer sob limite de contaminação declarado; e três trabalhos de pessoas externas ao projeto quando fizeram os runs. Uma delas tornou-se maintainer depois.

O draft evita somar todas como apoio equivalente. As quatro não referenciais foram escritas a partir do texto, sem acesso a uma implementação anterior, e testadas com vetores publicados pelo projeto. O próprio documento ressalva que não são vetores independentes. Reproduzir um texto, interoperar com outro produto e operar em produção continuam sendo evidências diferentes.

Isso dá substância à primazia do código em execução. Código não vota, mas expõe uma ambiguidade: hashes divergem, classificações não coincidem ou um resultado não pode ser recalculado. O registro de verificação mostra os defeitos e sua correção, em vez de esconder o caminho até o resultado.

O RFC 7942 define esse papel limitado. Uma seção Implementation Status pode informar maturidade, cobertura, versões, licença e experiência. Working Groups escolhem como usar o material. Uma implementação listada não recebe endosso da IETF, e a seção, dependente do tempo, costuma ser removida antes da publicação de um RFC.

O achado que veio depois da tag

O quinto run é a melhor prova de que o freeze precisa de escopo. Segundo o I-D, o implementador trabalhou contra pala1-v1.0, passou os testes publicados, construiu casos adversos e registrou oito ambiguidades e uma falha conceitual no pareamento de spans.

O texto afirmava que um crash deveria deixar um span visivelmente aberto, mas não definia uma checagem uniforme para produzi-lo. A solução não transformou todo trail incompleto em falsificação. Registrou o span sem par como advisory finding. O draft chama esse run de aquele que mudou a especificação após o freeze e diz que publicou o raciocínio e a decisão.

Nada aí demonstra uma mudança do wire. Mostra que bytes, interpretação, diagnóstico e profile são objetos diferentes. Uma frase pode ganhar precisão sem mudar offsets. Um verificador pode emitir novo aviso sem alterar o verdict da cadeia. Um profile pode evoluir mantendo o envelope. Cada caso impõe um custo distinto aos antigos readers e writers.

Sem uma disposição explícita, um crítico pode dizer que qualquer edição destruiu o freeze; um mantenedor pode dizer que vetores iguais provam semântica idêntica. A pergunta útil não é binária: o que mudou, quem classificou e o que uma implementação v1 precisa fazer?

Congelar somente o núcleo necessário

A especificação do projeto define header fixo de 156 bytes, TLVs, tipos e hash chain. Um verificador que encontra versão ou tipo desconhecido deve continuar validando a cadeia, relatar o item como não interpretável e não rejeitar o conjunto apenas por desconhecimento.

Um pequeno esqueleto mantém offsets em versões futuras: magic, versão, comprimentos, tipo, sequência, boot ID, hash anterior e digest do corpo. Essa estabilidade permite a um reader antigo localizar o próximo registro e verificar a cadeia. Não obriga que toda semântica permaneça imóvel.

Profiles tratam corpos EVENT, métricas agregadas, origem das folhas Merkle e vocabulário de roles. A documentação do deployment identifica o profile. É a lógica de minimum initial specification: tornar comum apenas a compatibilidade necessária e deixar escolhas futuras junto aos implementadores.

O PALA-1 também separa coerência interna, completude contra anchor e existência contra witness. Uma chain coerente não prova que o gravador falou a verdade. A limitação é um ato de contenção: o formato não toma poder sobre uma pergunta que seu mecanismo não responde.

O recibo mínimo

No lado do freeze, o recibo guarda commit, tag, hashes dos vetores, ator, data, exit test e pendências. O escopo deve escolher entre wire bytes, parsing spine, semântica normativa, profile, orientação de implementação e material de teste.

Cada issue posterior registra ID estável, revisão e seção, além da classe: editorial, interpretação, regra semântica, profile, extensão aditiva, reparo de vetor ou wire incompatível. A disposição nomeia o role que decidiu, a razão e o resultado: nenhuma alteração, esclarecimento, advisory, nova versão de profile, extensão, nota de compatibilidade, novo formato ou adiamento.

O efeito completa a decisão. O reader v1 ainda encontra limites e verifica a cadeia? O writer v1 continua conforme? É necessário mudar o profile? Correções futuras são anexadas ao histórico.

Em separado ficam os estados da IETF: individual I-D, discussão em venue identificado, WG adoption, consensus, IESG approval e RFC publication. Maintainers falam pelo projeto; não pela IETF. Um WG pode revisar sem possuir a base instalada. Um operador pode adotar voluntariamente sem inventar um standard.

O RFC 2026 combina implementação e teste com excelência técnica, documentação clara, abertura, justiça e revisões sucessivas. Código é parte da disciplina, não um atalho para autoridade.

Pelo enquadramento de Heng Lu, o comum deve ser mínimo, decisões futuras devem permanecer locais quando não rompem interoperabilidade, e adoção voluntária não deve ser convertida em mandato. O próximo review pode confirmar o PALA-1, pedir esclarecimento, corrigir profile ou exigir v2. Hoje não há base para prever. Há base para exigir que frozen não seja usado como substituto de objeto, compatibilidade, autoria e autoridade institucional.

Fontes

  1. Anúncio do Internet-Draft
  2. IETF Datatracker: PALA-1
  3. IETF Datatracker: histórico
  4. Arquivo IETF: versão 00
  5. Especificação PALA-1
  6. Commit de freeze 50b47edb1ed8
  7. Registro de verificação independente
  8. Vetores de teste
  9. Runs independentes
  10. RFC 7942: Improving Awareness of Running Code
  11. RFC 2026: The Internet Standards Process
  12. RFC Editor: How RFCs Are Created
  13. Heng Lu: Running-Code Primacy
  14. Heng Lu: Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption