Resumen

  • En la operación actual del IETF, un Internet-Draft suele caducar 185 días después de entrar en el repositorio, salvo que un estado formal de tramitación impida el vencimiento. La etiqueta describe la vida de la versión activa; no identifica a un órgano que haya rechazado la propuesta.
  • El Repository activo y el Archive histórico son superficies distintas. Una versión deja de estar activa por actualización, sustitución, publicación como RFC o caducidad, mientras que sus versiones se conservan normalmente en el Archive.
  • Los historiales oficiales muestran la diferencia. draft-iab-protocol-maintenance-05 caducó, volvió en revisiones posteriores y terminó como RFC 9413. draft-ietf-netvc-testing caducó varias veces, pero su cierre relevante fue otro evento: un estado IESG Dead con una razón expresa.
  • Una revisión diligente necesita un recibo de estado: nombre y revisión exactos, fechas, archivo y cadena de sustitución, grupo y flujo, adopción y Last Call, disposición explícita, dependencia técnica y responsable del juicio.

La casilla que convirtió un reloj en veredicto

Pensemos en una empresa que estudia una extensión de protocolo. El analista consulta el Datatracker, ve que la última revisión está Expired y anota «el IETF la rechazó». Producto elimina la función de su hoja de ruta. Auditoría reproduce la frase. Meses después aparece otra revisión y el inventario cambia a «el IETF ha retomado y aprobado el trabajo».

Las observaciones son reales: hubo caducidad y luego una revisión. Las conclusiones institucionales son inventadas. La primera transforma un límite automático en rechazo; la segunda convierte la entrega de un archivo nuevo en aprobación.

Un rechazo necesita sujeto, competencia y objeto. ¿El grupo de trabajo decidió no adoptar el texto? ¿El chair concluyó que no había rough consensus? ¿Un Area Director descartó patrocinarlo? ¿El IESG cerró una solicitud de publicación? ¿Los autores dejaron de editar? ¿Otro draft sustituyó al anterior? ¿O seguía habiendo interés mientras el documento atravesaba su fecha automática?

Expired no responde por sí solo. Constata una condición de ciclo de vida. Para afirmar que una institución decidió algo hay que localizar un evento diferente, con actor, versión, fecha, alcance y razones.

Repository, Archive y el evento de 185 días

La guía vigente de IETF Author Resources distingue entre el Repository de Internet-Drafts y su Archive. El Repository contiene las versiones activas. Una revisión deja de ser activa cuando otra la actualiza, otro Internet-Draft la sustituye, se publica como RFC o caduca. El Archive conserva todas las versiones y sus representaciones adicionales, salvo retiradas excepcionales.

La regla operativa fija normalmente la caducidad 185 días después del depósito. Algunos estados formales la evitan, por ejemplo cuando el IESG tramita la publicación en el flujo IETF o cuando el Independent Series Editor revisa un texto para el Independent Submission Stream. El reloj, por tanto, también se relaciona con el expediente de procedimiento; no es una guillotina idéntica para todos los casos.

Que el Archive conserve una revisión no la convierte en una publicación de archivo. La propia guía insiste en que un Internet-Draft sigue siendo work in progress y debe citarse como tal. La preservación demuestra qué texto existió. No demuestra qué aprobó el IETF.

La sección 2.2 de RFC 2026 permite ver la evolución. En 1996, BCP 9 describía el directorio como lugar para someter documentos cambiantes a comentario informal. Si un draft permanecía seis meses sin cambios ni recomendación del IESG para publicarlo, se retiraba; una versión nueva reiniciaba el plazo. También advertía que los Internet-Drafts carecen de estatus formal.

La infraestructura actual añade el plazo concreto de 185 días y un Archive duradero. No invierte la frontera: el draft no es un RFC y el vencimiento del repositorio no sustituye una decisión atribuible.

Cuatro capas que no caben en una etiqueta

Un registro fiable separa, como mínimo, cuatro planos.

El primero es la identidad documental. draft-example-foo-04 no es una idea abstracta llamada «Foo», sino una revisión con fecha, bytes y referencias concretas. La 05 puede corregir una condición de seguridad, cambiar el mecanismo o reducir el ámbito. Un informe sin sufijo de revisión no puede demostrar qué texto leyó.

