Resumen

  • BBF comunicó que WT-477i2 dependía de los módulos del modelo BGP de IETF y pidió información sobre una fecha objetivo. Con ello estableció una dependencia y una solicitud, no un compromiso de publicación de IETF.
  • IDR respondió el 1 de agosto que el borrador estaba en Working Group Last Call y distinguió revisiones posteriores de Area Director, IETF-wide Last Call e IESG antes de una cola del RFC Editor.
  • El 21 de agosto el Area Director responsable dijo que la WGLC seguía abierta y que el silencio no demostraba que el documento estuviera listo para publicar.
  • La ficha de la versión 21 sigue describiendo un Internet-Draft; muestra “Waiting for Implementation” en el grupo, “I-D Exists” en IESG y ninguna fecha de teleconferencia.
  • Un recibo de dependencia debe enlazar versiones, revisión y disposición, sin presentar una necesidad de calendario como el resultado de un estándar.

BBF documentó una dependencia, no una fecha concedida

La liaison de seguimiento del BBF identifica con precisión su objeto. Dice que los modelos YANG desarrollados en WT-477i2 dependen de ietf-bgp y de los módulos asociados enumerados en draft-ietf-idr-bgp-model-18. Aporta un borrador para consideración de IDR, explica que su propio documento se acercaba a la terminación y pregunta cuándo podría publicarse el modelo BGP de IETF.

Eso no es una pretensión de gobernar IDR. Es una forma de dejar constancia de que dos textos técnicos tienen una relación. También tiene límites claros: BBF no anuncia una decisión de IETF, no reserva un RFC y no prueba que los módulos estén implementados ni que WT-477i2 haya llegado a producción. La fuente sólo permite afirmar qué documento externo invoca la dependencia y qué información solicita.

La coordinación entre organismos suele necesitar justamente esta transparencia. Duplicar un modelo sólo para evitar la incertidumbre de otro proceso puede fragmentar el vocabulario técnico. Pero compartir una dependencia no transforma al solicitante en la instancia que determina la madurez del texto. RFC 2418 pide considerar trabajo relevante de otros organismos y contar con una liaison adecuada cuando se superpone; no convierte ese requisito en una delegación de las decisiones del grupo.

La respuesta de IDR separa participación y disposición

La respuesta de IDR sitúa el borrador en Working Group Last Call. Tras el cierre de esa llamada, enumera revisión del Area Director, Last Call de todo IETF y revisión integral del IESG antes de entrar en la cola de publicación del RFC Editor. El texto recomienda a personas del BBF participar en la lista IDR con comentarios técnicos, discusión y expresiones de apoyo.

No hay contradicción entre esa invitación y la autonomía del proceso. Un participante de BBF puede señalar una dependencia o revisar un módulo. Su participación se convierte en evidencia técnica dentro de la vía pública correspondiente, no en un reloj que salta los demás controles. Del mismo modo, que IDR responda no convierte una fecha solicitada en una fecha prometida.

La actualización de 21 de agosto es todavía más concreta. El Area Director dice que la versión 21 ya se publicó, pero que WGLC continúa abierta por el tamaño del documento y el período de reuniones y vacaciones. Al valorar consenso buscará apoyo positivo y revisiones terminadas; el silencio no equivale a que el documento pueda publicarse. El mensaje además identifica la separación de funciones: los tres chairs de IDR son coautores, por lo que el Area Director llamará el consenso para esa WGLC, con un shepherd determinado para la revisión.

No se trata de convertir una nota de lista en una conclusión definitiva. Se trata de leerla por lo que es: un estado presente y la regla de evidencia que gobernará la siguiente decisión. Una versión subida, un comentario, apoyo explícito y una disposición de consenso son hechos diferentes.

El Datatracker no muestra un RFC donde aún hay un borrador

La ficha de draft-ietf-idr-bgp-model-21 fecha la versión el 14 de agosto de 2026, la llama Internet-Draft y advierte que estos documentos de trabajo pueden actualizarse, reemplazarse u obsoletarse; deben citarse como trabajo en curso. Su estado WG es “Waiting for Implementation”; el estado IESG es “I-D Exists”, sin teleconferencia prevista.

La carta de IDR hace de BGP el objetivo prioritario de desarrollo y mantenimiento del grupo para IPv4 e IPv6. Esa carta explica para qué existe el grupo. No resuelve el estado de todos sus borradores. RFC 2026 describe los niveles de madurez y exige una acción específica del IESG para mover una especificación a Proposed Standard; además, la experiencia puede llevar a cambios o retirada antes de un avance posterior.

Por ello una cronología responsable necesita columnas, no un único semáforo. La primera columna registra el documento BBF y la versión IETF de la que depende. La segunda registra apertura, continuación o cierre de WGLC. La tercera registra revisiones y disposición de consenso. La cuarta conserva revisión de Area Director, Last Call de IETF e IESG. La quinta identifica entrada en cola y RFC final. Una columna no certifica las demás.

Una cadena pública puede ser precisa sin inventar plazos

El recibo propuesto es sencillo: versión WT-477i2 + versión IETF citada + fecha de solicitud + estado WGLC + revisión/conclusión de consenso + estados IETF/IESG + cola RFC Editor + RFC final. Cada elemento debe llevar una fuente y una advertencia sobre su alcance. La entrada de BBF no prueba aprobación. La WGLC abierta no prueba fracaso ni una duración futura. La entrada en una cola no prueba publicación. Un RFC final tampoco probaría adopción, interoperabilidad o despliegue de un producto BBF.

Las fuentes públicas no permiten medir implementación de BGP, soporte de proveedores, uso por operadores o impacto comercial. Tampoco justifican imputar una demora, conflicto o incumplimiento. Mantener esa incertidumbre no debilita el artículo: impide que una línea de calendario hable en nombre de una revisión que aún conserva dueño y evidencia propios.

Fuentes