Resumo

  • Na IETF 126, o grupo PROCON concordou em propor uma frase de carta segundo a qual seus documentos devem registrar com precisão a política vigente. No encerramento da pesquisa, o Datatracker ainda apresentava apenas a carta aprovada em 2025; a nova frase não era autoridade em vigor.
  • A carta atual já permite mudanças não editoriais limitadas sobre marcos de Working Groups e adoção de Internet-Drafts. Também autoriza um BCP sobre delegação e sucessão temporária da presidência da IETF. Itens adicionais exigem nova carta.
  • O 2418bis remove a conhecida referência a 51% e 99%, introduz funções de apoio, trata múltiplos fóruns públicos e esclarece que adoção não é consenso sobre o conteúdo e pode ser revertida. Essas mudanças não partem necessariamente da mesma fonte normativa.
  • Uma prática corrente não se torna política só por existir. Da mesma forma, texto novo não é necessariamente extrapolação: a carta já autoriza certas revisões substantivas.
  • Um registro público por diferença relevante deve ligar versão, base anterior, evidência de prática, tipo de mudança, cláusula de autoridade, objeções, decisão do grupo e os estados posteriores na IETF e no IESG.
  • O registro não criaria veto nem nova fase. Ele também manteria separadas a publicação do BCP e a adoção posterior em ferramentas, treinamento e comportamento dos grupos.

Uma frase sobre o presente que ainda não entrou em vigor

O trabalho de PROCON nasce de um problema de manutenção real. RFC 2026 e RFC 2418 continuam fundamentais para o processo de padronização e a organização dos Working Groups, mas RFCs posteriores, erratas e novas ferramentas afastaram o texto original da experiência cotidiana.

A carta PROCON aprovada ordena a incorporação dos RFCs que atualizam as duas bases, além de erratas verificadas ou marcadas para atualização. Ela não limita o grupo a emendas editoriais. Permite explicitamente mudanças não editoriais sobre marcos e adoção de rascunhos. Autoriza ainda um BCP separado sobre delegação pelo presidente da IETF e sucessão temporária. Trabalho extra depende de rechartering.

Há, portanto, ao menos quatro operações legítimas a distinguir. Consolidação reúne autoridade já aprovada. Correção de mecanismo obsoleto atualiza a forma de cumprir uma responsabilidade sem mudar a responsabilidade. Codificação transforma prática observada em norma escrita. Revisão deliberada usa uma competência dada pela carta ou por uma futura carta aprovada. Uma linha diferente do RFC antigo não revela sozinha qual operação ocorreu.

Os slides das presidências na IETF 126 mostraram o impasse. O programa era entendido como documentação precisa e clara do processo vigente, deixando extensões e mudanças de política para depois. Uma leitura estrita, entretanto, poderia excluir até correções editoriais e alinhamento com uma realidade operacional transformada. A proposta inicial era mais longa e citava RFCs, declarações do IESG e mudanças em ferramentas.

As minutas da reunião registram a solução curta: propor que os documentos finais registrem com precisão a política vigente. O próprio arquivo informa que foi rascunhado por IA e depois revisado e atualizado pelas presidências e participantes. É um registro revisado da decisão, não uma transcrição literal.

Em 2 de setembro de 2026, o Datatracker ainda mostrava charter-ietf-procon-01, atualizada em 9 de julho de 2025, como versão aprovada. A frase da IETF 126 é uma proposta do grupo ao IESG. Não deve ser narrada como carta já operacional nem usada para legitimar retroativamente qualquer diferença anterior.

O que muda quando 51% e 99% desaparecem

draft-ietf-procon-2418bis-04 exclui o parágrafo do RFC 2418 que dizia que 51% de apoio não necessariamente é consenso aproximado e que até 99% pode esconder uma objeção substancial. A apresentação do 2418bis chama os percentuais de regras práticas confusas. A reunião manteve a exclusão e não adicionou a referência sugerida ao RFC 7282.

Retirar os números pode proteger a ideia de rough consensus contra uma leitura eleitoral. Essa justificativa, contudo, precisa sobreviver junto com a mudança: trecho de origem, problema identificado, princípio preservado e decisão do grupo. Sem isso, a futura leitura terá de presumir que a remoção era fiel apenas porque chegou ao texto final.

As funções de apoio apresentam outro caso. A revisão 04 permite que presidências e Area Directors nomeiem ou removam participantes dessas funções, sem que elas mudem a tomada de decisão por consenso ou reduzam as responsabilidades básicas de presidências e Area Directors. A reunião decidiu revisar a redação e manter a barreira de accountability.

Uma mensagem pública no grupo afirma, a partir da experiência do autor, que muitos Working Groups não designam formalmente um Document Editor e pergunta se o texto deveria refletir esse costume. A mensagem é evidência atribuída de uma alegação sobre prática. Não é censo nem política normativa. Cabe ao grupo decidir se a prática é suficientemente estabelecida e quais limites recebe ao entrar no BCP.

A responsabilidade atravessa o e-mail, o chat e o registro

O RFC 2418 foi escrito tendo listas de e-mail como principal espaço. A revisão 04 fala em fóruns públicos que incluem e-mail, grupos de chat e outras ferramentas colaborativas, exigindo que seus resultados sejam resumidos e bem documentados.

