Resumen

  • La página de charter-ietf-radext-07-08, actualizada el 6 de agosto de 2026, identifica el texto como una propuesta en External Review y señala que la carta aprobada continúa siendo la versión 07.
  • La propuesta incluye dos envíos al IESG previstos para mayo, cinco para agosto y uno para diciembre. Las ocho celdas de documentos asociados están vacías.
  • Los dos borradores que mejor encajan con mayo son documentos activos del grupo RADEXT, pero ambos permanecen en I-D Exists. El de revisión de seguridad se presenta como Informational aunque el hito dice Proposed Standard.
  • Los cinco hitos de agosto parecen corresponder a tres borradores individuales expirados, un candidato a adopción expirado y un candidato activo. Connect-Info, el candidato activo, también muestra una diferencia entre Informational y el Proposed Standard del hito.
  • Expired no significa abandonado, Candidate for WG Adoption no significa adoptado y I-D Exists no significa que el IESG haya recibido el documento. La tabla no permite convertir las siete fechas en siete veredictos.
  • IETF debería mantener una línea base versionada que una cada hito con el documento, su vía de publicación, el estado de adopción e IESG, la transición medida, la fecha efectiva y la razón de cualquier reprogramación.

Dos relojes sin una unión visible

RADEXT es el grupo que mantiene y extiende RADIUS, pieza histórica de la autenticación, autorización y contabilidad en redes de acceso. Datatracker muestra ahora la propuesta 07-08, pero advierte que la carta vigente y aprobada es la versión 07. Por tanto, la página no describe simplemente una lista de tareas corriente: presenta un futuro ámbito de trabajo aún sometido a revisión institucional.

El estado completo es External Review (Message to Community, Selected by Secretariat). La ayuda del propio Datatracker distingue esa fase de IESG Review y de Approved. Una revisión nueva o una objeción retirada puede ser evidencia de progreso; no sustituye el cambio formal a Approved.

El historial permite reconstruir parte de la secuencia. El 12 de mayo se añadieron ocho hitos. El 22 de julio se abrió la revisión externa y se creó una papeleta de aprobación. A finales de julio y comienzos de agosto aparecieron Blocks sobre coordinación del control de congestión, ubicación de trabajos y condición editorial. Entre 07-05 y 07-08 el texto cambió, y el 6 de agosto todos los Blocks registrados ya constaban como No Objection.

Esto descarta una lectura fácil: no quedan Blocks abiertos en el historial consultado. Pero tampoco autoriza a anticipar el resultado. La página seguía diciendo External Review en la fecha de corte y no explica la falta de una transición posterior.

El otro reloj está en los hitos. Mayo contiene dos entregas Proposed Standard al IESG. Agosto contiene cuatro Proposed Standards y un Informational. Diciembre añade otro Proposed Standard. En ninguna de las ocho filas aparece un enlace bajo Associated documents. Se puede leer una descripción y un mes, pero no abrir el objeto cuyo movimiento debería confirmar el cumplimiento.

Mayo: actividad comprobable, envío no registrado

El primer hito de mayo se refiere a la revisión de seguridad y privacidad de RADIUS. La coincidencia más fuerte es draft-ietf-radext-review-radius-02, documento activo del grupo actualizado el 10 de agosto. Datatracker lo mantiene en I-D Exists, y su cabecera indica Informational.

La actualización de agosto demuestra que no es un trabajo inmóvil. A la vez, el estado no registra la transición “to IESG” que figura en la carta propuesta. Además, la ruta editorial no coincide: Proposed Standard en el hito e Informational en el documento. Ninguno de esos datos resuelve por sí solo cuál debe prevalecer.

El segundo hito menciona la eliminación gradual de prácticas inseguras. draft-ietf-radext-deprecating-radius-10 es un documento activo de RADEXT, revisado el 3 de julio, con document shepherd y cabecera Standards Track. También aparece en I-D Exists. Su página conserva un hito de enero de 2024 procedente de la carta aprobada, mientras la propuesta coloca la entrega en mayo de 2026.

Las actas de IETF 126 dan contexto operativo. El 22 de julio, la presidencia señaló que los dos borradores todavía no habían superado el Working Group Last Call y que debían entrar en esa fase pronto. La conclusión adecuada no es que nada ocurrió ni que el envío se completó: el trabajo avanzaba, pero el cambio concreto nombrado por el hito no consta en el registro.

Agosto mezcla borrador, candidatura, adopción y publicación

