Résumé

  • La RFC 9984 définit des groupements YANG pour clients et serveurs UDP, mais aucun nœud accessible config false. Elle décrit une intention configurable, pas l’état d’un socket en cours d’exécution.
  • Un nom d’hôte doit encore être résolu, le port local 0 doit encore être remplacé par un port choisi par le système, et une adresse joker ne dit pas sur quelles interfaces un processus écoute effectivement.
  • Kent Watsen partage cette RFC avec Alex Huang-Feng et Pierre Francois. La sobriété du modèle est une qualité : il appartient aux implémentations de joindre configuration, état appliqué, trafic et résultat applicatif sans prêter au standard une observation qu’il ne fait pas.

Le zéro que le tableau de bord avait pris au pied de la lettre

Une équipe redémarre un service, puis compare le fichier de configuration avec la veille. Rien n’a changé : même nom distant, même politique locale, même local-port: 0. Pourtant le pare-feu voit un autre port source et le système de supervision continue d’afficher zéro. Chacun dit vrai sur son propre plan, mais le tableau de bord a confondu une demande de sélection avec le résultat de cette sélection.

La RFC 9984 est très explicite. Lorsque la fonction local-binding est utilisée côté client, le port local a pour valeur par défaut 0 ; cela signifie que le système d’exploitation peut choisir n’importe quel port disponible. Zéro n’est pas envoyé sur le réseau. Il délègue une décision.

Cette petite règle contient tout le sujet. Un modèle peut décrire fidèlement l’intention tout en ne sachant rien du résultat concret. Pour dire « actif », il faut un autre témoin.

Un groupement n’est pas encore un arbre déployé

La RFC 9984, publiée en juin 2026 sur la voie Standards Track, fournit les modules ietf-udp-client et ietf-udp-server. Ce sont des blocs réutilisables destinés à d’autres modèles YANG.

La RFC 7950 précise qu’un grouping est un ensemble réutilisable de nœuds de schéma, mais que sa déclaration n’est pas elle-même une définition de données. Elle ne crée aucun nœud dans l’arbre. C’est un uses, placé par un modèle consommateur, qui instancie les nœuds ; ce modèle peut ensuite les affiner ou les augmenter.

Il faut donc distinguer le registre de l’usage. L’IANA enregistre les deux noms de modules, leurs fichiers datés du 15 juin 2026, leurs espaces de noms et leurs préfixes. Ce reçu stabilise l’identité d’un artefact. Il ne prouve ni son chargement, ni son instanciation, ni l’existence d’un processus UDP.

Un contrôle sérieux conserve la révision du module, puis le modèle consommateur, l’emplacement du uses, les fonctions activées, les raffinements et les augmentations. Une simple case « compatible RFC 9984 » efface précisément les choix qui déterminent le comportement de l’application.

Le nom configuré n’est pas l’adresse choisie

Le groupement client exige remote-address, mais accepte une adresse IPv4, une adresse IPv6 ou un nom d’hôte. Dans le troisième cas, la configuration ouvre une nouvelle étape : un résolveur doit produire une adresse selon une vue, un cache, une politique et un instant donnés.

La RFC indique que l’adresse résolue devrait être compatible avec la famille de l’adresse locale lorsqu’elle est fournie. Elle ne définit pas de champ pour l’adresse retenue, la source de résolution, l’heure ou la durée de validité. Ce silence permet à des applications très différentes de réutiliser le même bloc. Il interdit seulement de présenter le nom comme s’il constituait déjà le tuple distant observé.

Le port distant reste lui aussi à compléter. Il n’est ni obligatoire ni assorti d’une valeur par défaut ; le modèle consommateur doit ajouter une valeur connue ou rendre le champ obligatoire lorsque son protocole l’exige. Le groupement de base ne suffit donc pas toujours à former une destination complète.

Côté serveur, la liste local-bind accepte plusieurs points, plusieurs familles d’adresses et les valeurs joker IPv4 ou IPv6. Une adresse joker exprime une politique de liaison. Elle n’énumère pas les interfaces réellement exposées après application des espaces de noms, des adresses présentes et des règles du système.

Valide pour le schéma, refusé par le noyau