Pode ser apenas uma correção de mecanismo: as mesmas exigências de publicidade e memória aplicadas a meios novos. Mas as palavras também podem ampliar decisões sobre quais salas contam, que moderação é admissível e quando uma conversa efêmera integra o registro do consenso. A classificação informa se o revisor deve verificar continuidade da obrigação ou uma nova competência.

Já a adoção de rascunhos tem uma base de autoridade direta. O 2418bis afirma que adoção torna um texto a base de um item de trabalho, sem representar consenso sobre seu conteúdo, e pode ser revertida. Como a carta atual menciona adoção entre os campos de mudança não editorial, esse modelo de custódia pode ser revisão deliberada autorizada. Não precisa ser disfarçado de simples ajuste.

O recuo de 2026bis não apagou a fronteira

Os slides de atualização do 2026bis separam ajustes tidos como editoriais, questões adiadas e trabalho antes de novo Working Group Last Call. Na IETF 126, o grupo decidiu reverter mudanças da revisão 09 sobre discussão não pública de recursos e trocar Unicode por IEEE 802 Ethernet como exemplo de padrão externo.

A troca pública sobre escopo registra argumentos atribuídos. Um participante considerou a discricionariedade uma mudança de política fora da carta; a resposta invocou RFC 2026 e a prática atual como base de esclarecimento. A conversa prova que os argumentos foram apresentados, não que a IETF adotou um deles como conclusão institucional. Reverter o texto resolve a próxima revisão sem eliminar o problema de classificação.

Também foi adiada a substituição de “expired” por “inactive”. Na discussão pública, reconheceu-se que a segunda palavra pode refletir melhor o Datatracker, mas talvez não seja meramente editorial. Se apenas atualiza um rótulo, é correção técnica; se altera quando um estado produz efeitos, é política. O tamanho do diff não mede sua importância.

O registro mínimo de classificação

O mecanismo proposto é um índice, não um segundo processo de padrões. Diferenças que alterem papéis, accountability, consenso, fóruns, adoção ou recursos receberiam doze campos:

  1. revisão imutável e seção ou diff;
  2. RFC, errata ou declaração de base;
  3. prática ou estado de ferramenta alegado, com fonte pública;
  4. classificação como consolidação, correção de mecanismo obsoleto, codificação de prática ou revisão deliberada;
  5. cláusula da carta, proposta de nova carta ou justificativa de que não há nova autoridade;
  6. razão editorial;
  7. objeções materiais e autoria;
  8. decisão do grupo e data;
  9. mudanças após Working Group Last Call;
  10. tratamento em IETF Last Call e IESG;
  11. texto publicado;
  12. adoção operacional e em ferramentas.

Uma diferença pode ter mais de uma classificação. A atualização dos fóruns pode corrigir tecnologia e codificar uma prática. O registro não exige falsa pureza; exige que a alegação de prática tenha evidência, a correção identifique o dever preservado e a revisão mostre sua autoridade.

Objeções continuam sendo posições atribuídas, não vetos. A decisão do grupo fica em campo próprio. Se o texto for removido, o registro mostra o encerramento sem perpetuar a proposta.

A Nota 64 de Heng Lu oferece uma lente de desenho: fixar um mínimo estável, localizar decisões futuras no ator autorizado e separar a adoção operacional. Ela não é fonte factual sobre PROCON e não substitui o processo da IETF. Aqui, apenas ajuda a impedir que base, decisão posterior e uso efetivo sejam tratados como um único momento.

Revisão decide o resultado; registro preserva o motivo

O melhor argumento contrário é que a IETF já tem controles. Consenso do grupo, Working Group Last Call, IETF Last Call, revisão do Area Director e IESG podem corrigir problemas. Na IETF 126, o Area Director considerou o 2026bis dentro do escopo com a atualização proposta, mas ressalvou que ainda não havia examinado profundamente os diffs do 2418bis.

O inventário de documentos PROCON listava 2026bis-11 em Working Group Last Call e 2418bis-04 como documento do grupo. Nenhum estado equivale a aprovação do IESG ou publicação como BCP. A análise precisa deixar espaço para revisão posterior.

Essas etapas, porém, não organizam automaticamente a explicação de cada mudança. A razão pode estar num e-mail, a objeção nos slides, a decisão na minuta e o efeito no changelog. A aprovação final não revela por si só se uma prática foi verificada, apenas afirmada ou substituída por outra base.

O registro torna o processo existente legível. Se uma revisão mudar a classificação, registra-se a mudança. Se um diff desaparecer, preserva-se o desfecho. Se a evidência de prática falhar, o grupo pode retirar o texto ou usar uma autoridade diferente. A decisão permanece livre e deixa de perder memória.

Fontes

  1. Carta PROCON aprovada
  2. Inventário de documentos PROCON
  3. Minutas PROCON da IETF 126
  4. Slides das presidências de PROCON
  5. Atualização do 2026bis
  6. Apresentação do 2418bis
  7. Nota 64 de Heng Lu
  8. Discussão pública sobre escopo
  9. Discussão pública sobre a prática do Document Editor
  10. Discussão pública sobre inactive e expired
  11. draft-ietf-procon-2026bis-11
  12. draft-ietf-procon-2418bis-04
  13. RFC 2026
  14. RFC 2418