Para control de congestión, el candidato más reconocible es draft-janfred-radext-radius-congestion-control-01. Es un borrador individual sin stream, cuya última versión apareció en octubre de 2025 y expiró en abril de 2026. La historia de la carta confirma que el asunto de coordinación se debatió durante la revisión. Como la fila no enlaza el texto, la asociación sigue siendo una inferencia editorial.

El hito sobre reparto de carga en proxies probablemente apunta a draft-dekok-radext-proxy-load-00, también individual, sin stream y expirado. Su resumen afirma que, en aquella revisión, no había suficiente experiencia operativa para avanzar por Standards Track o como BCP. La carta propuesta, sin embargo, anuncia un Proposed Standard en agosto. Podría existir una futura revisión, otro documento o una decisión posterior; la página pública no permite escoger entre esas hipótesis.

La coincidencia para incertidumbre de localización es draft-grayson-5580uncertainty-00. El borrador individual ha expirado. La vía Informational de la fila parece compatible con el tema, pero falta la asociación oficial y no aparece una transición al IESG.

draft-gundavelli-radepcs-02, sobre atributos para comunicaciones de emergencia, está catalogado como Candidate for WG Adoption y expiró en julio. Un candidato puede volver con una nueva revisión; la expiración no lo cancela. Sin embargo, ninguna de esas condiciones equivale a una adopción del grupo, mucho menos a una presentación ante el IESG.

Connect-Info ofrece el ejemplo más claro de dependencia institucional. draft-grayson-connectinfo-10 está activo, es Candidate for WG Adoption y sigue en I-D Exists. Su cabecera dice Informational, no Proposed Standard. Las actas de IETF 126 indican que una consulta previa a la adopción encontró consenso, pero que la adopción se realizaría tras completar la nueva carta.

Por eso una fecha desnuda resulta insuficiente. Hay señal de consenso, documento activo y expectativa de adopción; también hay una condición previa que todavía no figura como aprobada. El hito no distingue esos escalones.

El renglón de diciembre aún no venció

La fila final prevé para diciembre un documento sobre Status-Realm y prevención de bucles. La correspondencia probable es draft-ietf-radext-status-realm-01, borrador del grupo que expiró después de su revisión de marzo de 2025.

El mes todavía era futuro en la fecha de corte. No cabe etiquetarlo como retraso. La expiración sí merece vigilancia, porque hará falta una revisión, un sustituto, un cambio de alcance o una nueva fecha si ese documento ha de alcanzar el estado descrito. Es una alerta prospectiva, no una sentencia.

Un hito debe registrar una transición

RFC 2418 explica que los objetivos y plazos de una carta sirven al Area Director para seguir el progreso y a los posibles participantes para reconocer momentos importantes de intervención. También prevé que la lista se actualice periódicamente. Las fechas no son decoración; distribuyen atención.

Para que esa función sea auditable, cada fila necesita un identificador estable, la versión y estado de la carta, el documento exacto, su condición individual o de grupo, y la vía prevista tanto en la carta como en la cabecera vigente. Sobre todo, debe definir el evento: adopción, Working Group Last Call y envío al IESG son decisiones diferentes.

Después puede registrar una fecha real o un estado controlado: previsto, activo, logrado, reprogramado, sustituido o bloqueado. Una reprogramación debería conservar la fecha anterior y nombrar causa, autoridad y dependencia. Si mayo ya era retrospectivo cuando se añadió el día 12, conviene indicarlo. Si agosto dependía de la aprobación, la dependencia debe ser visible. Si cambió la vía de Proposed Standard a Informational, el registro debe mostrar la decisión.

La idea de registro de Heng Lu resulta útil en este punto preciso: una institución debería reflejar el estado que pretende coordinar. No implica equiparar una carta de IETF a un instrumento soberano ni juzgar ilegítimo el proceso de RADEXT. Significa que el calendario no debería obtener su autoridad de un vacío entre páginas. La propuesta fija dirección; una línea base versionada conserva lo sucedido.

Fuentes

  1. Heng Lu, The Policy Mirror
  2. Propuesta de nueva carta de RADEXT
  3. Historial de la carta de RADEXT
  4. Definiciones de estados de cartas en Datatracker
  5. Página del grupo RADEXT
  6. Documentos del grupo RADEXT
  7. Actas de RADEXT en IETF 126
  8. RFC 2418
  9. Revisión de seguridad y privacidad de RADIUS
  10. Eliminación de prácticas inseguras de RADIUS
  11. Borrador sobre control de congestión en RADIUS
  12. Borrador sobre carga de proxies RADIUS
  13. Borrador sobre incertidumbre de localización
  14. Borrador sobre atributos de preparación para emergencias
  15. Borrador Connect-Info
  16. Borrador Status-Realm