Résumé

  • RFC 9675 confie au gestionnaire distant l’expression de la politique, mais à l’agent présent sur l’équipement l’observation, l’autorisation et l’exécution des Controls.
  • Un Control DTNMA n’a pas de code retour synchrone ; un rapport peut attendre, expirer, remplacer un autre rapport, arriver dans le désordre ou résumer plusieurs actions.
  • Une décision défendable sépare intention, encodage, garde du message, réception, autorisation, données fraîches, exécution, mise en sûreté, génération du rapport, file d’attente, rapprochement et observation actuelle.

Deux enveloppes, une chronologie inversée

Le centre de supervision reçoit d’abord un rapport rassurant : la température est revenue dans la plage prévue. Une heure plus tard arrive une alerte indiquant un dépassement. L’interface classe les messages par heure de réception et conclut à une rechute.

La chronologie locale dit l’inverse. L’alerte a été produite pendant la perte de contact, puis retenue sur un chemin lent. L’agent a appliqué une règle de protection, exécuté plusieurs Controls et généré le rapport de récupération, lequel a emprunté une route plus rapide. Le dernier état observé est arrivé le premier.

Ce scénario est hypothétique, mais le mécanisme est celui que RFC 9675 demande de traiter. Dans un réseau perturbé, les rapports peuvent suivre des chemins différents, attendre une retransmission et parvenir hors ordre. Le gestionnaire ne doit pas déduire la succession des événements de la succession des arrivées.

Cette seule règle renverse une habitude de produit. L’horodatage de l’API n’est pas l’heure de l’état. Le voyant vert n’est pas un présent universel.

Une architecture logique, pas une promesse de produit

RFC 9675, publié en novembre 2024, décrit la Delay-Tolerant Networking Management Architecture. Le document est Informational, issu du flux IETF, approuvé par l’IESG et représentatif du consensus de la communauté IETF. Il n’est pas une spécification Standards Track.

Il décrit une architecture logique : rôles, comportements et cas d’usage. Il ne définit pas une architecture fonctionnelle complète, ni toutes les interfaces entre composants. Il n’impose pas BPv7, même si les bundles sont adaptés aux contacts intermittents. Le transport, le nommage, l’adressage, le routage et la sécurité des communications restent hors de son périmètre.

Ces limites protègent l’analyse contre deux excès. La publication ne démontre aucun déploiement. Et l’adoption d’un vocabulaire DTNMA ne prouve ni livraison de commande, ni autorisation, ni changement d’état.

Le problème traité est plus profond : certaines liaisons sont unidirectionnelles, des équipements dorment, la latence se compte en jours, et un contact peut finir avant un aller-retour. Les services d’infrastructure peuvent être absents. Attendre une session stable et une réponse immédiate revient alors à ne plus gérer l’équipement.

Le gestionnaire prépare ; l’agent décide au contact du réel

Le DTNMA Manager est l’opérateur distant. Il reçoit une politique souhaitée, l’encode, agrège les expressions et prépare leur acheminement. Le DTNMA Agent est l’opérateur local. Il se trouve avec l’équipement, collecte et fusionne les données, valide les informations, applique l’autorisation, gère les erreurs et exécute les actions.

L’architecture comporte donc deux étages. Le premier configure l’opérateur local. Le second fait fonctionner l’équipement par cet opérateur. Une instruction distante ne devient pas directement un mouvement, une configuration ou un état applicatif. Elle rejoint un environnement où des règles, des limites de ressources et des observations locales existent déjà.

Même lorsque la liaison est rapide, le contrôle reste local. La réception d’un Control est un stimulus évalué par l’autonomie de l’agent. La session ayant transporté le message n’est pas maintenue comme condition d’exécution.

L’autonomie n’annule pas l’autorité distante. Elle en fixe la forme. Le centre exprime un objectif ; l’agent le confronte à des faits que le centre ne peut pas connaître à temps. La preuve doit conserver les deux côtés.

Un Control ne renvoie pas « succès »