El segundo es el ciclo de vida del repositorio. Active, updated, replaced, published y expired explican por qué una versión sigue o deja de ser la copia activa. Sirven para localizar trabajo reciente, no para medir por sí solos mérito técnico o consenso.

El tercero es el estado de procedimiento. Una contribución individual, un candidato a adopción, un documento de grupo adoptado, un texto en Working Group Last Call y una solicitud en evaluación del IESG ocupan posiciones distintas. RFC 2418, sección 7.2, presenta los drafts como documentos en curso; la sección 7.4 trata el Last Call como un acto separado; la sección 7.5 distingue el rough consensus para avanzar y la remisión al IESG.

El cuarto es la disposición. Un actor competente puede registrar adopción, sustitución, retirada, negativa, aprobación, publicación o cierre, a veces con motivos y recurso. Aquí puede encontrarse una conclusión adversa real. No debe deducirse del calendario.

Las capas se mueven por separado. Un documento de grupo puede caducar mientras se prepara su revisión. Un draft individual puede estar activo sin patrocinador. Un diseño ya implementado puede morir en la vía de publicación. Una revisión caducada puede ser seguida por otra con el mismo nombre. Un semáforo único no representa esas combinaciones.

El draft que caducó y acabó como RFC 9413

El historial oficial de Maintaining Robust Protocols desmiente la equivalencia. La revisión 05 se publicó el 12 de julio de 2021 y el sistema la marcó caducada el 13 de enero de 2022. La 06 apareció el 10 de mayo. Siguieron las revisiones 07 a 12. El IAB llevó el documento a Community Review e IAB Review, registró consenso y aprobación y lo envió al RFC Editor en febrero de 2023.

El resultado se publicó como RFC 9413 en junio de 2023. La caducidad de la 05 es un hecho histórico. Describirla como rechazo del IAB o del IETF sería falso: el reloj no impidió ni decidió las revisiones y revisiones posteriores.

El ejemplo no permite afirmar que todo draft caducado vaya a volver. Prueba algo más acotado: caducidad y rechazo no son equivalentes. Si un modelo solo puede sobrescribir «rechazado» con «aprobado», su vocabulario ha destruido la secuencia que debía conservar.

La ficha correcta mantiene cada evento. El 13 de enero la 05 salió del estado activo por caducidad automática; el 10 de mayo apareció la 06. Las entradas posteriores nombran órganos y decisiones. RFC 9413 registra el desenlace editorial. Cada hecho conserva su fecha y su actor.

El draft cuyo cierre real sí tuvo motivo

El historial de Video Codec Testing and Quality Measurement muestra el caso contrario. La revisión 05 caducó en septiembre de 2017 y la 06 llegó el mes siguiente. La 06 caducó en mayo de 2018; la 07 apareció en julio y entró en Last Call del grupo. En enero de 2019, la 07 caducó mientras el estado del grupo indicaba consenso a la espera del write-up. Después, la 08 entró en tramitación e IETF Last Call.

La conclusión adversa significativa llegó el 25 de marzo de 2020. El estado IESG pasó a Dead. La nota del Area Director explicó que, tras repetidos intentos de lograr respuestas a los comentarios de evaluación, el grupo NETVC carecía del impulso suficiente para completar el documento. Otra caducidad automática se registró en agosto.

Ahora sí existe un cierre citable: fecha, superficie decisoria y motivo. El motivo habla de falta de impulso y comentarios pendientes; no declara inútiles los métodos de prueba. El write-up del shepherd señalaba incluso que ya los usaban implementadores de AV1. Dependencia de implementación, disposición de publicación y caducidad fueron hechos separados.

Llamar rechazo solo a la última caducidad ocultaría la mejor evidencia, la transición IESG y su explicación. Llamar rechazo a las caducidades anteriores contradice que el trabajo continuó.

Una revisión nueva tampoco es aprobación

La regla es simétrica. Si caducar no prueba rechazo, revisar no prueba aceptación. Cualquier persona que cumpla las condiciones puede presentar un Internet-Draft. Una nueva versión puede responder comentarios, recuperar visibilidad, reabrir una conversación o mantener abierta la posibilidad de continuar.

