Resumo

  • A consulta informa que o SLA antigo foi cumprido em apenas 42,5% dos trimestres medidos desde 2016 e que estados históricos não separavam bem espera de autor, fila de atribuição e partes da revisão final.
  • A proposta cria faixas por tamanho, percentis, uma janela móvel anual e dois apertos graduais para medir somente o tempo que o RPC controla. É um limite legítimo de responsabilidade, não a duração completa do serviço.
  • O próprio documento estima cerca de 245 dias corridos para um RFC típico de 30 a 50 páginas, cerca de 115 dias associados ao backlog e aproximadamente 97 dias fora do controle do RPC. São visões agregadas que não devem ser somadas como blocos independentes.
  • Daniel Kade propõe um registro atribuível dos repasses: cada estado preservaria entrada, saída, dono, próxima ação, base do relógio, motivo, escalada e correção, permitindo publicar lado a lado o tempo do RPC e o tempo total.

O documento só chega uma vez

Para o contrato, uma pausa pode estar fora do relógio. Para o autor, ela continua dentro do calendário. Essa diferença não torna o contrato enganoso; ela revela que duas perguntas legítimas foram colocadas sobre o mesmo processo. A primeira é administrativa: o centro de produção fez o trabalho que estava em suas mãos dentro do limite acordado? A segunda é operacional: quanto tempo o sistema inteiro levou para transformar um texto aprovado em registro permanente da série RFC?

Confundir as perguntas cria dois erros simétricos. Se todo o tempo corrido for debitado ao RPC, o centro passa a responder por uma decisão que apenas um autor, uma instância de aprovação ou a IANA pode tomar. Se apenas o relógio do RPC for publicado como resultado do serviço, dias reais desaparecem da experiência mesmo quando há um responsável conhecido e uma ação pendente identificável.

A consulta reconhece por que a métrica anterior perdeu força. Desde 2016, segundo sua análise, ela foi atendida em 42,5% dos trimestres medidos. Uma meta que falha na maior parte das medições deixa de separar uma exceção de uma condição estrutural. Além disso, os próprios estados podiam atribuir o tempo ao lugar errado: antes do segundo trimestre de 2025, a espera por autor raramente era registrada como tal; não havia um estado distinto para o documento que aguardava designação de editor; e partes de AUTH48 que ainda exigiam trabalho do RPC ficavam fora da medição.

O problema não é apenas estatístico. Um estado nomeado determina quem recebe o alerta, qual fila aparece no relatório e qual intervenção parece capaz de melhorar o resultado. Se a espera por designação não existe como categoria, o trabalho permanece no sistema sem possuir uma forma própria de prestação de contas. Se uma pergunta ao autor permanece no relógio editorial, um indicador acusa o executor que não pode respondê-la. O vocabulário da fila é, portanto, uma distribuição de responsabilidade.

A proposta corrige o denominador

O novo desenho abandona uma única expectativa para documentos muito diferentes. A consulta calcula que cada página acrescente, em média, cerca de 0,34 dia de trabalho controlado pelo RPC. Uma fila com textos curtos pode parecer mais eficiente do que outra com documentos longos mesmo que as duas equipes operem da mesma forma. As três faixas de tamanho tentam impedir esse efeito.

No ponto de partida proposto, 75% dos documentos teriam de permanecer dentro de 130 dias de RPC quando possuíssem até 15 páginas, 170 dias para 16 a 40 páginas e 190 dias acima de 40 páginas. A parcela exigida subiria um ponto percentual por trimestre até 85%. Depois do primeiro ano, os limites de duração cairiam 5% ao ano. Um movimento exige que mais documentos entrem no resultado; o outro comprime o tempo aceito.

O cálculo usaria uma janela móvel de um ano, reduzindo a volatilidade de um trimestre isolado. Ao lado dos percentis haveria medidas de vazão e do backlog ativo máximo, tanto em documentos quanto em páginas. Essa combinação é mais informativa do que uma média simples: revela a produção, a carga que ainda permanece e o comportamento da cauda sem exigir que todo caso excepcional seja tratado como falha contratual.

Há, porém, hipóteses fortes. O modelo conserva o total de recursos editoriais e o escopo de trabalho do RPC. Nessas condições, prevê queda aproximada de 20% no backlog em três anos e desaparecimento em sete a doze anos. Não é promessa de data. Uma mudança na chegada de documentos, na complexidade, na equipe, na revisão ou nas ferramentas altera a trajetória. É justamente por isso que a consulta pergunta se vale investir por prazo curto, mudar prioridades, retirar tarefas ou aceitar outro ritmo.

