Resumo

  • Publicado como BCP 245, o RFC 9945 cria uma política de moderação para os fóruns públicos on-line da IETF, mas condiciona a vigência das mudanças à aprovação, pela IESG, dos procedimentos da seção 4. Enquanto eles não forem estabelecidos, os processos anteriores continuam valendo.
  • A ficha “obsoletado”, a existência de uma equipe, a presença de um SOP e uma ação registrada são evidências diferentes. Um recibo de ativação deve unir a versão aprovada, o ato e horário de aprovação, a entrada em vigor, a substituição de regras, o escopo, os papéis e a migração de casos, sem publicar denúncias ou deliberações privadas.

Uma ação não pode buscar sua regra no futuro

Procedimentos operacionais mudam. Uma frase é esclarecida, um modelo de aviso é trocado, um prazo é ajustado, uma nova plataforma passa a fazer parte do escopo. Isso é normal e é uma das razões para não gravar cada instrução em um RFC.

O problema aparece quando a mudança apaga a história. Se um chair adotou uma medida em 30 de junho e a apelação foi examinada em julho, o revisor precisa encontrar a regra que vigorava em 30 de junho. A versão que aparece em main no dia da apelação pode ser melhor, mas não pode governar retroativamente só por estar mais fácil de abrir.

O RFC 9945 percebeu essa questão. Ele separa sua publicação da ativação dos novos procedimentos. O documento foi publicado em fevereiro de 2026, recebeu o número BCP 245 e ocupa um lugar inequívoco no corpus da IETF. Ao mesmo tempo, afirma que as mudanças entram em vigor quando a IESG aprovar os procedimentos da seção 4. Até que os procedimentos e critérios sejam estabelecidos, os processos anteriores permanecem em vigor.

Essa arquitetura oferece flexibilidade. O marco normativo é estável; a operação pode ser aperfeiçoada com participação pública e nova aprovação. Mas flexibilidade sem uma fotografia datada produz um paradoxo: todos veem o documento atual, ninguém consegue provar com facilidade qual documento comandava o passado.

O metadado “obsoleta” cumpre outra função

O RFC 9945 diz que torna obsoletos os RFCs 3683 e 3934, substitui trechos do RFC 9245 e atualiza o RFC 2418. As páginas do RFC Editor refletem essas relações. Um pesquisador que começa no RFC 3934 recebe corretamente o aviso de que há um sucessor.

Esse metadado não contém o predicado de transição inteiro. Ele não identifica o hash dos procedimentos da seção 4, a consulta comunitária, a decisão da IESG ou a hora efetiva. É uma seta entre documentos, não uma linha do tempo operacional.

Por isso, não há contradição obrigatória em dizer que um RFC foi formalmente obsoletado na série e que seu processo continuou temporariamente em vigor por determinação do próprio sucessor. O primeiro enunciado organiza textos. O segundo governa atos.

Se as duas camadas forem comprimidas, uma pessoa pode descartar cedo demais o processo antigo. Outra pode declarar que o novo BCP não existe de verdade. O resultado correto é mais sóbrio: o marco foi publicado; a troca operacional depende do evento que o marco definiu.

A resposta de 9 de julho marcou um estado

Uma apelação apresentada por Andrew Lee em 30 de junho tornou a distinção prática. Ela questionava uma ação de moderação durante o Last Call do grupo TLS e alegava, entre outros pontos, que o RFC 3934 não poderia mais conferir autoridade depois de ser listado como obsoleto.

A IESG respondeu em 9 de julho e negou a apelação. Quanto à fonte de autoridade, disse que o RFC 3934 permanecia em vigor porque os novos procedimentos e critérios do RFC 9945 ainda não haviam sido estabelecidos. A resposta também observou que BCP 9 não concede, por si só, poderes de moderação, mas não considerou essa citação adicional capaz de invalidar a medida.

Não é necessário tomar partido no conflito substantivo para aprender com a decisão. O documento público não prova censura, perseguição, parcialidade ou ilegalidade. Tampouco transforma toda decisão de moderação em correta. A IESG tratou de outras alegações e recusou o recurso; este artigo não reabre o processo.

O fato útil é temporal. Em 9 de julho, a IESG reconhecia uma transição ainda não concluída. A regra aplicável não foi inferida da palavra “obsoleto”, mas da condição prevista no documento novo.

