Resumo

  • O Final Review de um RFC, anteriormente chamado AUTH48, começa depois que um stream de publicação aprova um Internet-Draft. Os autores conferem conteúdo, marcação e formatos, respondem às perguntas e autorizam a publicação; é um controle efetivo, não uma nova votação da IETF.
  • Depois da entrada na fila, o RFC Production Center detém o controle de alterações da cópia de produção. Correções editoriais podem avançar sob essa custódia, mas acréscimos, exclusões e mudanças técnicas ou além do editorial exigem aprovação do stream de origem.
  • O piloto de kramdown-rfc e GitHub de 2025–2026 tornou essa fronteira observável. Em 27 de agosto de 2026, o RFC-to-be 10025 tinha página de Final Review e repositório público, enquanto o endereço de informações do RFC 10025 ainda não apresentava um registro publicado.
  • Um recibo confiável deve preservar a revisão aprovada, a decisão do stream, o conjunto de edições do RPC, a classificação das questões, as aprovações de autores e do stream, os hashes dos artefatos finais e o anúncio de publicação. Implementação e operação continuam sendo outra camada de prova.

O pull request que parecia uma nova votação

A captura de tela não era falsa. Havia uma branch RPC-edits, issues em aberto, um pedido de revisão e autores que ainda não haviam confirmado a versão final. O erro surgiu quando esses sinais foram comprimidos em uma única condição: “não aprovado”. Em seguida vieram descrições ainda mais fortes — “os autores vetaram”, “o consenso foi reaberto”, “a decisão agora acontece no GitHub”.

Final Review é o intervalo de custódia entre dois atos institucionais diferentes. Antes dele, um dos streams aprova um Internet-Draft para publicação. Depois dele, o RPC publica um conjunto definido de arquivos e anuncia o RFC. No intervalo, editores, autores e contatos do stream verificam se a cópia de produção é fiel ao texto aprovado e se os formatos estão prontos para se tornar o registro duradouro.

O controle não é decorativo. Uma linha perdida de algoritmo, um trecho ABNF deformado, uma instrução incorreta à IANA ou um termo normativo alterado pode sobreviver por anos no documento de referência. Ainda assim, o tamanho do risco não amplia automaticamente a jurisdição de quem o detecta. O editor pergunta e corrige; o autor atesta a fidelidade; o stream decide quando a mudança atravessa o limite editorial.

É esse o valor de governança da superfície pública de revisão. O repositório mostra o ponto de partida, as edições propostas, as perguntas, os respondentes e as aprovações excepcionais. Transparência útil não transforma cada participante visível em autoridade. Ela conserva a separação entre quem propôs, quem verificou e quem decidiu.

A aprovação antecede a fila

A orientação atual sobre o processo de publicação de RFCs começa antes do trabalho editorial. Um dos cinco streams — IETF, IAB, IRTF, Independent ou Editorial — aprova o Internet-Draft segundo seu próprio processo. Só então o documento chega ao RFC Production Center.

Essa aprovação define o conteúdo de referência e identifica a autoridade responsável. Ao entrar na fila, o documento passa ao controle de alterações do RPC para fins de produção. Um autor não substitui silenciosamente o arquivo aprovado. A alteração é registrada e, se for técnica ou de outra forma além do editorial, volta ao stream competente.

O RFC 9920, modelo vigente do RFC Editor, distribui as funções com clareza. Os organismos de aprovação respondem pelo conteúdo de seus streams. A função RFC Editor cuida da produção e da distribuição. O RPC edita, registra alterações e diálogos, identifica possíveis impactos técnicos, pede esclarecimentos, estabelece a prontidão e publica os artefatos.

Não há um lado importante e outro meramente administrativo. A aprovação conceitual não garante arquivos íntegros e legíveis. Da mesma forma, a custódia da cópia não concede ao RPC poder para redesenhar o protocolo. E a autoria não permite recuperar, na etapa final, propriedade exclusiva sobre uma decisão coletiva.

Por isso, um registro defensável começa com dois campos: a fonte aprovada — incluindo revisão e hash — e o stream que a aprovou. Sem esse ponto fixo, todo diff posterior fica sem referência e toda divergência parece uma disputa política.

O que a aprovação dos autores significa

Os autores não fazem uma conferência simbólica. Eles precisam resolver perguntas do RPC, examinar alterações de coautores, ler todo o conteúdo, verificar aviso de copyright e marcação semântica, e inspecionar as saídas HTML, PDF e texto. O processo pode exigir várias rodadas.

As instruções do piloto kramdown-rfc separam duas confirmações. Primeiro, os autores indicam que o markdown está estável o bastante para conversão em RFCXML. Depois, aprovam o conteúdo e todos os formatos finais. A distinção é prática: uma fonte correta ainda pode gerar código, arte, referências ou quebras defeituosas.

A aprovação do autor é, portanto, uma atestação de integridade. Ela liga a responsabilidade de uma pessoa aos artefatos que serão publicados. Não é uma licença para substituir a decisão do grupo de trabalho, do IESG ou de outro órgão do stream.

A regra para autor indisponível confirma essa arquitetura. A orientação prevê mover o nome para Acknowledgements, movê-lo para Contributors ou permitir que um gerente do stream aprove em seu lugar. O procedimento preserva crédito sem criar um veto permanente em uma caixa de entrada inalcançável.

Uma aprovação ausente ainda importa: aquela pessoa pode ser a única capaz de perceber uma distorção. O recibo deve registrar tentativas de contato, a alternativa escolhida, a autoridade que a autorizou e o motivo. A diferença está entre tratar a ausência com um procedimento explícito ou inventar para ela um poder indefinido.