O backlog entra antes do primeiro toque

A estimativa mais visível do documento é a duração de aproximadamente 245 dias corridos para um RFC típico de 30 a 50 páginas. A consulta associa cerca de 115 dias desse ambiente ao backlog e calcula aproximadamente 130 dias sem ele. Também informa uma média ao redor de 97 dias fora do controle do RPC, independentemente do tamanho.

Esses números não formam três peças que possam ser empilhadas. São estimativas agregadas e parcialmente sobrepostas, construídas para perguntas diferentes. Somá-las produziria uma precisão que a fonte não oferece. Elas tampouco explicam a história de um RFC identificado. Um documento pode passar muito tempo em uma dependência normativa; outro pode exigir edição técnica complexa; um terceiro pode receber aprovação rápida em AUTH48 e ter esperado antes da atribuição.

Mesmo assim, o conjunto mostra por que um único resultado verde não resolve o problema público. O backlog pode envelhecer antes que o relógio de edição ativa comece. Uma espera externa pode crescer depois que uma pergunta é enviada. O RPC pode melhorar exatamente o segmento que controla e o total continuar quase imóvel. Isso é progresso local, não necessariamente uma jornada mais curta.

A conclusão inversa também importa. Se o tempo total não cai, não se pode concluir automaticamente que mais recursos no RPC resolveriam a restrição. O registro pode mostrar que o centro já reduziu sua parte enquanto a próxima limitação se encontra em referências, aprovação, resposta ou ação de registro. Atribuição impede tanto a culpa automática quanto a absolvição automática.

AUTH48 é uma fronteira, não um sumidouro

AUTH48 ocorre perto da publicação, quando autores e revisores designados confirmam o texto editado. A revisão é uma salvaguarda da série, não desperdício por definição. Um autor pode precisar verificar uma alteração que afeta precisão técnica; a IANA pode ter uma ação vinculada; uma referência pode depender de outro documento. O cuidado não deve ser castigado apenas porque consome calendário.

Mas cuidado e invisibilidade são coisas diferentes. Quando a próxima ação está com o autor, o SLA do RPC deve pausar. A história do documento, por sua vez, deve dizer quando a solicitação saiu, quem precisa agir, que dependência existe e quando o estado terminou. Essa informação permite distinguir revisão deliberada, espera repetitiva e erro de encaminhamento sem transformar o autor em réu de um ranking público.

O mesmo vale para a atribuição editorial. Um documento que aguarda editor não está recebendo edição ativa, mas continua sob a responsabilidade institucional do serviço. O estado precisa aparecer. Uma sala de espera sem nome melhora artificialmente qualquer painel que comece a contar apenas quando alguém abre a porta.

O registro proposto por Daniel Kade seria complementar ao SLA, não uma segunda penalidade. Para cada transição, conservaria a identidade do documento, momento de entrada e saída, ator responsável pelo estado, detentor da próxima ação, motivo normalizado, relógio em uso, dependência, gatilho de escalada e eventual correção. Ao final, produziria pelo menos três totais: tempo controlado pelo RPC, tempo atribuído aos demais participantes e tempo corrido de ponta a ponta.

Corrigir o estado sem reescrever a série

Uma fila real contém classificações imperfeitas. Uma resposta chega sem ser percebida; uma dependência muda; uma pausa é atribuída ao ator errado. O sistema precisa aceitar correção. Precisa também preservar o valor anterior, o motivo da mudança, a data e a autoridade que a efetuou.

Sem essa trilha, uma série histórica pode melhorar porque o passado foi recategorizado. Não é necessário supor manipulação: equipes corrigem dados para torná-los mais verdadeiros. O risco aparece quando a correção apaga a base usada por relatórios anteriores. Um registro imutável de transições permite recalcular a visão atual e, ao mesmo tempo, explicar por que ela difere da publicada antes.

Essa disciplina preserva uma coordenação estreita sem criar um comando central. O registro não decide conteúdo técnico nem concede ao administrador poder sobre os fluxos da IETF. Ele documenta a custódia temporária de uma função compartilhada. O dono de um trecho responde pelo trecho; nenhum ator se torna soberano sobre o percurso completo.

Cada público precisa de uma leitura diferente