Un Control est une procédure paramétrée prédéfinie, exécutée par l’agent à la demande d’un gestionnaire ou en réponse à une règle locale. Une macro ordonne plusieurs Controls.

RFC 9675 souligne que le Control ressemble conceptuellement à un RPC, mais ne possède pas de code retour. Un tel code supposerait une relation synchrone entre appelant et appelé. C’est précisément ce que l’architecture ne peut garantir.

Transformer l’action en RPC avec un délai gigantesque ne suffit pas. Au moment de l’exécution, l’objectif peut avoir expiré. Une donnée locale peut être périmée. Une mise à jour concurrente peut être active. Une étape de macro peut échouer après que les précédentes ont modifié le système.

L’échec devient un élément de l’état de l’agent et peut déclencher d’autres règles. Certains échecs exigent un retour arrière ou une mise en sûreté. Le résultat opérationnel est donc une suite locale d’actions et de corrections, pas une valeur booléenne attendant de rentrer au centre.

Le journal utile conserve la version de politique, l’heure de réception, la décision d’autorisation, la fraîcheur des entrées, les préconditions, chaque étape, les conflits, le retour arrière et l’état observé ensuite. « Terminé » sans cette histoire est un résumé sans causalité.

Le rapport n’est pas l’accusé de réception de la commande

La gestion peut être en boucle fermée ou ouverte. Dans le premier cas, une nouvelle action attend un retour ; dans le second, elle ne l’attend pas. Une boucle peut durer quelques millisecondes ou plusieurs années.

Commandes et rapports n’ont pas nécessairement une relation bijective. Un rapport peut décrire l’état final après plusieurs Controls. Un Control peut influencer plusieurs rapports. L’association peut être absente. Un rapport produit peut disparaître de la file avant transmission.

Un identifiant de message prouve quel objet a circulé, non quel état en a résulté. Un identifiant de politique nomme l’intention, non sa pertinence lors de l’arrivée. Un identifiant de Control nomme une procédure, non les données fraîches qu’elle a effectivement utilisées.

Il faut donc relier sans les fusionner l’objectif, l’expression encodée, la chaîne de garde, l’autorisation de l’agent, la trace d’exécution, les observations, le rapport et l’état ultérieur. Un rapport résumant trois Controls doit porter cette relation plusieurs-à-un au lieu de se transformer en réponse imaginaire à la dernière commande visible.

La file d’attente peut supprimer une partie de la mémoire

Les rapports sont produits selon l’état local, indépendamment de la connectivité. Ils attendent éventuellement une fenêtre de contact. Or le stockage est fini. RFC 9675 reconnaît qu’un rapport peut expirer, être remplacé ou être supprimé avant toute transmission.

Le silence ne possède alors aucune signification unique. Il peut indiquer l’absence d’événement, une règle sans rapport, un rapport encore en attente, une expiration, un refus d’autorisation, l’absence de route, un agent hors service ou un gestionnaire incapable de rapprocher les données reçues.

Une politique de conservation est donc aussi une politique de preuve. Quels événements ne peuvent jamais être remplacés ? Quelle pression de stockage justifie une agrégation ? Quel résumé doit conserver les références aux observations brutes ? Qui peut constater qu’une partie de l’histoire a été supprimée ?

Sans réponses explicites, l’architecture continue de fonctionner tandis que l’audit devient impossible.

La fusion locale produit une nouvelle couche de réalité

L’agent peut transformer des compteurs et mesures en produits compacts. Une moyenne, un minimum, un score ou un état final consomme moins de bande passante et peut alimenter les règles locales. Dans un réseau contraint, cette fusion est une fonction opérationnelle, pas un luxe analytique.

Mais le produit fusionné n’est pas la totalité de ses sources. Il dépend d’une règle, d’une version, d’une fenêtre et de données disponibles. Deux résumés de même forme peuvent avoir été calculés différemment. Un résultat exact peut cacher un échec intermédiaire important.

RFC 9675 n’interdit pas de conserver les valeurs brutes. Elles restent utiles pour comprendre les interactions et améliorer les décisions. Le leadership doit choisir avant l’incident quelles observations doivent survivre à la compression.