Esse achado vale para aquela data. Até 11 de setembro, não encontrei nas fontes oficiais consultadas uma decisão posterior da IESG aprovando uma revisão identificada dos procedimentos novos. A conclusão não é que a decisão inexiste. Pesquisas falham. A conclusão é que uma aprovação feita para ser pública deve ser descobrível por um índice de autoridade, não apenas por quem sabe onde procurar atas, listas e repositórios.

O time de seis e o SOP de três

Datatracker apresenta hoje um IETF Moderator Team ativo, com seis integrantes. A descrição abrange as tarefas do RFC 9945: criar procedimentos para os fóruns públicos, ajudar na resposta a comportamentos perturbadores, administrar os espaços plenários e os fóruns sem administrador, sob nomeação e responsabilidade da IESG.

Já o repositório ietf/Moderators, no commit congelado b907805e15…, fala do time da lista geral de discussão do IETF e ancora sua atuação no RFC 9245. Seu SOP identifica três membros. O texto exige a concordância de dois para uma ação e descreve uma escada de resposta com os níveis 0, 1 e 2. O arquivo de estatísticas conta ações segundo essas categorias.

Essas diferenças não permitem acusar ninguém de descuido. O repositório pode ser uma herança limitada à lista geral, e o novo time pode ter outro espaço de trabalho. Pode haver uma migração. Pode haver atraso editorial. O SOP antigo pode continuar sendo legítimo no intervalo previsto pelo RFC 9945.

O que as diferenças impedem é a inferência automática. A página de equipe prova a identidade pública do principal. O commit prova o conteúdo de uma versão. A tabela prova que categorias foram usadas para contar. Nenhum objeto declara sozinho: “a IESG aprovou esta revisão para este conjunto de fóruns, com efeito a partir deste instante”.

A nova política não centraliza tudo

Os administradores continuam na primeira linha. Chairs de grupos de trabalho são administradores dos fóruns do grupo por padrão. Podem delegar, mas precisam receber, reconhecer e acompanhar queixas. Depois de consultar o time, podem alterar ou desfazer uma ação, inclusive a de um moderador.

Os moderadores desenvolvem procedimentos comuns e funcionam como recurso da comunidade. Normalmente devem procurar o administrador antes de agir. Podem intervir quando ele não responde a tempo ou quando o comportamento atravessa vários fóruns. Também administram os espaços plenários e qualquer fórum público sem outro responsável.

Area Directors resolvem conflitos no primeiro patamar. A IESG nomeia e destitui moderadores, aprova procedimentos, acompanha o time e participa da rota de apelação. O IAB pode ser acionado depois, segundo o mecanismo do RFC 2026. A Ombudsteam mantém sua tarefa específica de assédio. A IETF Administration LLC possui um poder de emergência separado para risco jurídico grave, vinculado a aconselhamento legal.

IRTF, IAB, RSWG, RSAB e o Independent Submission stream não são absorvidos automaticamente. Precisam concordar de modo explícito. Um mapa de escopo é, portanto, tão importante quanto a data. Uma regra legítima em uma lista da IETF não ganha autoridade sobre uma conversa privada, uma reunião, uma conta Datatracker ou outra organização por proximidade institucional.

O regime anterior tinha várias portas

O RFC 3934 oferecia aos chairs um procedimento para mensagens perturbadoras em listas de grupos de trabalho. O RFC 3683 definia uma ação de retirada de direitos de postagem com participação comunitária e da IESG. O RFC 9245 cuidava da lista geral. O RFC 2418 estabelecia responsabilidades mais amplas dos chairs. O RFC 2026 dava estrutura às apelações.

O BCP 245 surgiu porque essa coleção tinha problemas reais. Critérios variavam, alguns caminhos eram lentos, padrões em várias listas escapavam ao administrador local e novas arenas — chat, wiki, GitHub, GitLab, issue tracker — não cabiam confortavelmente em regras feitas para e-mail.

Manter os processos antigos por uma fase não expande seu escopo. O RFC 9945 exclui remoção de conta, restrição de participação em reuniões, apagamento ou redação de conteúdo e comunicação privada ou externa à IETF. A cláusula de transição preserva autoridade existente dentro de limites; não entrega uma licença geral.

