Résumé

  • draft-toutain-t2trg-coreconf-m2m-01 propose de projeter un modèle YANG compact, ses SID et ses contrôles vers des outils MCP capables de lire un appareil ou de configurer ses flux.
  • La présence d’un contrôle dans un graphe ne désigne pas l’acteur autorisé à l’exercer ; une réponse de protocole ne prouve pas non plus que l’état physique demandé a été atteint.
  • Une preuve défendable doit relier la révision du modèle, la résolution d’identité, le principal, la politique, l’accord, la requête, la décision CORECONF, l’exécution locale et une observation indépendante du résultat.

Deux équipes observent le même capteur. La première modifie, par un outil nommé « démarrer l’historique », le pas d’échantillonnage et la cadence des messages confirmables. La seconde ne touche à rien, mais son flux change immédiatement. Le bouton semblait local ; le paramètre était commun à tous les abonnements du transducteur.

Ce détail du projet CORECONF-M2M dit davantage sur l’autorité que bien des schémas de sécurité. Une interface peut être parfaitement typée, transportée sur un canal protégé et néanmoins masquer la portée réelle de l’opération. Le danger ne vient pas de YANG ou de MCP en soi. Il vient du moment où la commodité efface le sujet, la portée et la conséquence.

Au 2 octobre 2026, le Datatracker de l’IETF classait la révision 01 de CORECONF for Machine-to-Machine Communication comme Internet-Draft individuel actif, mis à jour le 16 septembre. Le texte, daté du même jour, vise le statut Informational et expire le 20 mars 2027. Il n’a ni flux RFC, ni area director responsable, ni telechat. Le Datatracker précise qu’une soumission individuelle n’est pas avalisée par l’IETF et n’a aucun statut formel dans son processus. La discussion sur la liste T2TRG ne constitue pas une adoption par l’IRTF.

Il faut donc lire une proposition en évolution. Le validateur YANG affichait ce jour-là 19 erreurs et 8 avertissements : références de révision absentes, descriptions manquantes, ordre canonique et accessibilité d’un nœud config false, entre autres. Ce sont des signaux de maturité du texte soumis, ni un verdict de sécurité ni la preuve d’un échec d’implémentation.

La représentation devient plus simple, la décision reste entière

Le projet assemble YANG pour le modèle, CoAP pour l’échange, CBOR pour la compacité et les SID pour remplacer des identifiants longs par des nombres. Il décrit des transducteurs qui peuvent être capteurs, actionneurs ou les deux. Ils exposent une quantité, sa source temporelle, des statistiques, des paramètres de notification et des opérations.

La révision 01 ajoute un pont vers les ontologies SOSA et SensorThings, puis vers MCP. Un serveur MCP « coreconf-m2m » enveloppe les actions en direct. Un second serveur pilote FROST, où se trouvent les Things, Datastreams et Observations. Dans l’exemple de Rennes, l’agent cherche un Thing, suit ses relations, récupère le SID et la précision du capteur, lit la valeur sur l’appareil puis la stocke dans FROST.

Le gain est réel : le modèle commun évite un convertisseur artisanal par appareil. Mais le serveur continue de traduire du sens. Il choisit l’enregistrement FROST, l’adresse CoAP, l’identité du transducteur, le SID d’instance, le SID cible, l’unité et la précision. Supprimer un adaptateur spécifique ne supprime ni l’intermédiaire ni sa responsabilité.

Une adresse périmée peut viser le mauvais boîtier. Une identité réutilisée peut relier un nom actuel à un ancien capteur. Une précision incorrecte transforme un entier valide en mesure plausible mais fausse. Un outil peut être conforme à son schéma tout en s’appuyant sur une projection obsolète.

Le reçu de projection doit donc conserver le module YANG exact, sa révision, les fonctions et déviations, le fichier SID, l’éventuelle traduction privée, l’identité de l’appareil et du transducteur, l’adresse, l’unité, la précision, la catégorie, la méthode, le chemin, le SID cible, la source FROST et sa fraîcheur.

Un contrôle décrit une possibilité, pas un mandat

Le graphe ccm2m:Control rend les opérations explicites. Il distingue read-single, read-stat, la remise à zéro des statistiques, la préparation de l’historique, l’abonnement et l’écriture instantanée d’un actionneur. Cette séparation est saine : configurer un flux ne revient pas à le démarrer, et l’arrêter dépend du cycle Observe de CoAP, non d’un SID magique supplémentaire.

Mais le graphe ne dit pas qui a le droit d’appeler l’opération. Il ne porte pas à lui seul la limite de vitesse, la fenêtre de maintenance, l’approbation humaine, le nombre d’essais, l’interverrouillage ou la procédure d’urgence.

Le projet CORECONF de base, révision 21, exige que le serveur empêche les utilisateurs non autorisés de lire ou écrire les ressources. Il prévoit une réponse 4.01 Unauthorized lorsqu’un client n’a pas le droit d’agir sur un nœud, un datastore, un RPC, une action ou un flux. Il mentionne les mécanismes adaptés d’authentification et d’autorisation.

La spécification MCP 2026-07-28 maintient elle aussi la frontière. La liste des outils peut varier selon l’autorisation présentée avec chaque requête. Le serveur doit valider les entrées et appliquer des contrôles d’accès ; le client devrait demander confirmation pour les opérations sensibles. Les annotations d’un outil ne sont pas fiables par nature.

