Resumen

  • draft-ietf-netmod-yang-versioning-reqs-14 enumera cinco familias de requisitos y declara que no estudia ni respalda una solución concreta.
  • La existencia del borrador, una etiqueta BC/NBC o una afirmación de cobertura indican intención; no demuestran clientes protegidos, nodos disponibles, migración sin pérdida ni despliegue seguro.

Una comisión recibe una matriz de aceptación. En la columna izquierda aparecen cinco grupos de requisitos; en la derecha, cinco referencias a documentos. No hay versiones de cliente, hashes de módulos, inventario de deviations, datos convertidos ni resultado de rollback. Aun así, el informe dice “cumplido”.

Ese salto no lo autoriza la revisión 14. El borrador, fechado el 20 de julio de 2026, se presenta como Informational. Datatracker lo muestra activo en NETMOD, con estados WG Document e I-D Exists. Su resumen deja claro que define el problema y las obligaciones de una solución, pero no considera ni avala una.

El cambio incompatible tiene varias superficies

El primer grupo exige cambiar un módulo de forma NBC sin renombrar a la vez todo el grafo dependiente. También protege a los clientes que sólo usan nodos no modificados o modificados de forma compatible, pide una importación menos abierta que “cualquier revisión” y menos rígida que una revisión exacta, y exige expresar dónde ocurrió la incompatibilidad.

Cada punto necesita su propio recibo. El cierre de imports e includes demuestra qué artefactos se resolvieron. Una comparación documentada evalúa la clasificación. Un esquema efectivo incorpora features y deviations. Sólo la ejecución muestra cómo responde un cliente real. Una marca NBC no sustituye esas capas.

El segundo grupo quiere que personas y herramientas distingan BC de NBC. El propio contexto advierte que la semántica puede cambiar aunque las instrucciones YANG visibles no cambien. Por eso la aceptación debe conservar bytes anteriores y posteriores, reglas de comparación, contexto de compilación, decisión humana y advertencias. Que una herramienta lea la categoría no significa que la categoría sea correcta.

La compatibilidad antigua pertenece a una pareja concreta

El tercer grupo pide mecanismos para clientes existentes y para quienes esperan una versión antigua tras un cambio incompatible. La prueba mínima es bilateral: cliente antiguo con servidor nuevo y cliente nuevo con servidor antiguo. Debe abarcar lectura, escritura, RPC, notificaciones, errores y autorización con binarios y conjuntos de módulos identificados.

El cuarto grupo aborda deprecated y obsolete. El cliente debe saber si un nodo deprecated está implementado, conocer la alternativa y recibir aviso antes de su retirada mientras la definición todavía funciona. La publicidad de esa política reduce incertidumbre, pero el comportamiento del nodo, las deviations y la persistencia tras reinicio siguen pendientes de observación.

El quinto grupo obliga a explicar el paso desde YANG 1.0/1.1 y el efecto sobre datos de instancia. RFC 9195 puede vincular datos a un content-schema, pero no promete que otro esquema conserve su significado. El recibo de migración cuenta campos renombrados, eliminados, sintetizados, predeterminados y rechazados; verifica invariantes y lectura tras rollback.

Los borradores vecinos pueden proponer piezas para esta matriz. No obtienen una aprobación colectiva por compartir grupo de trabajo. La revisión 14 es más útil como lista de deudas verificables que como sello de madurez.

Fuentes primarias

El paquete oficial incluye la revisión 14, Datatracker, su historial, la lista NETMOD y RFC 2119, RFC 6020, RFC 7950, RFC 8049, RFC 8299, RFC 8525 y RFC 9195.