Resumen

  • RFC 3967 hizo explícita durante la última llamada de la IETF una dependencia normativa de menor madurez, en vez de ocultarla como excepción.
  • RFC 4897 y RFC 8067 trasladaron algunos casos de la espera a la anotación y al criterio de la IESG; ninguno elevó la madurez del texto citado.

Una norma puede depender de un documento útil antes de que este alcance un estado tan maduro como el texto que lo cita. Una implementación quizá necesite un algoritmo descrito en un RFC Informational. Una especificación de transición puede tener que explicar la convivencia con un protocolo antiguo. Y un documento de la IETF puede recurrir a un sistema externo o propietario que no puede republicar simplemente con una categoría superior. La cuestión difícil no es que exista la referencia, sino que una norma dependa de manera normativa de un texto cuyo estado indica menos revisión o estabilidad.

La regla general de RFC 2026 intentaba conservar esa diferencia: las especificaciones Standards Track normalmente no debían depender de trabajos Standards Track de menor madurez ni de documentos ajenos a esa vía, salvo los estándares de otros organismos. RFC 3967, publicado en diciembre de 2004 como BCP 97, expresa el motivo institucional: evitar que parezca que una norma es más madura de lo que realmente es. La madurez no es una puntuación directa de calidad técnica. Pero una dependencia normativa puede contener información necesaria para implementar por completo la especificación que la cita.

Si es inestable, difícil de obtener o se interpreta mal, el documento principal quizá no sea autosuficiente.

RFC 3967 aceptó que algunas referencias descendentes eran necesarias y diseñó una excepción visible. Un documento Standards Track o BCP podía seguir la última llamada normal de la IETF, siempre que el aviso identificara expresamente la referencia descendente. Los comentarios de la comunidad sobre su idoneidad debían llegar a la deliberación de la IESG. Un director de área podía omitir avisos posteriores únicamente para el mismo documento y versión, después de que la comunidad hubiera visto la referencia varias veces y si su uso ya se consideraba aceptado en el ámbito técnico.

Era una regla de transparencia, no un visto bueno automático. RFC 3967 advertía que no debía usarse el procedimiento si lo correcto era trasladar el documento citado a la categoría adecuada. La excepción tampoco cambiaba su estado: el texto objetivo conservaba su propia madurez. El propósito era poner la dependencia a la vista y permitir objeciones antes de publicar, no presentar una diferencia de madurez como si fuera consenso.

Tres años después, RFC 4897 describió otro costo. Su introducción dice que la regla anterior había ocasionado demoras muy largas en algunos casos y que ciertas personas la consideraban un obstáculo importante para que los documentos avanzaran de nivel. Conviene conservar la cautela: en los agradecimientos, el autor también expresa dudas sobre la validez de algunas quejas y presenta la propuesta, en parte, como una forma de ponerlas a prueba. Es una fuente sobre una disputa de procedimiento, no un estudio que mida el tiempo perdido.

RFC 4897 cambió el tratamiento de las referencias normativas a documentos Standards Track y BCP ya publicados, pero de menor madurez. En vez de retener el documento nuevo hasta que el citado avanzara, se podía añadir una nota: el documento objetivo podía ser menos estable y se podía explicar por qué la dependencia era adecuada. La IESG conservaba la facultad de establecer criterios que exigieran una demora, y la comunidad podía presentar objeciones durante el ciclo de vida del texto. Para los documentos fuera de Standards Track seguía rigiendo el procedimiento de RFC 3967.

RFC 4897 también decía que hacer avanzar el documento objetivo continuaba siendo preferible cuando correspondía; “anotar y seguir” no pasó a ser una regla universal.

En 2017, RFC 8067 volvió a ajustar el aviso. Identificar expresamente una referencia descendente en el mensaje de última llamada pasó a ser muy recomendable, pero no obligatorio. El director de área responsable aún debía buscar esas referencias. Si una aparecía durante la última llamada o la revisión de la IESG, esta decidiría si convenía repetir la consulta. No repetirla no cambiaba la madurez del documento citado, y un uso futuro seguiría sujeto al procedimiento. La omisión debía quedar anotada en Datatracker.

Leídas juntas, las tres BCP 97 muestran cómo cambió la carga institucional. RFC 3967 exponía la diferencia ante la comunidad antes de que la IESG decidiera. RFC 4897 permitió que algunas dependencias avanzaran con una advertencia explícita en vez de esperar siempre una promoción de estado. RFC 8067 dio a la IESG margen para decidir si una referencia no detectada exigía otra consulta, manteniendo visible su madurez y dejando constancia del criterio. La evolución fue desde una demora principalmente procedimental hacia una distribución más explícita de transparencia, revisión, anotación y responsabilidad.

Esto no demuestra que las publicaciones fueran más rápidas en la práctica, que mejorara la seguridad ni con qué frecuencia se utilizó la excepción. Los RFC establecen reglas y exponen los motivos de sus autores, pero no ofrecen una serie comparativa de resultados. La conclusión histórica es más acotada: un sistema de estándares puede reconocer que las dependencias y el estado de los documentos no siempre avanzan a la vez, y aun así impedir que una referencia adquiera en silencio una autoridad que no le corresponde.

Fuentes: RFC 2026, RFC 3967, RFC 4897, RFC 8067, RFC 7841.