Resumo

  • O Datatracker identifica charter-ietf-radext-07-08, atualizado em 6 de agosto de 2026, como proposta em External Review e informa que a carta aprovada ainda é a versão 07.
  • A proposta contém dois marcos em maio, cinco em agosto e um em dezembro de 2026. As oito células de Associated documents estão vazias.
  • Os dois rascunhos mais compatíveis com maio são documentos ativos do grupo RADEXT, mas ambos permanecem em I-D Exists. A revisão de segurança se declara Informational, enquanto o marco diz Proposed Standard.
  • Os cinco itens de agosto parecem corresponder a três rascunhos individuais expirados, um candidato à adoção expirado e um candidato ativo. Connect-Info, o ativo, também diverge entre Informational e Proposed Standard.
  • Expired não é sinônimo de abandonado; Candidate for WG Adoption não é adoção; I-D Exists não é envio ao IESG. As sete datas, portanto, não autorizam sete veredictos de atraso.
  • Uma linha de base versionada deveria unir estado da carta, identidade do documento, trilha de publicação, adoção e estado no IESG, transição esperada, data real e motivo de eventual replanejamento.

O relógio da aprovação e o relógio da entrega

O RADEXT mantém e amplia o RADIUS, protocolo usado para transportar autenticação, autorização e contabilização em sistemas de acesso à rede. A página atual do Datatracker exibe a proposta 07-08, mas separa explicitamente o recharter proposto da carta aprovada, que continua na versão 07. A distinção determina o limite formal do trabalho, não apenas a etiqueta da página.

O estado completo da proposta é External Review (Message to Community, Selected by Secretariat). A ajuda do Datatracker diferencia External Review, IESG Review e Approved. Uma nova revisão, uma posição de ballot alterada ou uma objeção solucionada mostra progresso, mas não substitui o estado Approved.

O histórico registra movimento substancial. Oito marcos foram acrescentados em 12 de maio. Em 22 de julho, o texto saiu da revisão interna para External Review, com a criação de um ballot Approve. No fim de julho e começo de agosto, surgiram Blocks sobre coordenação de controle de congestionamento, localização de itens de trabalho e condição de publicação. As versões avançaram até 07-08; em 6 de agosto, todos os Blocks registrados haviam mudado para No Objection.

Assim, não há base para dizer que restam Blocks não resolvidos. Tampouco há base para antecipar a aprovação. No corte desta apuração, a página mais recente ainda dizia External Review e não explicava por que o próximo estado não havia sido registrado.

O segundo relógio está na lista de marcos. Maio reúne dois envios de Proposed Standard ao IESG. Agosto traz quatro Proposed Standards e um Informational. Dezembro acrescenta um Proposed Standard. Nenhuma linha contém link em Associated documents. A tabela mostra mês e descrição, mas não o objeto cujo movimento comprovaria a entrega.

Maio tem trabalho vivo, não o recibo da transição

O primeiro item de maio pede a revisão de segurança e privacidade do RADIUS como Proposed Standard no IESG. A correspondência mais clara é draft-ietf-radext-review-radius-02, documento ativo do grupo, atualizado em 10 de agosto. Seu estado IESG é I-D Exists e o cabeçalho pretende publicação Informational.

A revisão de agosto impede chamar o texto de parado. Ao mesmo tempo, o registro não mostra o movimento “to IESG” nomeado no marco, e a diferença entre Proposed Standard e Informational continua sem uma decisão pública que a conecte.

O segundo item trata da depreciação de práticas inseguras. draft-ietf-radext-deprecating-radius-10 é um documento ativo do grupo, atualizado em 3 de julho, com document shepherd e cabeçalho Standards Track. Ele também permanece em I-D Exists. Sua página conserva um marco de janeiro de 2024 associado à carta aprovada, enquanto o novo texto propõe maio de 2026. A continuidade entre os dois calendários não aparece.

A ata do IETF 126 esclarece a etapa. Em 22 de julho, a presidência observou que os dois documentos ainda não haviam passado pelo Working Group Last Call e deveriam avançar rapidamente para ele. É possível haver trabalho ativo e, ainda assim, não existir a submissão que o marco descreve. O registro precisa mostrar ambos.

Agosto reúne quatro graus diferentes de maturidade