Une configuration peut respecter toutes les contraintes YANG et échouer lors de bind(). Le port est déjà occupé. L’adresse a disparu. Le service s’exécute dans un autre espace réseau. Le processus lie le socket puis tombe. Le fichier reste correct pendant que la réalité change.

La RFC 9984 ne cache pas cette limite : elle ne définit aucun nœud accessible config false. Ses modules, pris seuls, n’exposent ni donnée modifiable, ni état en lecture seule, ni RPC. Les modèles qui réutilisent les groupements doivent traiter leurs propres considérations de sécurité. Les adresses et ports peuvent révéler des informations privées ; recueillir un reçu opérationnel n’implique donc pas de le publier sans contrôle.

La sécurité dépend ici de deux disciplines simultanées. Il faut connaître le tuple effectif pour diagnostiquer et contrôler l’exposition. Il faut aussi limiter qui peut voir cette information, combien de temps elle est gardée et avec quel degré de détail.

NMDA nomme la distance au lieu de la masquer

La RFC 8342, dont Kent Watsen est l’un des cinq auteurs, distingue la configuration voulue de ce qu’un équipement utilise réellement. <intended> contient la configuration après transformations, celle que le système tente d’appliquer. La configuration appliquée est celle qui sert effectivement. L’état système regroupe les informations transitoires. <operational> réunit configuration appliquée et état système.

L’architecture recommande de comparer <intended> à la partie config true de <operational> pour savoir quelle part de l’intention est utilisée. Le délai d’application, les ressources absentes, les transformations, le matériel et les interactions logicielles peuvent créer un écart. Elle reconnaît même une configuration rémanente pendant la libération d’une connexion, de mémoire ou d’un descripteur.

La RFC 9984 n’ajoute pas elle-même les feuilles permettant d’observer le socket. Un modèle consommateur peut le faire. Une implémentation peut fournir de la télémétrie autrement. L’absence d’un format universel n’autorise pas à supprimer la distinction ; elle rend le propriétaire de l’exécution responsable de son propre reçu.

Une contribution collective qui sait où s’arrêter

Le profil public IETF Datatracker capturé le 2 septembre 2026 décrit Kent Watsen comme spécialiste de la gestion et de la sécurité des réseaux. Il recense alors des fonctions de président et de relecteur et compte 21 RFC, dont les RFC 8040, 8342 et 9984. Ces éléments sont datés et peuvent évoluer.

La RFC 9984 reste une œuvre collective. Alex Huang-Feng et Pierre Francois en sont auteurs avec Watsen, et les blocs de contact intégrés aux modules nomment Huang-Feng et Francois. Rien ne justifie d’attribuer à une seule personne l’invention, l’implémentation ou l’exploitation du modèle.

La contribution intéressante est une continuité intellectuelle : RESTCONF donne un accès structuré, NMDA sépare les magasins et les états, et le modèle UDP fournit un vocabulaire réutilisable. Dans cette architecture, être précis signifie aussi refuser de déclarer un fait que la couche ne peut pas observer.

La primauté du code exécuté défendue par Heng Lu formule le même test : le document aide à coordonner, mais l’opération établit la réalité. Son principe de spécification initiale minimale explique pourquoi le groupement doit rester fin. La norme partage ce qui est nécessaire ; le résolveur, le noyau, le superviseur de processus et l’application gardent leurs décisions locales et leurs preuves propres.

Six reçus au lieu d’un voyant vert

Le premier reçu identifie l’artefact : révision, espace de noms, référence IANA et empreinte. Le deuxième décrit l’instanciation : modèle consommateur, uses, fonctions, raffinements et augmentations.

Le troisième conserve l’intention : changement accepté, transformations, instant et vue <intended>. Le quatrième vient de l’exécution : instance du service, résolution, tuples local et distant effectifs, résultat de liaison, heure de création et motif de fermeture.

Le cinquième porte sur le trafic : compteurs bornés, première et dernière observation, erreurs et pertes, sans conserver inutilement les charges. Le sixième appartient à l’application : pair authentifié, requête acceptée, réponse valide ou transaction achevée.

Ces reçus permettent des états honnêtes. Configuré mais non appliqué. Lié mais silencieux. Actif sur une adresse inattendue. Trafic reçu mais refusé par l’application. La RFC 9984 n'est contredite dans aucun de ces cas ; elle fournit seulement le langage commun avec lequel on peut enfin poser la bonne question.

Sources