Summary

  • Un Internet-Draft individual del ámbito ONSEN separa la sintaxis YANG de la semántica de servicio: comportamiento del ciclo de vida, validez, duración y retroalimentación. La revisión -01 expiró el 19 de agosto de 2026 y no es adopción del WG ni consenso IETF.
  • Pedido aceptado, configuración pretendida, configuración aplicada, salud observada y cierre comercial son afirmaciones diferentes. El éxito local de una capa no demuestra que todas entiendan igual «activo», «caducado», «revertido» o «cerrado».
  • Daniel Kade propone un recibo semántico de servicio que une intención exacta, vocabulario de estados, tiempo, descomposición, transformaciones, pruebas, autoridad y cierre. Es orientación editorial, no una exigencia de ONSEN.

El reloj sólo hace caducar una descripción

No hace falta un atacante. Basta un servicio compuesto administrado por sistemas competentes. El cliente solicita capacidad elevada entre sedes durante un intervalo. El sistema comercial conserva el pedido; el orquestador lo convierte en servicios de red; los controladores producen configuraciones por segmento; la telemetría observa el resultado.

Al llegar la hora final, «completo» puede significar que cesa la facturación. «Caducado» puede impedir renovar. «Retirada iniciada» puede indicar sólo que se emitió una orden. «Activo» puede describir una configuración todavía aplicada. Una medida anterior puede mantener verde la salud calculada. Son verdades locales, no sinónimos.

El espejo de políticas aparece cuando un panel las reduce a una sola etiqueta. La capa que actualiza primero obtiene, sin mandato explícito, el poder de definir el servicio entero. YANG puede precisar cada campo, pero un esquema no designa por sí solo qué transición gobierna a las demás.

Qué afirma —y qué no— el borrador

draft-xie-onsen-problem-statement-01 llama semántica de servicio al sentido operativo del ciclo de vida, la validez, la duración y el feedback, no a la sintaxis YANG. Explica que API derivadas de modelos semejantes pueden diferir entre proveedores y despliegues y obligar a crear integraciones específicas.

El ejemplo DTS-I es un traslado temporal de gran cantidad de datos, con alto ancho de banda, tiempo previsible y coordinación entre dominios heterogéneos. El pedido incluye inicio, fin y capacidad. La entrega puede atravesar acceso, VPN y salida de centro de datos, además de BSS, orquestador y controladores. Una intención se convierte así en varios objetos con relojes distintos.

El texto identifica ciclos fragmentados de instanciación, monitorización, diagnóstico, modificación y retirada. Señala que suelen faltar expresiones nativas para activación, duración, expiración o rollback, y que métricas parecidas pueden usar definiciones, unidades, ámbitos o frecuencias diferentes. También advierte que una abstracción orientada a configuración puede no demostrar que la conducta pedida fue aplicada y sigue vigente.

La revisión se publicó el 15 de febrero de 2026 y declara expiración el 19 de agosto. El Datatracker consultado aún la etiqueta como borrador individual activo, pero carece de posición formal en el proceso IETF. Las secciones operativa y de seguridad permanecen inconclusas, y el documento declara que no propone una solución concreta.

ONSEN sí es un Working Group activo con carta aprobada. Su ámbito incluye actualizar abstracciones y definir la interfaz entre servicios YANG y OSS/BSS. Esa carta autoriza trabajo futuro; no convierte este borrador individual en texto adoptado.

La misma forma no es el mismo contrato de estado

RFC 8969 separa modelos de servicio, red y dispositivo y describe cómo baja la intención y sube el estado. El marco es un RFC informativo de consenso IETF, no una garantía de que cada implementación use la misma máquina de estados.

RFC 8342 distingue configuración pretendida, aplicada y estado del sistema. Transformaciones, recursos ausentes, demora e interacción con protocolos pueden separarlas y darles vidas distintas. Un commit correcto no prueba todavía el resultado prometido.

RFC 9417 dice que una configuración aplicada no implica que el servicio funcione como se esperaba. Su grafo de aseguramiento relaciona instancias, subservicios, salud y síntomas; RFC 9418 ofrece los módulos correspondientes. Esa arquitectura descubre brechas, pero necesita contexto externo para saber cuándo termina el pedido o quién puede cerrarlo.

RFC 8299 modela el servicio L3VPN visto por el cliente y RFC 9182 la red vista por el operador. La relación muestra por qué mapear campos no basta: hace falta identificar qué transición inferior satisface cuál obligación superior. RFC 9834 mantiene separados estado administrativo y operativo y recomienda considerar ambos.

Seis luces verdes no dicen lo mismo

Aceptación significa que una frontera recibió una solicitud admisible. Validación cubre restricciones conocidas allí. Commit registra una transacción. Estado pretendido dice qué busca aplicar el sistema. Estado aplicado dice qué usa. Salud observada depende de métricas, regla, alcance y momento.

El cierre comercial puede detener cobro u obligación. El cierre de recursos debe comprobar que túneles, direcciones, credenciales y suscripciones desaparecieron. «Pedido cerrado» no libera por magia esos recursos.

El recibo semántico de servicio

