Resumo

  • O RFC 5111 separou entregas úteis das provas obrigatórias para formar um Working Group.
  • Um Exploratory Group podia usar processos e ferramentas de WG, mas sua carta não podia prever documentos Standards Track nem especificações de protocolo.
  • A conclusão dos marcos levava a feedback e a uma votação separada do IESG, não a uma conversão automática.

Um problema bem descrito não é o mesmo que um mandato para resolvê-lo por meio de um protocolo do IETF. Essa diferença sustentava toda a experiência.

O RFC 2418 pede que a formação de um WG considere clareza, viabilidade, urgência, sobreposição, participantes, experiência, usuários, papel apropriado do IETF, direitos de propriedade intelectual, abertura e coordenação com outros organismos. Pode haver interesse suficiente para trabalhar sem que esse conjunto esteja fechado.

Formalizar o que ainda falta

O IESG podia propor um EG quando relevância e interesse já estavam demonstrados, mas restava pelo menos um critério. O EG podia vir antes de um BOF ou entre um BOF e o WG. Depois de um segundo BOF, criar mais uma etapa exploratória não era recomendado.

A função era transformar espera difusa em uma lista pública de condições, evidências e próximos passos. O EG não era uma versão menor do WG. Era um instrumento para descobrir se o WG deveria existir.

Entregas básicas e opcionais

Dois marcos eram obrigatórios: elaborar a futura carta do WG e demonstrar o atendimento aos critérios de formação. O IESG podia acrescentar problema, requisitos, literatura ou práticas atuais, desde que isso não atrasasse o básico.

O texto proibia que a carta incluísse o desenvolvimento de documentos Standards Track ou especificações de protocolo. A proibição mantinha a avaliação livre de fatos consumados. Se código e adoção começam antes da autorização, a decisão deixa de medir mérito e passa a administrar custos já criados.

Mandato curto, saída explícita

A carta inicial deveria durar de seis a doze meses, com seis como padrão. Uma extensão de seis meses era possível; ir além não era recomendado.

O relógio media a redução de incerteza. Ao final, a organização precisava mostrar quais dúvidas foram encerradas. Uma sucessão de documentos que não fecha sobreposição, escopo ou capacidade não é progresso de admissão.

Sem prazo, a etapa transitória acumula identidade: o nome ganha reputação, a lista cria base política e rascunhos passam a ser tratados como posições. O prazo preservava a opção de encerrar ou reenquadrar.

A aparência de um WG era intencional

Revisão do IAB e IESG, anúncio à comunidade, regras abertas, reuniões, rastreamento, PROTO shepherding, presidente e WGCHAIRS eram compartilhados. O nome deveria conter EG para que o limite permanecesse visível.

A infraestrutura registrava trabalho e feedback. Não registrava a transferência da autoridade normativa. Um presidente coordenava; não concedia aprovação. Um rascunho acompanhado podia continuar controverso. Um calendário público não substituía o voto.

Um experimento contido

O RFC 3933 forneceu o modelo para dezoito meses e no máximo três EGs. O IESG precisava publicar cada decisão de formação. O RFC 5111 não alterou as regras de formação do RFC 2418 nem o processo do RFC 2026.

O que se testava era a eficácia de um estágio formal e curto. Não se criava uma rota paralela de padronização.

A métrica decisiva

Sem avanço nos marcos básicos, o EG não era bem-sucedido, mesmo com um excelente levantamento. Prazo e retorno positivo do IESG, IAB e comunidade deveriam levar o IESG a votar sobre o WG.

Atividade na lista indicava possível engajamento. Pouco tráfego podia desaconselhar extensão. Muito tráfego, porém, não comprovava usuários, experiência ou escopo adequado.

Interesse, EG, marcos, revisão, voto, WG, especificação, avanço no processo e resultado operacional eram recibos diferentes.

Fontes