La question est donc le raccordement. Le journal doit associer l’identité du serveur MCP et le hash de sa définition d’outil au client demandeur, au principal authentifié, à l’audience et aux scopes du credential, à la politique, à l’approbation, à la ressource et aux bornes des paramètres. Puis il doit conserver la décision d’autorisation CORECONF. Sans ce lien, on sait quel verbe était disponible, pas qui avait mandat pour l’exécuter.

Le chiffrement protège le trajet, pas l’effet

Le document sélectionné exige DTLS ou OSCORE pour les opérations CORECONF sur CoAP. Cette exigence est indispensable, mais son domaine est précis. Elle protège l’échange selon le profil déployé. Elle ne décide pas si un modèle d’IA, un technicien ou un service autonome peut ouvrir une vanne à cet instant.

CORECONF définit des erreurs de méthode, de ressource, d’autorisation et de contrainte YANG. Une réponse de succès atteste le traitement de la requête à ce niveau. Elle ne mesure pas la vitesse d’un arbre, la pression d’une conduite ou la position durable d’une vanne.

Le projet illustre un instant-write par une pompe fictive réglée à 1 500 tours par minute. L’identité de la pompe reçoit un SID de substitution, car elle n’existe pas dans le module d’exemple. L’actuation SOSA conserve la valeur écrite et l’heure d’émission de la commande. Le texte prend soin de distinguer cette commande d’une observation.

Cette prudence doit survivre à l’interface MCP. L’écriture est une intention transmise. La lecture d’un tachymètre est une autre preuve. Elle doit avoir sa propre identité, son étalonnage, son unité, son origine temporelle et son intervalle de validité. Si la « confirmation » provient du cache où la commande vient d’être inscrite, elle ne confirme que la commande.

Une chaîne complète sépare donc : invocation ; principal et accord ; autorisation ; message protégé ; validation par l’application ; commit ou démarrage d’action ; état des sécurités locales ; mouvement physique ; mesure distincte ; persistance du résultat ; rapprochement ou retour arrière. Elle peut s’arrêter légitimement avant le bout, à condition de le dire.

Le paramètre partagé est un test de gouvernance

Les paramètres de notification comprennent pas, nombre maximal d’échantillons, période, encodage, taille maximale, seuils, hystérésis, temporisation et fréquence des messages confirmables. Le projet précise qu’ils sont communs à toutes les observations d’un transducteur. Toute modification prend effet immédiatement, même sur les abonnements d’autres clients.

Cette sémantique transforme un réglage apparemment privé en changement partagé. L’autorisation « s’abonner » ne devrait pas emporter automatiquement l’autorisation « reconfigurer les autres ». L’outil doit annoncer cette portée, lire la version précédente, vérifier une précondition, enregistrer avant/après et identifier les abonnés affectés. Le drapeau active indique seulement qu’au moins un client écoute ; il ne fournit pas leur consentement.

Le même raisonnement vaut pour FROST. Le serveur proposé offre non seulement la consultation, mais aussi la création, la modification et la suppression d’entités. Si cette base sert à résoudre l’adresse et les SID d’une opération en direct, le droit de modifier ses lignes participe indirectement au chemin de commande.

Les messages NON déplacent l’incertitude vers l’application

Le profil impose des requêtes FETCH et iPATCH Non-Confirmable. Sur un lien contraint, cela évite des retransmissions CoAP coûteuses. En retour, l’application doit décider du délai, de la répétition et de l’idempotence.

En l’absence de réponse, elle ignore si la requête s’est perdue, si l’opération a été appliquée puis la réponse perdue, ou si l’appareil travaille encore. Répéter une affectation de valeur peut être acceptable ; répéter une action avec effet de bord peut ne pas l’être. Le reçu doit inclure token, identité de requête, hash du corps, numéro d’essai, règle de timeout, comportement anti-doublon et lecture ultérieure.

À l’inverse, l’ACK d’une notification Confirmable montre que le pair CoAP a reçu le message. Il ne prouve ni son stockage durable dans FROST, ni sa prise en compte par l’agent, ni la fin de la condition physique. Compacter le réseau ne doit pas compacter ces nuances.

Le temps et l’unité gouvernent la réalité observée

Le bootstrap fournit uptime, époque de référence éventuelle et pas minimal. La quantité peut être horodatée par la source ou par le récepteur. Certains temps d’historique sont reconstruits depuis l’arrivée et l’intervalle. L’heure d’émission d’une commande, son acceptation par le firmware et le moment physique de l’effet ne sont donc pas synonymes.

Une valeur brute ne devient une grandeur qu’avec son identité, son unité et sa précision. Interroger plus vite que le minimal-step peut vider la batterie sans produire une information plus fraîche. La preuve finale doit conserver la provenance de l’horloge, la qualité temporelle, la révision du modèle, l’unité, la précision, l’étalonnage et l’âge de la mesure.

Enfin, le résultat du validateur YANG doit rester à sa place. Dix-neuf erreurs et huit avertissements disent que cette révision précise a encore du travail. Un futur zéro erreur ne prouverait ni l’interopérabilité, ni l’autorisation, ni l’action mécanique. C’est un reçu du modèle, pas un certificat de sûreté.