Resumen

  • RFC 9675 sitúa la decisión operativa junto al dispositivo: el Manager expresa política, mientras el Agent autoriza y ejecuta Controls con datos locales.
  • Un Control no devuelve un código de resultado sincrónico, y los informes pueden acumularse, caducar, sustituirse, combinar varias acciones o llegar fuera de orden.
  • La prueba defendible conserva por separado intención, custodia, recepción, autorización, precondiciones frescas, ejecución, recuperación, generación del informe, cola, conciliación y observación actual.

La orden válida que llegó demasiado tarde

Imaginemos una estación remota con una ventana de operación que termina a las 14:00. El centro emite a las 13:40 una política para aumentar una carga. El mensaje queda retenido en una red de almacenamiento y reenvío. A las 14:05, sin noticias del centro y ante una lectura local fuera de rango, el agente entra en modo seguro. La orden llega a las 17:20: está íntegra, procede del gestor autorizado y conserva su firma. Sin embargo, el objetivo para el que fue creada ya no existe.

Una consola convencional puede mostrar tres éxitos: enviado, entregado y autenticado. Ninguno responde a la pregunta decisiva: ¿debía ejecutarse todavía? Si se ejecutó, tampoco responde a otra: ¿qué estado quedó después de que las reglas locales actuaran de nuevo?

El ejemplo es hipotético. No atribuye un fallo a ningún sistema real. Sirve para mostrar el cambio de modelo que introduce RFC 9675. En redes con demoras extremas, una orden puede sobrevivir a la situación que le dio sentido. La arquitectura necesita autonomía local; la gobernanza necesita recibos que no confundan supervivencia del mensaje con vigencia de la decisión.

Lo que RFC 9675 especifica, y lo que deja abierto

RFC 9675 fue publicado en noviembre de 2024 como documento Informational del flujo IETF, aprobado por el IESG y representativo del consenso de la comunidad IETF. No es una especificación de Standards Track. Describe la Delay-Tolerant Networking Management Architecture, DTNMA, como arquitectura lógica e informativa.

Eso significa que identifica componentes, conductas y casos de uso, pero no entrega un diseño funcional completo. No prescribe interfaces exhaustivas ni obliga a usar Bundle Protocol. BPv7 puede encajar en un entorno intermitente, pero la selección de transporte, nombres, direccionamiento, enrutamiento y seguridad de comunicaciones queda fuera del alcance del documento.

La cautela evita convertir un esquema en prueba de despliegue. Citar RFC 9675 no demuestra que un dispositivo implemente DTNMA, que un mensaje haya llegado, que una acción estuviera autorizada ni que el resultado deseado exista ahora. La adopción sólo se vuelve observable en agentes, gestores, modelos, reglas, Controls, colas e historiales reales.

La premisa sí es concreta. Hay redes sin intercambio extremo a extremo oportuno, con enlaces unidireccionales, equipos dormidos, capacidad asimétrica y periodos sin DNS, autoridad de certificación u otra infraestructura. Una sesión estable y una ida y vuelta rápida no pueden ser requisitos del control.

Dos operadores, dos superficies de autoridad

El DTNMA Manager cumple el papel de operador remoto. Recibe el objetivo de una aplicación de gestión, lo codifica como política, agrupa mensajes y los dirige hacia los Agents. El DTNMA Agent es el operador local, situado en el dispositivo o junto a él. Recoge y fusiona datos, valida información, autoriza acciones, ejecuta Controls y gestiona errores.

Así aparecen dos niveles. El centro configura al operador local; ese operador actúa sobre el equipo. La orden remota no salta directamente al mundo físico o al estado de una aplicación. Entra en una superficie donde ya hay reglas, límites, observaciones, actualizaciones concurrentes y una política de seguridad.

Incluso con conectividad rápida, todo Control se evalúa y ejecuta localmente. La recepción es un estímulo para la autonomía, no un túnel que permita al centro evitarla. El poder remoto consiste en definir objetivos y capacidades permitidas; el poder local consiste en decidir si las condiciones presentes permiten la acción.

Por eso el registro debe contener ambos lados. Una autoridad puede haber emitido correctamente una política y el Agent puede haberla rechazado correctamente por caducidad, datos obsoletos o conflicto. Un tablero que sólo conserva el último icono convierte una decisión legítima en una aparente avería.

Un Control no es un RPC lento

Un Control es un procedimiento parametrizado que el Agent ejecuta por indicación de un Manager o por selección de una regla local. Una macro ordena varios Controls. RFC 9675 subraya que no existe el concepto de código de retorno: ese código supondría una relación sincrónica entre quien llama y quien responde.

Aumentar el tiempo de espera de un RPC no resuelve el problema. Al comenzar la ejecución pueden haber cambiado las precondiciones. Una macro puede modificar el equipo en su primer paso y fallar en el segundo. El fallo pasa a ser estado del Agent y puede activar recuperación, rollback o transición a modo seguro mucho antes de que el centro reciba un informe.

El recibo útil registra la versión exacta de política, recepción, autorización, valores locales y su frescura, precondiciones, cada paso, cambios competidores y recuperación. La palabra «completado» no basta. Puede describir el final del procedimiento sin demostrar el objetivo, o el final de una macro antes de una regla correctora posterior.

Los informes no forman parejas naturales con las órdenes

