Resumo

  • Na operação atual da IETF, um Internet-Draft normalmente expira 185 dias depois de entrar no Repository, salvo quando um estado formal impede o vencimento. O rótulo descreve a vida da versão ativa; não identifica um órgão que tenha rejeitado a proposta.
  • Repository e Archive têm funções diferentes. Atualização, substituição, publicação como RFC e expiração retiram uma versão da superfície ativa, enquanto o Archive preserva as versões, salvo remoções excepcionais.
  • Os históricos oficiais separam relógio e decisão. draft-iab-protocol-maintenance-05 expirou, voltou em revisões posteriores e tornou-se o RFC 9413. draft-ietf-netvc-testing expirou várias vezes, mas seu encerramento relevante foi outro registro: estado IESG Dead com motivo explícito.
  • Uma análise responsável precisa de um recibo de estado: nome e revisão exatos, datas, cadeia de versões e substituições, grupo e fluxo, adoção e Last Call, disposição formal, dependência de implementação e responsável pela conclusão.

A planilha que transformou prazo em sentença

Considere uma empresa avaliando uma extensão de protocolo. O analista abre o Datatracker, vê a última revisão como Expired e registra “a IETF rejeitou”. Produto remove a função do roadmap; segurança copia a frase. Meses depois surge nova revisão, e a mesma planilha passa a dizer “a IETF retomou e aprovou”.

Os fatos observados são verdadeiros: houve expiração e, depois, revisão. As decisões atribuídas são inventadas. O primeiro lançamento converte um evento automático em rejeição; o segundo toma um arquivo novo por aprovação.

Rejeição exige sujeito e competência. O grupo recusou adoção? O chair concluiu que não havia rough consensus? Um Area Director deixou de patrocinar? O IESG encerrou um pedido de publicação? Os autores apenas não atualizaram? Outro draft substituiu o nome anterior? Ou o debate continuou enquanto a versão atravessava a data automática?

Expired sozinho não responde. Ele prova uma condição de ciclo de vida. Para declarar uma decisão institucional, o registro precisa localizar outro evento e guardar ator, versão, data, escopo e razões.

Repository, Archive e os 185 dias

A orientação atual do IETF Author Resources distingue o Repository de Internet-Drafts do Archive. O Repository contém versões ativas. Uma versão deixa essa superfície ao ser atualizada, substituída por outro draft, publicada como RFC ou expirada. O Archive mantém as versões e representações adicionais, exceto em retiradas excepcionais.

O prazo operacional é normalmente de 185 dias. Alguns estados formais impedem a expiração, como o processamento pelo IESG para publicação no fluxo IETF ou a revisão pelo Independent Series Editor no fluxo independente. Até o relógio consulta o processo; não se trata de guilhotina uniforme.

Permanecer no Archive não torna o draft uma publicação arquivística. A mesma orientação diz que Internet-Drafts são trabalhos em andamento. Preservação responde “qual texto existiu?”, não “o que a IETF aprovou?”.

A seção 2.2 do RFC 2026 mostra a evolução. Em 1996, o diretório expunha textos em desenvolvimento para revisão informal. Depois de mais de seis meses sem alteração e sem recomendação do IESG para publicação, o documento era removido; uma versão nova reiniciava o período. O RFC também dizia que Internet-Drafts não têm status formal.

Hoje há 185 dias e Archive persistente. A ferramenta mudou; o limite institucional não. Draft não é RFC, e vencimento do Repository não substitui uma decisão atribuível.

Quatro estados que não cabem no mesmo selo

O primeiro plano é a identidade documental. draft-example-foo-04 é uma revisão concreta, com data, bytes e referências. A 05 pode corrigir segurança ou mudar escopo. Sem o sufixo, a diligência não prova qual texto examinou.

O segundo é o ciclo do repositório. Active, updated, replaced, published e expired explicam por que uma revisão é ou deixa de ser ativa. Ajudam a encontrar o trabalho atual; não medem mérito ou consenso.

O terceiro é o estado processual. Submissão individual, candidata a adoção, documento adotado, Working Group Last Call e pedido em avaliação pelo IESG ocupam posições diferentes. RFC 2418, seção 7.2, trata drafts como documentos em curso; a seção 7.4 separa o Last Call; a seção 7.5 distingue rough consensus para avanço e submissão ao IESG.

O quarto é a disposição. Um ator competente registra adoção, substituição, retirada, recusa, aprovação, publicação ou encerramento, às vezes com motivos e recurso. Uma conclusão adversa real deve vir daqui, não do calendário.

As camadas mudam separadamente. Um documento de grupo pode expirar enquanto a revisão continua planejada. Um draft individual pode estar ativo sem patrocinador. Um desenho implementado pode morrer na publicação. Uma revisão expirada pode ganhar sucessora com o mesmo nome. Um único semáforo não representa essa variedade.

O draft que expirou e virou RFC 9413

O histórico de Maintaining Robust Protocols derruba a equivalência. A revisão 05 foi publicada em 12 de julho de 2021 e expirou em 13 de janeiro de 2022. A 06 apareceu em 10 de maio; vieram depois as revisões 07 a 12. O IAB conduziu Community Review e IAB Review, registrou consenso e aprovação e enviou o texto ao RFC Editor em fevereiro de 2023.

O resultado tornou-se o RFC 9413 em junho de 2023. A expiração da 05 é fato histórico, mas chamá-la de rejeição do IAB ou da IETF seria falso. O relógio não bloqueou nem decidiu o percurso posterior.