O item de controle de congestionamento provavelmente aponta para draft-janfred-radext-radius-congestion-control-01. É um rascunho individual, sem stream definido, atualizado pela última vez em outubro de 2025 e expirado em abril de 2026. O histórico da carta confirma que houve debate de coordenação sobre o tema. Sem link na linha, porém, a associação é editorial, não oficial.

Para balanceamento de carga de proxies, o candidato é draft-dekok-radext-proxy-load-00, também individual, sem stream e expirado. Seu resumo diz que, naquela versão, a experiência operacional era insuficiente para Standards Track ou BCP. A proposta, por sua vez, marca Proposed Standard em agosto. Isso pode pressupor uma reescrita, outro documento ou uma decisão posterior; a tabela não informa qual.

draft-grayson-5580uncertainty-00 coincide com o título sobre incerteza de localização. É outro rascunho individual expirado. O marco o coloca como Informational, combinação plausível, mas ainda sem ligação oficial nem estado de submissão.

O texto de prioridade para emergências, draft-gundavelli-radepcs-02, aparece como Candidate for WG Adoption e expirou em julho. Candidato não é adotado e expirado não é abandonado. Uma nova versão pode reativá-lo, mas nenhuma dessas etiquetas demonstra apresentação ao IESG.

Connect-Info é o único dos cinco documentos prováveis que segue ativo. draft-grayson-connectinfo-10 está como Candidate for WG Adoption e I-D Exists. O cabeçalho indica Informational; o marco proposto, Proposed Standard. Na reunião IETF 126, a presidência informou que uma chamada prévia encontrou consenso e que a adoção ocorreria depois de concluído o recharter.

Essa dependência deveria estar na própria linha. Há texto ativo e sinal de consenso, mas a passagem institucional depende de uma carta em revisão. Uma data isolada mistura apoio, autorização, adoção e envio ao IESG.

Dezembro ainda é um sinal prospectivo

O último marco prevê Status-Realm e prevenção de loops em dezembro. O documento mais provável, draft-ietf-radext-status-realm-01, é um rascunho do grupo RADEXT cuja última versão é de março de 2025 e que hoje está expirado.

Dezembro ainda não havia chegado no corte, portanto não existe atraso a declarar. O estado expirado serve como alerta: será necessária uma nova revisão, um substituto, uma mudança de escopo ou uma nova data para alcançar a transição prevista. Alerta não é conclusão.

A data precisa apontar para uma mudança de estado

O RFC 2418 dá função prática aos marcos. Metas e prazos ajudam o Area Director a acompanhar o grupo e permitem que participantes em potencial identifiquem momentos críticos para contribuir. A lista deve ser atualizada periodicamente. Datas distribuem atenção e, por isso, precisam ser auditáveis.

Cada linha deveria ter identificador estável, versão e estado da carta, família documental exata, condição individual, candidata, adotada ou no IESG, além da trilha prevista na carta e no cabeçalho atual. Também deve nomear o evento: adoção, Working Group Last Call e submissão ao IESG não são a mesma coisa.

O registro poderia então guardar a data real ou um estado limitado — planejado, ativo, alcançado, reprogramado, substituído ou bloqueado. Uma reprogramação preservaria a meta antiga e informaria motivo, ator e dependência. Se maio já era retrospectivo quando incluído em 12 de maio, isso deve ser dito. Se agosto dependia da aprovação, a condição deve aparecer. Se a trilha mudou, a decisão precisa de recibo.

O princípio de ledger de Heng Lu cabe aqui de forma específica: o registro institucional deve descrever o estado que coordena. Não é uma tese de que a carta da IETF seja instrumento soberano nem uma acusação contra a legitimidade do RADEXT. É uma exigência mais simples: um calendário público não deve obter significado por meio do silêncio entre páginas. A carta define direção; o ledger preserva o percurso.

Fontes

  1. Heng Lu, The Policy Mirror
  2. Proposta de recharter do RADEXT
  3. Histórico da carta do RADEXT
  4. Definições de estado de cartas no Datatracker
  5. Página do grupo RADEXT
  6. Documentos do grupo RADEXT
  7. Ata do RADEXT no IETF 126
  8. RFC 2418
  9. Revisão de segurança e privacidade do RADIUS
  10. Depreciação de práticas inseguras do RADIUS
  11. Rascunho de controle de congestionamento
  12. Rascunho de carga de proxies RADIUS
  13. Rascunho de incerteza de localização
  14. Rascunho de atributos para emergências
  15. Rascunho Connect-Info
  16. Rascunho Status-Realm