O limite que um merge não atravessa

O RPC iniciou o piloto de kramdown-rfc em 1º de setembro de 2025. Entre os objetivos estavam trabalhar em um formato já conhecido por muitos autores e produzir diffs mais limpos, centrados no conteúdo. A fase inicial previa ao menos cinco solicitações por mês e aprendizado antes da expansão.

Em 2026, as instruções públicas já empregavam Final Review no lugar de AUTH48. O novo nome remove a aparência de um prazo de 48 horas que nunca foi uma garantia. No GitHub, a custódia fica concreta: uma branch contém edições do RPC, issues preservam perguntas, pull requests mostram mudanças e o histórico mantém a conversa.

O repositório do RFC-to-be 10025, revisão da especificação de cookies HTTP, fornece um caso atual. O README informa que o markdown inicial copia o Internet-Draft tal como aprovado para publicação. As edições do RPC ficam em branch separada. Os autores aprovam conteúdo e formatos. Area Directors aprovam mudanças além do editorial; chairs do grupo e o document shepherd também são convidados, e o processo pode voltar ao e-mail.

Em 27 de agosto de 2026, a página de estado do Final Review e o repositório estavam ativos, mas o endereço de informações do RFC 10025 ainda retornava 404. Naquele momento, a interface mostrava quinze issues e um pull request. Esses números não equivalem a quinze defeitos técnicos, quinze objeções nem quinze decisões bloqueadas. Provam apenas a existência de itens de trabalho visíveis.

O estado pode mudar depois deste retrato. É por isso que a observação precisa de data, URL e hash quando possível. Em Final Review é um estado atual. Publicado como RFC 10025 será outro evento, demonstrado pelo registro e pelo anúncio finais.

RFC 9991: uma palavra que exigiu um Area Director

Uma alteração concreta mostra a fronteira melhor do que uma regra abstrata. Durante o Final Review do documento que se tornou o RFC 9991, os autores propuseram adicionar uma palavra-chave BCP 14. Termos normativos em maiúsculas podem alterar uma obrigação técnica; não são mera pontuação.

Na troca pública arquivada, o RPC pediu que o Area Director responsável revisasse e aprovasse a inclusão. O AD registrou a aprovação. Mais tarde, o RPC publicou o RFC.

Os verbos compõem o recibo. Os autores propuseram. O RPC identificou uma mudança que exigia outra autoridade e solicitou revisão. O AD aprovou. O RPC publicou. Um merge não substituiu a aprovação, e a aprovação não foi tratada como prova antecipada de publicação.

Guardar somente o texto final apaga a autoridade que permitiu a mudança. Guardar somente o e-mail do AD não prova quais arquivos continham a redação aprovada. Guardar apenas o número do RFC perde toda a cadeia de custódia. A escalada, nesse caso, não é sinal de que editores tentaram legislar; é evidência de que reconheceram seu limite.

O 48 nunca foi um prazo

O nome antigo sugeria que a verificação final duraria 48 horas. O RFC 8963, baseado em uma amostra de RFCs produzidos em 2018, separou tempo de edição, AUTH48 e intervalo entre acordo final e publicação. Na amostra, AUTH48 durou em média mais de um mês, com grande variação.

O RFC 8700 registra a velha piada de que AUTH48 poderia significar 48 dias ou 48 semanas. Seu ponto institucional é mais útil: mudanças técnicas nessa etapa precisam de aprovação do Area Director relevante ou do gerente do stream.

Os dados históricos não transformam demora em falha automática. Complexidade, fusos horários, autor indisponível, ação da IANA, referência normativa, Stream Hold e problema de ferramenta têm responsáveis diferentes. Duração é um indicador que abre uma pergunta, não um veredicto que já atribui culpa.

Renomear a etapa retirou um relógio enganoso. Não se deve colocar uma urna igualmente enganosa em seu lugar. Final Review é finalização controlada.

O recibo do Final Review

Campo Evidência a preservar Por que importa
Fonte aprovada Nome, revisão, bytes e hash do Internet-Draft Fixa o conteúdo aceito pelo stream
Decisão do stream Stream, órgão, data e URL Identifica a autoridade de publicação
Entrega ao RPC Entrada na fila e estado Separa aprovação de custódia produtiva
Conjunto de edições Branch, diff ou hash Mostra mudanças posteriores à aprovação
Itens de revisão Pergunta, ator, resposta e arquivo Atribui incerteza e resolução
Classe da mudança Editorial, formato, técnica ou além do editorial Determina qual aprovação é necessária
Aprovação dos autores Identidade, escopo e data Liga pessoas aos artefatos finais
Aprovação do stream Recibo do AD ou gerente competente Impede que produção vire autoridade de conteúdo
Bloqueios externos IANA, referências, stream ou ferramentas Expõe o verdadeiro responsável pela espera
Artefatos finais Hashes de HTML, PDF, TXT e XML Fixa exatamente o que será entregue
Publicação Anúncio, URL e horário Prova a passagem de RFC-to-be para RFC
Adoção Implementação, testes e implantação Separa autoridade documental de operação

O recibo não automatiza julgamento. Ele impede que o julgamento perca seu sujeito. Assim, um responsável pode escrever “aguarda aprovação de um autor”, “mudança técnica aguarda o AD”, “ação da IANA incompleta” ou “registro de publicação ainda ausente”. É menos dramático que “veto” ou “segunda votação”, e muito mais útil para uma decisão de implementação ou contratação.

Fontes

As observações sobre o RFC-to-be 10025 correspondem a 27 de agosto de 2026. A contagem de issues não é tratada como contagem de defeitos, e nenhuma data ou resultado de publicação é previsto.