Resumen

  • draft-ietf-opsawg-veloce-yang-00 quiere que la publicación apunte a un tag o commit concreto, nunca al HEAD cambiante. Esa referencia prueba identidad del contenido; un merge, una issue cerrada o una CI verde no prueban por sí solos el consenso del grupo.
  • La cadena continúa después del RFC: archivo de decisiones, custodia del release, module-set real declarado por YANG Library, operaciones representativas y efecto observado sobre el servicio.

Hay dos maneras de perder el rastro de una norma. La evidente es no saber qué versión se utilizó. La más sutil es saber exactamente qué commit se utilizó y, aun así, no poder demostrar por qué tenía autoridad.

VELOCE intenta resolver la primera sin caer en la segunda. El borrador draft-ietf-opsawg-veloce-yang-00 plantea separar la prosa de un documento IETF del módulo YANG. La explicación del modelo, las consideraciones de seguridad y operación, las referencias y las acciones de IANA seguirían en el documento. El módulo viviría en un repositorio de código fuente, donde podría revisarse como diff, validarse con herramientas y mantenerse de forma incremental.

La motivación es sólida. YANG no es sólo texto para leer. Es una fuente que importan herramientas, servidores y clientes. Puede depender de otros módulos, features, deviations y ficheros SID. Una corrección pequeña no siempre justifica reabrir una gran pieza de prosa, y una revisión humana se beneficia de los resultados de parseadores y validadores.

El documento congelado es un Internet-Draft activo de OPSAWG, fechado el 25 de agosto de 2026. Su cabecera declara una intención Experimental; el resumen de Datatracker no muestra un estado RFC previsto. El historial sólo contiene la revisión 00. No es un RFC, una prueba terminada ni evidencia de adopción. Sus metas temporales—dos años para un módulo nuevo y uno para un -bis incremental—son parte del experimento propuesto.

La regla central evita una referencia ambigua. El módulo no debe insertarse en el documento; éste debe enlazar una versión etiquetada o un hash de commit, no la cabeza de una rama. El objetivo es que el contenido vigente en el momento de publicación permanezca recuperable y verificable.

Un commit es un recibo de identidad mucho mejor que main. Permite que autores, YANG Doctors, implementadores y auditores hablen del mismo objeto. Pero esa precisión no amplía el significado del recibo. El tag fija bytes; no fija consenso.

RFC 8874 afirma que el trabajo realizado en GitHub no tiene estatus especial. Su resultado puede ser aceptado, rechazado o modificado por el grupo de trabajo. También advierte que la copia del repositorio no tiene que reflejar perfectamente el consenso en todo momento, porque los editores necesitan margen para mantener el documento.

La interfaz puede ocultar esa distancia. Un pull request fusionado parece una decisión binaria. Una etiqueta llamada has-consensus parece llevar la conclusión en el nombre. Un check verde parece cerrar la discusión. Sin embargo, todos son estados administrados por personas con permisos concretos.

El consenso aproximado pertenece a otro plano. RFC 8874 exige confirmar las decisiones de consenso mediante la lista de correo y asigna a los presidentes la evaluación final. RFC 2418 aclara que no es una votación porcentual y que una decisión de una reunión debe revisarse en la lista. La actividad del repositorio puede informar ese proceso, pero no sustituir su alcance.

Por tanto, un merge legítimo no equivale necesariamente a una decisión del grupo. Los editores pueden fusionar cambios dentro de su discreción; un presidente puede pedir que se espere cuando el asunto afecta al diseño o la interoperabilidad. El recibo completo debe unir el problema, la resolución, la determinación del presidente y el commit exacto que la implementa.

Esa unión también protege a los editores. Sin ella, una modificación editorial puede ser interpretada después como mandato técnico, o una decisión real puede quedar representada por un commit distinto al que el grupo discutió.

La integración continua aporta una prueba diferente. RFC 8874 contempla construir documentos, validar lenguajes formales y ejecutar pruebas. VELOCE recomienda validación YANG y un entorno contenedorizado para reproducirla localmente.

Una CI verde demuestra que un conjunto definido de controles pasó sobre entradas definidas. Su alcance depende de la versión del validador, los módulos importados, las features activas, la configuración, la imagen del contenedor y el corpus de pruebas. No demuestra que se hayan escrito todas las pruebas necesarias ni que dos implementaciones vayan a ejecutar la semántica de la misma forma.

La respuesta correcta no es abandonar la CI, sino acompañar cada resultado con su denominador. Un manifiesto reproducible debe decir qué se probó, con qué herramientas, dependencias y excepciones.

La publicación agrega autoridad normativa sin ejecutar el código. El enlace exacto propuesto por VELOCE permitiría que el objeto revisado y el objeto nombrado por el RFC fueran el mismo. Eso es una mejora. Pero un RFC no construye por sí solo el paquete del proveedor ni activa el módulo en un datastore.

Entre ambos puntos están la custodia del repositorio, el release, la firma, la selección de dependencias, la integración del fabricante, la imagen del sistema, el despliegue y la configuración local. Cualquier salto no documentado puede romper la identidad que el tag había establecido.

La custodia tampoco se reduce a guardar Git. RFC 8874 explica que los objetos distribuidos sobreviven mejor que las discusiones de issues, reviews, pull requests o wiki. Una caída del servicio o unas credenciales privilegiadas comprometidas siguen siendo riesgos. RFC 8875 complementa las obligaciones de administración y copia de seguridad.

Conservar el código y perder la conversación que justificó su aceptación deja una norma arqueológicamente visible pero institucionalmente incompleta.

La verificación de ejecución empieza en el servidor. RFC 8525 define YANG Library para que un servidor comunique los module-sets ligados a sus datastores, con revisiones, features y deviations. Esa lectura puede revelar que el equipo no ejecuta el contexto que el tag publicado describe.

Incluso una coincidencia exacta no cierra la cadena. YANG Library es una afirmación del servidor sobre su esquema. Todavía hacen falta operaciones NETCONF o RESTCONF representativas, lectura posterior del estado y observación independiente del servicio. Identidad del esquema, aceptación del protocolo y efecto operativo son tres hechos distintos.

La primacía del código en funcionamiento, como lente, mantiene el orden de esas pruebas. No niega el valor de la especificación. Impide que un símbolo del repositorio sea tratado como resultado físico. La etiqueta pertenece al nivel del contenido; el consenso, al nivel de decisión; el RFC, al nivel normativo; el comportamiento, al sistema que opera.

La especificación inicial mínima ofrece una ruta práctica. El proceso común debe fijar las uniones necesarias: contenido exacto, validación reproducible, decisión trazable y referencia inmutable. Las herramientas y las cadenas de entrega pueden seguir siendo locales. La adopción voluntaria y la interoperabilidad demostrarán después cuánto valor sobrevivió fuera del repositorio original.

El riesgo político no está en usar GitHub, sino en confundir participación visible con representación. Quienes siguen cada issue son una muestra seleccionada. Otros expertos permanecen en la lista de correo. RFC 8874 ya reconoce ese sesgo y exige reconectar los espacios.

VELOCE será una buena experiencia si consigue velocidad sin transferir autoridad al indicador más cómodo. Cuando alguien diga que el módulo está “terminado”, la pregunta profesional será: ¿terminaron los bytes, la decisión, la publicación o el despliegue?

Ningún tag responde a las cuatro preguntas.

Fuentes