Daniel Kade propone un recibo semántico de servicio para cada transición material. No impone una terminología universal; documenta el paso entre terminologías.

Primero fija el hash del pedido y la intención, revisiones de modelos y módulos, funciones activas, desviaciones y transición previa. Después registra objetivo de activación, duración, expiración, zona horaria, reloj, gracia y diferencia entre hora del evento y hora de observación.

La descomposición enlaza servicio de cliente, instancias de red y dispositivos mediante identificadores estables. Cada adaptador o transformación queda versionado. Convertir «finalizar transferencia antes de las 18:00» en «reservar ancho de banda hasta las 18:00» pasa a ser una decisión visible.

La evidencia conserva tiempos de aceptación, validación, commit, pretendido, aplicado y observado, además de estado administrativo, operacional, unidades, alcance, frescura y síntomas. El recibo mantiene el desacuerdo. La sección de autoridad indica quién puede activar, modificar, cancelar, reintentar, compensar, revertir y cerrar; puede ser un rol o automatización acotada.

El cierre enumera recursos liberados, configuración remanente, medidas tardías y cese de facturación. El recibo también expira: una alineación antigua no certifica una época nueva.

RFC 9968 conserva el taller IAB NEMOPS y documenta fragmentación, observabilidad, modelado de servicio, mapeo y verificación. Es un informe informativo. Aclara que las opiniones de participantes no son necesariamente posiciones del IAB y que el relato no siempre expresa consenso. Sirve como evidencia del debate, no como mandato para esta propuesta.

Un tiempo exacto puede ejecutar una regla ambigua

Dos sistemas pueden leer correctamente el mismo timestamp y actuar de forma contraria. Para uno, el final es el último instante de uso; para otro, el primero en que puede empezar el desmontaje. Uno permite terminar flujos abiertos durante una gracia; otro corta todo en la frontera. Coincide el dato, no su institución temporal.

El recibo añade a inicio y fin la inclusión de la frontera, zona horaria, reloj, tolerancia, condición de renovación y destino de una activación tardía. Separa hora del evento, de la observación y del procesamiento. Un mensaje demorado altera el orden de llegada, no la historia del hecho.

También debe decidir qué significa reintentar. Heredar la ventana antigua puede crear un servicio casi vencido; reiniciar la duración sin autorización amplía el compromiso. Ninguna opción debe esconderse bajo una operación técnicamente idempotente.

Un servicio compuesto necesita estados componentes

En DTS-I, acceso, VPN y salida del centro de datos pueden avanzar por separado. Un active agregado no explica si están aplicados todos los segmentos, si basta el camino mínimo o si cayó una pieza redundante. Un failed tampoco identifica lo que ya funcionó ni lo que necesita compensación.

El recibo conserva cada componente y la regla de agregación: éxito total o parcial, elementos críticos, consecuencia de la degradación y remanente que impide cerrar. La regla lleva versión, porque modificarla cambia la conclusión producida por la misma telemetría.

En una frontera entre operadores no hace falta publicar topología o contratos privados. Puede exponerse compromiso acotado, época, resultado e interfaz responsable, con una referencia protegida al detalle. La confidencialidad restringe el contenido; no transforma lo desconocido en éxito.

Rollback no es commit en sentido contrario

Eliminar configuración nueva no restaura necesariamente el servicio anterior. La capacidad puede haberse reasignado, una credencial revocado, datos transferidos o sistemas externos haber actuado tras la notificación. Un controlador puede recuperar su estado sin devolver BSS, aseguramiento y dominio vecino a la época previa.

El recibo distingue restauración técnica, compensación comercial y corrección de evidencia. La primera enumera estados recuperables; la segunda asigna los efectos irreversibles; la tercera mantiene la decisión original y añade la rectificación. Sólo así «rollback completado» tiene un alcance comprobable.

Las fuentes no prueban un incidente de un operador, un plazo universal ni una arquitectura obligatoria. La conclusión es acotada: estructuras compatibles pueden transportar significados institucionales diferentes. La automatización sólo es gobernable si preserva la verdad local y prueba sus traducciones.

Fuentes

  1. https://heng.lu/the-policy-mirror/
  2. https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
  3. https://heng.lu/on-why-btw-media-exists-and-why-reality-not-advocacy-is-the-product/
  4. https://datatracker.ietf.org/doc/html/draft-xie-onsen-problem-statement-01
  5. https://datatracker.ietf.org/doc/draft-xie-onsen-problem-statement/
  6. https://datatracker.ietf.org/doc/draft-xie-onsen-problem-statement/history/
  7. https://datatracker.ietf.org/group/onsen/about/
  8. https://www.rfc-editor.org/info/rfc9968/
  9. https://www.rfc-editor.org/rfc/rfc8969.html
  10. https://www.rfc-editor.org/rfc/rfc8342.html
  11. https://www.rfc-editor.org/rfc/rfc9417.html
  12. https://www.rfc-editor.org/rfc/rfc9418.html
  13. https://www.rfc-editor.org/rfc/rfc8299.html
  14. https://www.rfc-editor.org/rfc/rfc9182.html
  15. https://www.rfc-editor.org/rfc/rfc9834.html