Resumen

  • Final Review, antes AUTH48, empieza después de que uno de los flujos de la serie RFC aprueba un Internet-Draft. Los autores comprueban el contenido completo y sus formatos y autorizan la publicación; es una salvaguarda real, no otra votación del IETF.
  • Al entrar en la cola, el RFC Production Center asume el control de la copia de producción. Puede tramitar correcciones editoriales, pero los añadidos, supresiones y cambios técnicos que excedan esa función necesitan aprobación del flujo de origen.
  • El piloto de kramdown-rfc y GitHub de 2025–2026 hace visible la frontera. El 27 de agosto de 2026, RFC-to-be 10025 conservaba página de Final Review y repositorio público, mientras la página de información del RFC aún devolvía 404.
  • El recibo correcto debe unir revisión aprobada, decisión del flujo, cambios del RPC, clasificación de cada ajuste, conformidades de autores y del flujo, huellas de las salidas finales y anuncio de publicación. La adopción operativa se prueba aparte.

La pull request que parecía otra elección

La pantalla enseñaba actividad, no soberanía. Había una rama RPC-edits, quince issues, una pull request y una lista de personas llamadas a revisar. Para un inventario acostumbrado a reducir cada documento a un solo estado, el salto era tentador: si hay cambios abiertos, la norma no fue aprobada; si falta una firma, un autor la vetó; si hay comentarios, el consenso se reabrió.

La posición institucional de Final Review es más estrecha y más útil. Antes de ella, el flujo correspondiente decide que un Internet-Draft debe publicarse. Después, el RPC producirá unos archivos determinados y anunciará el RFC. Entre ambas acciones se comprueba que la edición representa fielmente lo aprobado y que HTML, PDF, texto y XML no introducen errores.

Ese trabajo puede proteger a los futuros lectores de un fragmento roto, una referencia incorrecta o una instrucción IANA contradictoria. No por ello crea una asamblea nueva. El autor conserva responsabilidad sobre la exactitud; el editor conserva custodia sobre la producción; el flujo conserva la autoridad sobre cambios sustantivos.

La virtud del piloto no está en convertir GitHub en urna, sino en separar pruebas. El punto de partida, el diff, la pregunta, la respuesta y la autorización pueden seguirse. La apertura fortalece la gobernanza cuando permite atribuir actos distintos, no cuando llama «decisión» a cualquier intervención visible.

La aprobación ocurre antes de entrar en la cola

La guía vigente de publicación sitúa el primer acto en uno de cinco flujos: IETF, IAB, IRTF, Independent o Editorial. Solo después de su aprobación llega el Internet-Draft a la cola del RPC. Por eso la copia que recibe el centro de producción ya tiene una procedencia decisoria.

Desde la entrada, el RPC mantiene el control de cambios de la copia de producción. Un autor no reemplaza por su cuenta el texto que fue aprobado. Solicita el ajuste dentro de esa custodia; si el ajuste añade, elimina o cambia sustancia técnica, se requiere al flujo que lo autorice.

El RFC 9920 distribuye las funciones sin ambigüedad. El órgano aprobador responde del contenido de su flujo. La función RFC Editor responde de producción y distribución. El RPC edita, conserva los cambios y el diálogo con autores, identifica posibles efectos técnicos, pide aclaraciones, determina preparación y publica.

Cada actor perdería legitimidad si absorbiera al otro. Un flujo que no cuidara la producción entregaría un archivo inestable. Un RPC que reescribiera la técnica dejaría de producir la decisión recibida. Un autor que introdujera una política nueva en el último minuto eludiría el proceso colectivo. El registro debe comenzar con la revisión exacta aprobada y con el nombre de quien la aprobó.

Qué aprueban de verdad los autores

Final Review obliga a leer de nuevo. Los autores resuelven preguntas de los editores, revisan aportaciones de coautores, inspeccionan todo el contenido, las leyendas jurídicas, el marcado semántico y las salidas renderizadas. La aprobación final se refiere a una edición concreta y a las representaciones que serán públicas.

Las instrucciones del piloto piden primero conformidad para convertir el markdown estable a RFCXML y después conformidad con contenido y formatos finales. La separación responde a una realidad: una fuente correcta puede producir un PDF ilegible, código deformado o jerarquía semántica errónea.

La firma del autor es una garantía de fidelidad, no una investidura política. Protege el significado y la atribución. Si la modificación propuesta cruza la línea editorial, la responsabilidad vuelve al flujo.

La regla para autores no disponibles evita que esa garantía se convierta en un bloqueo accidental. Los demás pueden trasladar a la persona a Agradecimientos o Colaboradores, o un responsable del flujo puede aprobar en su lugar. Deben quedar documentados el motivo, la vía elegida, quien sustituyó la conformidad y la fecha. El procedimiento preserva crédito y continuidad sin fingir que una cuenta de correo es una cámara legislativa.