La fraîcheur complète ce problème. Une règle d’autonomie suppose que ses entrées représentent encore un état actionnable. Une valeur non renouvelée peut faire détecter un stimulus inexistant. L’implémentation doit donc indiquer si une valeur est assez fraîche pour représenter l’état actuel.

Une valeur fraîche lors de l’action peut être historique lors de la génération du rapport et obsolète lors de sa réception. La signature du rapport n’arrête pas le temps.

Plusieurs gestionnaires, plusieurs histoires possibles

La topologie peut exposer l’agent à différents gestionnaires selon les partitions et les contacts. RFC 9675 autorise des associations plusieurs-à-plusieurs et sépare les entités dont l’agent accepte le contrôle de celles auxquelles il envoie ses rapports.

Cette souplesse empêche de supposer un centre toujours disponible. Elle oblige aussi à formaliser la préséance. Deux politiques autorisées peuvent se contredire. Un gestionnaire peut être compétent pour une application et pas pour une autre. Une autorité temporaire peut expirer avant l’arrivée de son message.

L’architecture prévoit des mécanismes d’autorisation et invite à considérer la résolution des conflits, sans imposer une hiérarchie mondiale. La décision est locale, mais elle doit laisser un reçu : cartographie des gestionnaires, portée, version, règle de préséance et résultat.

Sinon, l’autorité réelle revient au gestionnaire dont les messages atteignent le tableau de bord en premier.

La sécurité ne transforme pas un message en résultat

RFC 9675 distingue la sécurité du modèle de données—validité, visibilité et autorisation—de la sécurité de la messagerie et de l’encodage. Les échanges doivent être protégés, mais le mécanisme précis reste hors périmètre.

Une garde authentifiée peut établir l’origine et l’intégrité d’un objet sous une politique donnée. Elle ne prouve pas que l’agent l’a autorisé. Une autorisation ne prouve pas les préconditions. Une exécution ne prouve pas l’objectif final. Un rapport confidentiel peut toujours être ancien, incomplet ou hors ordre.

La bonne architecture de preuve n’attend donc pas une attestation universelle. Elle protège et relie plusieurs reçus bornés.

Une chaîne de preuve adaptée à l’asynchronisme

Le premier reçu fixe l’objectif, sa portée, son auteur, son échéance et sa version. Le second conserve l’encodage et les agents destinataires. La chaîne de garde enregistre le stockage, l’intégrité, l’expiration et le transfert sans appeler cela livraison.

Sur l’agent, il faut conserver réception, autorisation, données fraîches, limites, préconditions et conflit éventuel. Chaque Control et chaque étape de macro produit une trace locale. Le retour arrière et la mise en sûreté appartiennent à la même histoire.

Le rapport ajoute son schéma, son heure de génération, ses Controls associés et sa règle de fusion. La file ajoute insertion, remplacement, expiration et émission. Le gestionnaire rapproche les événements selon leur contexte et non leur heure d’arrivée. Enfin, une observation nouvelle et bornée dans le temps est nécessaire lorsque la décision porte réellement sur l’état courant.

Cette chaîne ne réintroduit pas artificiellement la synchronie. Elle rend l’asynchronisme explicable.

Le code en fonctionnement reste la frontière décisive

RFC 9675 est une architecture Informational commune. Son adoption devient observable dans les agents, gestionnaires, règles, Controls, schémas, files et comportements effectivement déployés. Le diagramme ne réalise aucun de ces éléments à lui seul.

La lecture par spécification minimale de Heng Lu convient ici : le document commun nomme les rôles, tandis que transport, sécurité, sécurité fonctionnelle, préséance et rétention restent des décisions localisées. La primauté du code en fonctionnement dirige l’audit vers la séquence réellement exécutée. Les couches de réalité empêchent de confondre politique, message, action, rapport, écran et résultat physique.

Un réseau difficile à observer ne justifie pas une preuve plus faible. Il exige au contraire que chaque changement d’heure, d’autorité et de représentation reste visible.

Sources