Ela também preserva a temporalidade dos casos. Uma suspensão por tempo indeterminado decidida antes do novo processo só pode ser reconsiderada pelo procedimento existente na data original. A organização já reconhece, portanto, que a versão histórica não pode ser apagada por uma atualização.

Como seria o recibo de ativação

O primeiro campo é a versão. O recibo aponta para bytes imutáveis, publica seu hash e descreve quais classes de fórum estão cobertas. Uma URL de branch é conveniência; o hash é a identidade histórica.

O segundo é a autorização. Registra a janela de contribuição comunitária, um índice de tratamento dos comentários, a decisão atribuível da IESG, a hora da aprovação e a hora da vigência. Se houver ativação gradual, o cronograma entra no registro.

O terceiro é a substituição. Uma tabela diz quais seções e declarações deixam de governar, quais continuam para fatos anteriores, como medidas ativas migram e quais organismos estão fora. O roster e os períodos de nomeação ficam em bloco distinto. Nomear pessoas e aprovar regras são atos diferentes.

O quarto cuida do limite vivo. Quantas denúncias estavam pendentes? Quais restrições e apelações continuavam abertas? Que relógio regula pedidos de reintegração? A versão pública pode usar contagens e identificadores protegidos. O arquivo detalhado preserva nomes e material sensível apenas para quem precisa revisar.

O quinto registra implementação e correções. Administradores e operadores reconhecem a versão instalada. Um reconhecimento não produz autoridade, mas mostra a chegada da decisão. Uma correção posterior ganha um elo de supersessão; não reescreve o passado.

Privacidade é parte da arquitetura

Tornar público o recibo não significa reproduzir a queixa. Relatos podem expor uma pessoa, repetir conteúdo nocivo, revelar contexto privado ou amplificar a interrupção. A intervenção jurídica emergencial pode ainda limitar a comunicação.

A camada pública precisa apenas da regra, da decisão, do tempo, do escopo e do histórico de correção. A camada protegida mantém fatos e deliberação. O aviso à pessoa afetada, o registro para revisão e o relatório agregado cumprem funções diferentes.

Também não se deve extrair veredictos de artefatos estreitos. Procedimento aprovado não prova aplicação justa. Notificação não prova a alegação. Estatística não prova consistência. Roster não prova vigência. A governança melhora quando cada prova responde só à pergunta para a qual foi criada.

Os textos de Heng Lu servem aqui como lente, não como evidência sobre a IETF. Um rótulo de documento, uma decisão executável e a observação de um resultado pertencem a camadas diferentes. A especificação inicial mínima deve tornar a união visível, deixando revisões futuras para a autoridade competente.

O RFC 9945 escolheu um bom problema: combinar resposta rápida, alcance entre fóruns, limites, revisão e apelação. Seu sucesso depende de um detalhe que parece administrativo, mas não é. A equipe mostra quem. O procedimento mostra como. A aprovação mostra por que essa versão tinha autoridade. A data mostra quando. Só juntos formam a ativação.

Fontes

  1. https://heng.lu/the-policy-mirror/
  2. https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
  3. https://heng.lu/on-why-btw-media-exists-and-why-reality-not-advocacy-is-the-product/
  4. https://www.rfc-editor.org/info/rfc9945/
  5. https://www.rfc-editor.org/rfc/rfc9945.html
  6. https://www.rfc-editor.org/rfc/rfc3934.html
  7. https://www.rfc-editor.org/rfc/rfc3683.html
  8. https://www.rfc-editor.org/rfc/rfc9245.html
  9. https://www.rfc-editor.org/rfc/rfc2418.html
  10. https://www.rfc-editor.org/rfc/rfc2026.html
  11. https://datatracker.ietf.org/group/iesg/appeals/artifact/314
  12. https://datatracker.ietf.org/group/iesg/appeals/artifact/315
  13. https://datatracker.ietf.org/group/ietfmoderators/about/
  14. https://github.com/ietf/Moderators/blob/b907805e15f5b902d5d728a9c2c6601962ca625d/README.md
  15. https://github.com/ietf/Moderators/blob/b907805e15f5b902d5d728a9c2c6601962ca625d/sop.md
  16. https://github.com/ietf/Moderators/blob/b907805e15f5b902d5d728a9c2c6601962ca625d/stats.md