O RPC precisa administrar capacidade, ferramentas, edição e fila. A IETF LLC precisa contratar e supervisionar. Os autores querem localizar a próxima ação. Os gerentes de fluxo querem comparar padrões sem interferir no conteúdo aprovado. A comunidade decide se escopo, qualidade e recursos entregam um resultado aceitável. Implementadores e leitores querem saber quando o registro estável existirá.

Nenhum número responde igualmente a todos. O percentil controlado pelo RPC serve à relação de desempenho. A idade do backlog serve ao planejamento. O tempo por dono serve à melhoria do processo. A duração total serve ao resultado institucional. Publicá-los em conjunto evita exigir de uma métrica o que ela não foi construída para dizer.

Autoridade sem fabricar mandato

Essa separação também protege a autoridade. RFC 9280 coloca política da série, aprovação e implementação em papéis diferentes. O RPC edita e publica; RSWG e RSAB tratam da política da série; a IETF LLC supervisiona o contrato e o desempenho. RFC 8711 dá à LLC responsabilidade administrativa, operacional e financeira, mas não autoridade para decidir o mérito dos padrões. Um cronômetro administrativo não pode fabricar uma competência técnica.

O registro de repasses não altera essa distribuição. Ele apenas comprova quando o documento entrou ou saiu do trecho de cada instituição, quem deve agir em seguida e como uma correção posterior foi registrada. A evidência pode atravessar a fronteira institucional sem que o administrador, o RPC ou a métrica recebam o poder que continua do outro lado.

As manifestações públicas já observadas testam partes diferentes do desenho. Mirja Kühlewind questiona o horizonte de sete a doze anos e a utilidade de metas fixas isoladas. Acee Lindem concentra a atenção no tempo até AUTH48 e demonstra ceticismo sobre processo adicional. São contribuições individuais, não consenso da IETF. Seu valor está em obrigar a proposta a declarar as hipóteses antes que a métrica se torne a linguagem permanente da supervisão.

Velocidade sem qualidade é outra troca de escopo

A série RFC preserva um registro técnico duradouro. Editar XML, verificar YANG ou código, tratar scripts não latinos e RTL, melhorar acessibilidade, coordenar IANA e manter ferramentas são custos reais da qualidade. A consulta atribui parte do aumento de trabalho a responsabilidades desse tipo e registra desaceleração gradual de cerca de seis dias por documento a cada ano, sem reduzi-la a uma causa.

Uma meta temporal pode criar incentivo para retirar tarefas difíceis, adiar melhoria de ferramentas ou deslocar trabalho aos voluntários. Isso talvez seja uma escolha legítima, mas deve aparecer como mudança de escopo. Concluir rápido após uma edição mais estreita não equivale automaticamente ao mesmo serviço realizado com mais eficiência.

Por isso, qualidade deve ficar ao lado do tempo, e não escondida no numerador. Retrabalho substantivo, correções materiais após publicação, clareza percebida pelos autores, consistência editorial e disputas sobre mudanças precisam de séries próprias. Satisfação deve ser segmentada por papel e fluxo; uma experiência fácil para autores frequentes pode ocultar obstáculos enfrentados por quem publica pela primeira vez.

O que observar antes de 6 de setembro

Antes do encerramento da consulta, importa ver se as respostas distinguem uma meta justa para o RPC de uma visão completa da jornada. Também é preciso acompanhar se haverá apoio para comprar a redução mais rápida do backlog, tratar fluxos de RFC de modo diferente, medir satisfação sem premiar apenas velocidade e preservar tarefas de qualidade quando se discutir fazer menos. Uma resposta pública que nomeie custos, responsáveis e efeitos de cada escolha será sinal mais forte do que uma preferência isolada por um prazo menor.

O ponto decisivo é se a IETF LLC apresentará o SLA limitado junto de um histórico atribuível dos repasses, ou se o primeiro se tornará a única narrativa de desempenho. Até 6 de setembro, as contribuições individuais são sinais de deliberação, não consenso; a proposta continua aberta e ainda não é um compromisso adotado.

Fontes

  1. Consulta sobre SLA para edição e publicação de RFCs
  2. Anúncio da consulta pela IETF Administration LLC
  3. RFC 9280: RFC Editor Model, versão 3
  4. RFC 8711: estrutura da atividade de suporte administrativo da IETF
  5. Processo de publicação para autores
  6. Funcionamento da fila do RFC Editor
  7. Relatório do RPC aos presidentes de grupos de trabalho
  8. Relatório sobre tempo de publicação e estados do processo
  9. Resposta individual de Mirja Kühlewind
  10. Resposta individual de Acee Lindem