O caso não promete retorno a todo draft expirado. Prova apenas que expiração e rejeição não são logicamente iguais. Um modelo que sobrescreve “rejeitado” por “aprovado” apaga a cadeia que deveria preservar.

O registro adequado conserva todos os eventos: saída automática da 05, chegada da 06, etapas de revisão com seus atores e, por fim, publicação como RFC 9413.

O draft cujo encerramento tinha responsável e razão

O histórico de Video Codec Testing and Quality Measurement mostra o outro lado. A revisão 05 expirou em setembro de 2017 e a 06 chegou no mês seguinte. A 06 expirou em maio de 2018; a 07 surgiu em julho e entrou em Last Call do grupo. Em janeiro de 2019, a 07 expirou quando o estado do grupo indicava consenso aguardando write-up. A 08 seguiu para o processo de publicação e IETF Last Call.

O registro adverso relevante veio em 25 de março de 2020. O estado IESG mudou para Dead. A nota do Area Director explicou que, após repetidas tentativas de obter resposta aos comentários de avaliação, o grupo NETVC já não tinha impulso suficiente para concluir o documento. Outra expiração automática ocorreu apenas em agosto.

Agora há encerramento citável: data, instância e motivo. O motivo é falta de impulso e comentários não resolvidos, não uma prova de que os métodos eram inúteis. O write-up dizia que implementadores de AV1 já os usavam. Uso técnico, disposição editorial e expiração eram fatos distintos.

Chamar apenas a última expiração de rejeição esconderia a melhor evidência, a mudança IESG e sua explicação. Chamar as primeiras de rejeição contrariaria a continuação documentada.

Voltar a ficar ativo não significa aprovação

A fronteira é simétrica. Se expirar não prova rejeição, revisar não prova aceitação. Qualquer pessoa apta pode apresentar um Internet-Draft. Uma versão nova pode responder comentários, recuperar visibilidade, reabrir debate ou manter aberta a opção de trabalho.

O nome do arquivo não resolve tudo. draft-ietf-... costuma refletir adoção de grupo, mas o histórico exato segue sendo a evidência. O prefixo não prova rough consensus atual sobre cada frase nem aprovação do IESG. Last Call abre revisão; não é publicação.

Running code também não fabrica status. Implementação é prova valiosa de interoperabilidade, utilidade e custo. A primazia do código em execução defendida por Heng Lu limita autoridade puramente documental. Mas implantação demonstra realidade operacional, não cria ata de consenso. Os dois registros devem permanecer separados.

Adotantes externos precisam assumir sua decisão. Um comprador pode fixar uma revisão para obter capacidade antes do RFC. A obrigação nasce do contrato, não do selo do Repository. A versão, a regra de mudança, os testes e a saída precisam estar explícitos.

A proposta de acabar com a expiração continua sendo proposta

O draft individual Removing Expiration Notices from Internet-Drafts argumenta que a expiração perdeu utilidade quando versões passaram a permanecer arquivadas. Observa que drafts expirados ainda são citados e que alguns sistemas apenas mudam sua apresentação. É evidência de debate, não de consenso.

Sua última revisão também expirou. A ironia não dá licença para ridicularizar o argumento nem lhe dar autoridade. O texto não foi adotado como regra. Sua existência não permite escrever “a IETF aboliu a expiração”.

Um draft pode conter boa análise sem status formal; um selo pode estar correto sem julgar mérito. Só um ato rastreável do ator competente conecta os dois.

O recibo de estado

Campo O que estabelece
Nome e revisão exatos O texto avaliado, não uma ideia móvel
Impressão do conteúdo Correspondência entre bytes lidos e preservados
Datas de postagem e expiração Evento temporal e regra aplicável
Estado do Repository Se está ativo e por que saiu
Local do Archive Onde ficam texto e representações
Cadeia de revisões Versões anteriores e posteriores sem confundi-las
Relações de substituição Se outro nome continuou o trabalho
Fluxo, patrocinador e grupo Quem controla a próxima etapa
Estado de adoção Se o grupo assumiu o trabalho e com que prova
Consenso e Last Call Qual revisão foi examinada e o que ficou aberto
Disposição IESG ou de fluxo Decisão, ator, data e motivos reais
Resultado editorial Número, fluxo e categoria do RFC eventual
Dependência técnica Código, testes e implantações relacionados
Instrumento externo Contrato ou política que escolheu a revisão
Responsável e revisão Quem corrige o inventário quando algo muda

O recibo impede dois erros opostos. Transformar Active, adopted ou Last Call em “aprovado pela IETF” infla autoridade. Transformar Expired em “rejeitado pela IETF” inventa autoridade negativa. Uma afirmação exige ato positivo; a outra, disposição adversa. Relógio não fornece nenhum dos dois.

Fontes

Conclusão

Expired é alerta útil: a revisão ativa atravessou limite de atualidade e a dependência merece nova diligência. Não revela por que o trabalho parou, se houve julgamento técnico ou se o órgão competente decidiu algo.

A regra prática é guardar dois recibos. Expiração é recibo do relógio; disposição é recibo de autoridade. Se o trabalho acabou, registre ator, processo, versão, data e razões. Se voltou, registre a nova revisão sem inventar aprovação. Se implementador ou comprador continua dependendo, assuma a escolha sob sua própria autoridade. Calendário envelhece documento; não vota.