Una aplicación puede operar en bucle cerrado o seguir emitiendo política en bucle abierto. En DTNMA, cerrar un bucle puede requerir milisegundos, días o años. Durante ese tiempo, el Agent sigue viviendo en su propia cronología.

Tampoco existe una correspondencia uno a uno entre Control e informe. Un único informe puede resumir el estado final de tres Controls. Una acción puede aparecer en varios informes. La asociación causal puede no estar incluida. La cola puede eliminar un informe antes de transmitirlo.

Un identificador de mensaje prueba qué objeto estuvo bajo custodia, no qué efecto produjo. Un identificador de política nombra la intención, no demuestra que seguía vigente. Un identificador de Control nombra el procedimiento, no los datos usados ni la recuperación posterior.

La conciliación debe enlazar sin fusionar objetivo, codificación, custodia, recepción, autorización, ejecución, observación, informe y resultado posterior. Cuando una pieza representa varias acciones, hay que conservar la relación muchos-a-uno. De lo contrario, la interfaz atribuirá el resumen a la última orden visible y fabricará una causalidad limpia que nunca existió.

La hora de llegada puede invertir la historia

Los informes se generan en función del estado local, con independencia de que haya conexión. Esperan en almacenamiento, viajan por rutas diferentes y pueden ser retransmitidos. RFC 9675 advierte que el Manager no debe inferir significado del orden de recepción.

Cada informe necesita hora de generación, identidad del Agent, esquema, política y contexto suficiente. La hora de entrada en una API es información de transporte, no tiempo de observación. Si los relojes tienen incertidumbre, esa incertidumbre debe mantenerse; imponer un orden total falso no mejora la evidencia.

El almacenamiento añade otro límite. Un informe puede caducar, ser reemplazado por uno más reciente o desaparecer sin transmisión. El silencio puede significar que nada ocurrió, que una regla no informó, que el dato espera en cola, que fue descartado, que faltó autorización, que cambió el destino o que no existe conectividad. La salud no puede deducirse del silencio por descarte.

La fusión local ahorra capacidad y pierde detalle

El Agent puede convertir muestras y contadores en mínimos, máximos, promedios, alarmas o estados compactos. Esa fusión permite operar con poco almacenamiento y contactos breves. También crea un objeto nuevo. El resumen es evidencia acerca de una regla de fusión; no conserva automáticamente todos sus insumos.

Una definición que cambia puede volver incomparables dos informes. Un resumen correcto puede omitir el fallo intermedio que explica una transición segura. RFC 9675 no prohíbe retener datos brutos y reconoce su valor para estudiar interacciones complejas. La organización debe decidir qué observaciones son irremplazables antes de que la presión de almacenamiento decida por ella.

La frescura también es temporal. Un valor puede ser suficientemente reciente cuando una regla lo evalúa, histórico al generarse el informe y obsoleto al llegar al centro. La autenticidad protege procedencia e integridad; no rejuvenece la medición.

Varios Managers convierten la autoridad en historia

RFC 9675 permite relaciones muchos-a-muchos. Un Agent puede aceptar control de ciertos Managers e informar a otros. Distintas particiones pueden presentar autoridades diferentes. La arquitectura contempla autorización fina y la necesidad de resolver conflictos, pero no impone una constitución universal.

Una implementación debe declarar alcance, precedencia, caducidad y regla de seguridad. Al reconectar, debe conservar qué Manager podía hacer qué, qué políticas compitieron y qué regla local prevaleció. El informe que llega primero no debe conferir retroactivamente autoridad a su remitente.

La seguridad tampoco colapsa las capas. La custodia autenticada no prueba autorización del Control. La autorización no prueba precondiciones. La ejecución no prueba que se logró el objetivo. Un informe firmado puede ser íntegro y obsoleto al mismo tiempo.

Una escalera de recibos para el control asíncrono

La cadena comienza con objetivo, alcance, autoridad, versión, tiempo de decisión y caducidad. Sigue con la codificación exacta del Manager, destinatarios, agregación y custodia. En el Agent registra bytes recibidos, autorización, entradas frescas, límites y conflictos.

Después conserva cada Control, paso de macro, delta, error, rollback y transición segura. A las observaciones brutas y fusionadas añade origen y frescura. Para los informes registra esquema, generación, Controls contribuyentes, inserción en cola, sustitución, caducidad, eliminación y transmisión. El Manager reconcilia por contexto del evento, no por llegada.

El último peldaño es una observación independiente, nueva y acotada en el tiempo. Sólo ella permite una afirmación de estado actual para una decisión que realmente lo exige. Los peldaños anteriores pueden ser correctos sin llegar hasta éste.

Una arquitectura Informational exige adopción observable

La contribución de RFC 9675 no es prometer omnisciencia remota. Es reconocer que la gestión distribuida no puede depender de ella. La política escrita coordina; el Agent local interpreta bajo condiciones concretas; los Controls cambian algo; los informes proyectan partes de ese cambio; el mundo puede volver a cambiar.

La lente de Heng Lu sobre especificación mínima y capas de realidad ayuda a mantener esas superficies separadas. El texto común puede definir roles y vocabulario mientras cada implementación toma decisiones localizadas sobre transporte, seguridad y recuperación. El running code muestra después qué decisiones se volvieron efectivas.

Para el liderazgo, la disciplina consiste en no rebajar la prueba porque la red sea difícil de observar. La demora hace más valiosas la cronología, la autoridad y la custodia; no menos.

Fuentes