La frontera que no cruza un merge de GitHub

El RPC inició el piloto kramdown-rfc el 1 de septiembre de 2025. Quería trabajar en un formato ya común entre autores y obtener diferencias más limpias. El comienzo contemplaba al menos cinco solicitudes mensuales y una ampliación después de aprender del ensayo.

En 2026, las instrucciones emplean Final Review en lugar de AUTH48. El nuevo nombre elimina una cifra que nunca garantizó dos días. GitHub muestra dónde está la copia aprobada, dónde propone el RPC sus ediciones, qué cuestiones siguen abiertas y quién debe contestar.

El repositorio de RFC-to-be 10025, relativo a la actualización de cookies HTTP, declara que su markdown inicial copia el Internet-Draft aprobado para publicación. La rama del RPC contiene las ediciones. Los autores aprueban contenido y formatos; los Area Directors aprueban lo que exceda lo editorial; chairs y shepherd participan en la superficie de revisión. Incluso se conserva una salida al proceso por correo.

En la observación del 27 de agosto, la página de estado seguía activa, el repositorio era público y el URL informativo de RFC 10025 no existía. Las quince issues y la pull request visibles no constituyen un contador de errores técnicos ni de disenso. El estado puede cambiar mañana; la evidencia debe decir cuándo fue vista.

Reservar un número de RFC no publica el documento. Tener una versión renderizada tampoco. La publicación se prueba con los artefactos finales, la página del RFC y el anuncio.

RFC 9991 y la palabra que necesitó al Area Director

La separación de poderes aparece con nitidez en la Final Review del documento que terminó como RFC 9991.

Los autores propusieron añadir una palabra clave BCP 14. Una palabra normativa en mayúsculas puede alterar una obligación técnica. En el intercambio archivado, el RPC pidió al Area Director que revisara y aprobara la adición. La respuesta fue approved.

El episodio no necesita dramatización. Precisamente porque el mecanismo funcionó, los verbos quedaron separados: los autores propusieron; el RPC clasificó y remitió; el AD aprobó; el RPC publicó después el RFC. El merge no sustituyó a la aprobación, y la aprobación no sustituyó a los archivos finales.

Una auditoría que conserve solo el texto publicado no sabrá cómo entró el cambio tardío. Una que conserve solo el correo del AD no podrá probar que la versión autorizada llegó a cada formato. La cadena completa protege tanto al lector como a los participantes del proceso.

Por qué 48 nunca fue un plazo

El nombre AUTH48 inducía a leer un compromiso de 48 horas. El RFC 8963 analizó una muestra de RFC producidos en 2018 y separó edición, AUTH48 y publicación final. En aquella muestra, AUTH48 superó un mes de media y presentó gran variación. El informe la caracterizó como verificación final: aprobar la edición o pedir una última corrección.

El RFC 8700 recoge la broma de las 48 jornadas o semanas. También conserva la regla institucional relevante: los cambios técnicos requieren aprobación del Area Director o responsable del flujo.

La duración no identifica por sí sola al responsable. Puede faltar una respuesta, una acción IANA, una referencia, una decisión del flujo o una corrección de herramientas. El reloj indica que conviene preguntar; no responde por qué.

Cambiar AUTH48 por Final Review corrige la metáfora temporal. La organización no debería reemplazarla por otra metáfora falsa, la de una nueva votación. Es una finalización controlada.

El recibo de Final Review

Campo Evidencia Razón
Fuente aprobada Nombre, revisión, bytes y hash Fija la base decidida por el flujo
Decisión Flujo, órgano, fecha y enlace Identifica la autoridad
Entrega al RPC Hora y estado de cola Separa aprobación y producción
Cambios Rama, diff y hash Muestra lo alterado tras la decisión
Cuestiones Pregunta, actor, respuesta y archivo Atribuye la resolución
Clase Editorial, formato, técnica o más allá Define quién debe aprobar
Conformidad de autores Persona, alcance y hora Vincula revisión y salidas
Aprobación del flujo Recibo de AD o responsable Mantiene la frontera sustantiva
Retenciones IANA, referencias, flujo o herramientas Nombra el bloqueo verdadero
Salidas Hashes de HTML, PDF, TXT y XML Une conformidad y publicación
Publicación Anuncio, URL y fecha Prueba que existe el RFC
Adopción Código, pruebas y despliegue Evita convertir papel en operación

Un recibo así no automatiza el juicio. Impide que desaparezca su autor. Permite decir qué falta exactamente sin recurrir a «veto», «rechazo» o «segunda votación».

Fuentes

El estado de RFC-to-be 10025 queda limitado al 27 de agosto de 2026. No se predice su publicación ni se equiparan las issues a fallos.