Resumo

  • draft-sayre-gendispatch-derivative-06 é um Internet-Draft individual ativo. Ele propõe restringir o mecanismo de não derivação aos RFCs e Internet-Drafts usados no processo de padrões; não é RFC nem política adotada.
  • RFC 5378 diferencia a Contribuição IETF, categoria ampla que inclui comunicações em atividades IETF, do Documento IETF, categoria mais estreita. A declaração ativa do IESG e o encaminhamento de IETF 126 têm efeitos próprios e limitados.
  • Daniel Kade recomenda um recibo de status da contribuição para conservar a prova e expor classificação, regra, responsável, ato e revisão. A recomendação não é conselho jurídico nem obrigação da IETF.

O que chegou não é o mesmo que o que pode ser adotado

Uma conversa de padrões mistura mensagens, atas, apelações, textos de trabalho e documentos formais. A mistura é produtiva: permite que uma observação de implantação chegue cedo e que uma objeção seja preservada. Ela também cria a tentação de chamar tudo de documento ou de deixar uma frase automática decidir o tratamento de tudo.

RFC 5378 evita essa confusão. A definição de Contribuição abrange material enviado para publicação como Internet-Draft ou RFC e declarações no contexto de uma atividade IETF, inclusive comunicações eletrônicas para listas, grupos, BOFs, plenária, IESG e IAB. Documento IETF é outro objeto: RFCs e Internet-Drafts utilizados no processo de padrões. Um e-mail pode ser uma contribuição relevante sem ser o texto documental ao qual cabe o mecanismo específico de restrição de derivadas.

Essa distinção protege o participante e o processo. A pessoa não perde a autoria do que enviou; a lista não recebe poder para decidir todos os seus direitos; e uma observação forte não se torna mandato de adoção. RFC 5378 explica por que a IETF precisa de direitos para evoluir documentos e reconhece exceções limitadas, entre elas tecnologia proprietária, republicação de outra organização de padrões e material ainda não aceito para desenvolvimento. O ponto é classificar antes de inferir, não estender uma exceção por analogia a cada rodapé.

O projeto atual não é a regra atual

A versão -06, de 13 de agosto de 2026, aparece no Datatracker como Internet-Draft individual ativo, sem stream RFC, com boilerplate de consenso desconhecido e estado I-D Exists. Ela propõe que a vedação a derivadas só se aplique a Contribuições que sejam RFCs ou Internet-Drafts usados no processo de padrões. Os demais direitos de RFC 5378 continuam preservados no texto proposto.

Essa formulação não alterou RFC 5378. Não decide o caso de um e-mail concreto, não prova que houve edição, censura, perda ou má conduta, e não concede a um leitor autoridade jurídica. No IETF 126, o resultado de GENDISPATCH foi discussão adicional em IPR-WG seguida de revisão por assessoria jurídica. Encaminhamento é uma etapa, não consenso. Revisão anunciada não é parecer concluído.

A declaração do IESG, publicada em outubro de 2025, fornece a posição institucional hoje disponível. Ela diz que direitos de derivação de uma Contribuição só podem ser retidos quando a Contribuição é um Documento IETF e em circunstâncias estreitas. Diz também que avisos em conflito com a política devem ser ignorados numa Contribuição e que um dono do processo pode requerer sua remoção. Isso define o efeito de política do aviso; não autoriza alterar a mensagem de origem e não pré-seleciona o responsável por todas as decisões futuras.

Um recibo torna visível o ponto de decisão

Dois atalhos são perigosos. O primeiro deixa um rodapé corporativo funcionar como veto automático. O segundo usa a palavra “ignorar” para apagar a prova e a razão do tratamento. Um recibo de status evita ambos.

Ele começa pelo objeto recebido: identificador estável, canal, data, impressão digital do conteúdo e referência ao aviso como chegou. Depois mostra o objeto classificado: mensagem, Internet-Draft, RFC, recurso, ata ou comentário. Em seguida, nomeia a regra e a versão efetivamente usadas. Por fim, registra o ato de um papel autorizado: aviso considerado inaplicável, retirada pedida, assunto encaminhado, nova submissão solicitada ou nenhuma ação de processo.

Daniel Kade chama essa ligação de recibo de status da contribuição. Sua parte pública pode ser mínima: identificador, integridade, canal, aviso preservado, classificação, regra vigente, papel responsável, estado da ação, rota de revisão e decisão posterior que tenha substituído a anterior. Comunicações sensíveis podem ficar em anexo protegido. A confidencialidade não precisa esconder que houve um ato, qual foi seu limite e se ele permanece pendente.

Os termos impedem exagero: “aviso recebido” não é “aviso válido”; “contribuição” não é “documento adotado”; “regra aplicada” não é “parecer jurídico”; “remoção solicitada” não é “original reescrito”; “enviado para revisão” não é “revisão concluída”. É justamente essa precisão que deixa papéis diferentes cooperarem sem ocupar a autoridade alheia.

Participação aberta não precisa de um dossiê para cada frase

O recibo só faz sentido quando o status se torna material: uma limitação afeta o tratamento de um documento, há pedido de responsável, apelação ou ato contestado. Ele não deve criar cadastro, custo de entrada ou tribunal de licenças para uma lista. Um participante continua livre para enviar uma objeção; um chair pode conduzir uma etapa sem virar juiz de copyright; uma revisão jurídica pode analisar regra sem escolher a solução técnica.

Aqui vale a advertência de Heng Lu: presença e conhecimento são evidência, não mandato. Um remetente não governa por anexar um rodapé. Uma ferramenta de arquivo não governa por manter os bytes. A regra de direitos pode disciplinar uma questão delimitada; ela não muda a distribuição de autoridade em toda a comunidade.

Limites da evidência

As fontes não demonstram adoção do -06, atualização de RFC, consenso IETF ou parecer jurídico final. Não demonstram erro de qualquer autor, empregador ou arquivo. O recibo é recomendação editorial de Daniel Kade; não é protocolo, exigência de publicação ou instrução para modificar correspondência.

Fontes

  1. RFC 5378 — Rights Contributors Provide to the IETF Trust
  2. IESG Statement on Clarifying Derivative Works Rights
  3. draft-sayre-gendispatch-derivative-06 — Clarification of Derivative Works Restrictions
  4. Minutes: IETF 126 GENDISPATCH
  5. RFC 7282 — On Consensus and Humming in the IETF
  6. Heng Lu — The Multi-Stakeholder Mirage