El nombre tampoco resuelve todo. draft-ietf-... suele reflejar adopción por un grupo, pero el estado y el historial exactos siguen siendo la prueba. El prefijo no demuestra rough consensus actual sobre cada frase ni aprobación del IESG. Un Last Call abre una revisión concreta; no es publicación.

El running code no fabrica estatus institucional. La implementación aporta evidencia esencial sobre interoperabilidad, utilidad y coste de cambio. La primacía del código en funcionamiento de Heng Lu disciplina la autoridad del papel. Pero un despliegue demuestra realidad operativa, no crea un acta de consenso. Ambos expedientes deben conservarse separados.

Los adoptantes externos también deben asumir su elección. Un comprador puede fijar deliberadamente una revisión de draft para obtener una capacidad antes de que exista un RFC. La obligación nace del contrato, no de la etiqueta del repositorio. Debe identificar versión, reglas de cambio, pruebas y salida.

La propuesta de eliminar la caducidad sigue siendo una propuesta

El draft individual Removing Expiration Notices from Internet-Drafts sostiene que la caducidad automática ha perdido utilidad desde que las versiones permanecen archivadas. Señala que los drafts caducados siguen citándose y que algunos sistemas solo modifican su presentación. Es evidencia válida de desacuerdo entre participantes experimentados.

Su última revisión también ha caducado. La ironía no da permiso para ridiculizarlo ni para otorgarle autoridad. No se adoptó como norma vigente. Se pueden valorar sus argumentos, pero su existencia no significa que «el IETF decidió abolir la caducidad».

Esa es la disciplina central: un draft puede razonar bien sin estatus formal; una etiqueta puede ser correcta sin juzgar el fondo. Solo un acto trazable del actor autorizado conecta ambas cosas.

El recibo de estado del draft

Un inventario debe permitir que otro profesional reconstruya el juicio sin adivinar qué significaba un distintivo en una fecha.

Campo Qué acredita
Nombre y revisión exactos El texto evaluado, no una idea flotante
Huella de contenido Coincidencia entre los bytes revisados y la versión preservada
Fechas de publicación y caducidad El evento temporal y la regla aplicable
Estado del Repository Si la revisión está activa y por qué dejó de estarlo
Ubicación del Archive Dónde se conservan texto y representaciones
Cadena de revisiones Versiones previas y posteriores sin confundirlas
Relaciones de sustitución Si otro nombre continuó o desplazó el trabajo
Flujo, patrocinador y grupo Qué institución, si existe, controla el siguiente paso
Estado de adopción Si el grupo asumió el trabajo y con qué prueba
Consenso y Last Call Qué revisión se examinó y qué objeciones siguen abiertas
Disposición IESG o de flujo Decisión real, actor, fecha, estado y razones
Resultado editorial Número, flujo y categoría del RFC eventual
Dependencia técnica Código, pruebas y despliegues aún vinculados
Instrumento externo Contrato o política que seleccionó la revisión
Responsable y revisión Quién corregirá el inventario cuando cambie el expediente

El recibo evita errores opuestos. Convertir Active, adopted o Last Call en «aprobado por el IETF» infla autoridad. Convertir Expired en «rechazado por el IETF» inventa autoridad negativa. La primera afirmación necesita un acto positivo; la segunda, una disposición adversa. El reloj no aporta ninguna.

Fuentes

Conclusión

Expired es una advertencia útil. La revisión activa ha atravesado un límite de frescura y cualquier dependencia merece nueva diligencia. No revela por qué se detuvo el trabajo, si hubo juicio técnico ni si el órgano competente decidió algo.

La regla práctica es conservar dos recibos: caducidad como recibo del reloj y disposición como recibo de autoridad. Si el trabajo se cerró, hay que nombrar actor, proceso, versión, fecha y motivos. Si reaparece, se registra la nueva revisión sin inventar aprobación. Si un implementador o comprador sigue dependiendo de ella, debe reconocer su propia decisión. Un calendario puede envejecer un documento; no puede votar.