Resumen

  • La IESG anunció el 18 de agosto de 2026 la aprobación de draft-ietf-netmod-yang-module-versioning-17 como Proposed Standard. El texto permite documentar evoluciones no compatibles, incorpora recommended-min-date a los imports y expone el tratamiento de nodos deprecados y obsoletos.
  • Su ejemplo ramificado demuestra el límite: una revisión del 1 de mayo satisface un mínimo del 1 de abril, aunque puede no contener lo que introdujo la rama del 1 de abril. El calendario ordena artefactos; no prueba descendencia ni aptitud para el destino.

El filtro de fecha eligió a la hermana

La apertura es una construcción analítica basada en el borrador, no un incidente. Tras una revisión común del 1 de febrero, una rama pasa por el 1 de marzo hasta el 1 de mayo; la otra pasa por el 1 de abril hasta el 1 de junio.

Si el consumidor necesita algo añadido el 1 de abril, puede recomendar esa fecha. La regla acepta cualquier revisión igual o posterior, de modo que el 1 de mayo cumple. Pero ese artefacto está en la otra rama.

El propio documento avisa que puede no contener lo deseado desde el 1 de abril y concluye que recommended-min-date funciona mejor en historias cronológicas lineales. “Posterior” describe el tiempo; “descendiente” describe un camino.

La aprobación permite ver el borde incompatible

La versión 17 de “Updated YANG Module Revision Handling” procede de NETMOD, permanece como Internet-Draft en la cola del RFC Editor y tiene estado de implementación desconocido.

RFC 7950 exigía actualizaciones estrictamente compatibles. El nuevo trabajo admite que una corrección, una retirada tras transición o la evolución de material inestable puede requerir una ruptura. Sigue recomendando reducirlas al mínimo.

Cuando una revisión no es compatible con su progenitora debe incluir rev:non-backwards-compatible. El indicador hace auditable ese borde. No certifica, sin embargo, la relación de la revisión con todos los puntos de un historial ramificado.

Identidad inmutable no equivale a genealogía

Nombre y fecha identifican una definición inmutable dentro del historial. El borrador afirma expresamente que ni fecha ni identificador de versión bastan para determinar la ascendencia; hay que consultar el historial.

Dos revisiones pueden incluso tener el mismo cuerpo y diferir solo en su historia si el mismo cambio se aplicó en varias ramas. La igualdad de contenido tampoco reconstruye el camino.

Con submódulos, un include sin fecha exacta deja indeterminado qué revisión se usó. YANG Library, una fecha de inclusión exacta o un inventario de paquete debe cerrar esa prueba.

La recomendación evita una fijación excesiva

recommended-min-date admite cero o una aparición por import. Añadirla, cambiarla o retirarla se clasifica como compatible. Un analizador que no la entienda sigue las reglas normales de import de RFC 7950.

El texto la prefiere a fijar una fecha exacta cuando basta una cota, porque un pin rígido impide aprovechar cambios compatibles posteriores. La flexibilidad es útil, pero desplaza la verificación de idoneidad a otro control.

La cota no pregunta si la revisión seleccionada desciende de la requerida, conserva un nodo, recibió el cambio de la rama hermana o mantiene las mismas restricciones. Debe abrir la selección de candidatos, no cerrar la admisión.

Recortar el historial también recorta evidencia

Los mantenedores pueden retirar ciertas entradas antiguas, pero nunca la más nueva y nunca de manera que los marcadores incompatibles restantes falseen la relación con sus predecesoras conservadas.

El borrador desaconseja la poda porque puede ocultar cuándo apareció una ruptura. Si una organización basa la admisión en ascendencia, necesita preservar las aristas mediante historial, huellas, repositorios e inventarios firmados.

Esta es una consecuencia institucional: una limpieza documental aparentemente inocua puede borrar la prueba con la que la automatización justificaba una decisión de producción.

El estado de los nodos vive en el servidor

ietf-yang-library-status añade deprecated-nodes-implemented y obsolete-nodes-absent. El primero en verdadero significa que los nodos deprecados se implementan como actuales salvo desviación; el segundo en verdadero significa que no se implementa ningún nodo obsoleto.

Falso es el valor predeterminado de ambos y deja el comportamiento sin especificar. El texto recomienda publicar ambos como verdaderos. De lo contrario, el cliente no debe deducir compatibilidad solo de los marcadores de revisión.

La transición aconsejada es actual, deprecado y después obsoleto. Los clientes deben abandonar a tiempo lo deprecado y no pueden seguir usando lo obsoleto. Una fecha correcta no prueba qué etapa expone la meta concreta.

La admisión requiere grafo, esquema y ejecución

El controlador debe registrar la capacidad, la revisión que la introdujo, el artefacto resuelto y su huella, progenitores, rama, rupturas, submódulos y la instantánea de YANG Library con funciones, desviaciones y estado de nodos.

Luego compila y compara el esquema efectivo, valida datos y prueba cliente y servidor. Una ruptura puede ampliar un rango fuera de las suposiciones del cliente, cambiar un valor por defecto o exigir ajustes en NACM.

Una rama equivocada es fallo de linaje; un estado ambiguo es laguna de descubrimiento; un árbol distinto es fallo de esquema; una consecuencia real es fallo de implementación; una autorización ausente es fallo de gobierno.

La fecha reduce la búsqueda. La descendencia, el objetivo probado y el dueño responsable deciden la producción.

Fuentes