Résumé

  • La révision 21 confie au Publisher Parent la décomposition d’un Network Node Subscription en Component Subscriptions sans chevauchement et impose au moins un Message Publisher ID dans l’état de l’abonnement.
  • La liste annoncée par le Parent est un reçu de composition, pas la preuve que tous les composants nécessaires ont été choisis ni que chaque Agent a livré sans interruption.
  • La continuité se démontre processus par processus, avec le contexte du nœud, l’ensemble attendu, l’identité de l’éditeur, l’époque de séquence, l’identité du message si nécessaire, l’heure d’observation et l’historique des changements.

Une correction d’autorité pendant le Last Call

draft-ietf-netconf-distributed-notif-21 a été déposé le 6 septembre 2026, alors que le document du groupe NETCONF se trouve en IETF Last Call jusqu’au 8 septembre. Il vise le parcours des normes et a été soumis à l’IESG, mais demeure un Internet-Draft. Il n’est ni un RFC ni une annonce de déploiement.

La version 20 venait de recevoir un avis IANA - Not OK, notamment pour un exemple XML invalide et des actions de registre à préciser. La version 21 répare les guillemets, révise le texte IANA, corrige les chemins YANG cités dans la sécurité et replace l’examen dans l’état Version Changed - Review Needed. Une nouvelle vérification est attendue ; aucune inscription achevée n’est revendiquée.

Le changement de fond tient au sujet d’une phrase. Le Subscriber maintient l’abonnement du nœud auprès du Parent ; le Publisher Parent le désassemble ensuite en abonnements de composants. Le Subscriber connaît la demande. Le Parent connaît les Agents et leurs capacités. L’autorité qui choisit la couverture se trouve donc dans le nœud, avec l’obligation d’expliquer cette couverture.

Le min-elements 1 ajouté à la liste d’état message-publisher-id interdit une liste vide. C’est un progrès vérifiable, mais une liste non vide peut encore être incomplète.

L’identifiant d’abonnement décrit un contrat

Le Collector peut séparer le Subscriber d’un ou plusieurs Receivers. Les demandes arrivent uniquement au Parent. Celui-ci expose les capacités du nœud, crée des abonnements de composants sans chevauchement, transmet les propriétés aux Agents et conserve l’état global. Les Agents héritent du même identifiant et du même cycle de vie, puis publient directement leurs données.

L’identifiant commun relie donc plusieurs émissions à un contrat logique ; il ne désigne pas un processus unique. Une courbe agrégée peut rester régulière pendant qu’un Agent est muet. Le calme peut venir d’une baisse réelle, d’une nouvelle décomposition, d’un redémarrage ou d’une rupture de transport.

La coordination Parent-Agent reste hors périmètre, et l’affectation des sous-arbres YANG dépend de l’implémentation. L’absence de chevauchement évite les doublons entre composants déclarés ; elle ne prouve pas que le nœud en exécution est entièrement couvert.

Trois réalités à rapprocher

Le Parent émet tous les événements de cycle de vie. subscription-started et subscription-modified donnent l’ensemble courant des Publisher IDs ; une nouvelle liste doit suivre toute modification de la décomposition. Ces messages doivent être conservés comme des déclarations datées du Parent.

Ils ne fusionnent pas trois réalités : l’ensemble déclaré par le Parent, l’ensemble observé par le Receiver et l’ensemble en exécution qui devrait contribuer selon l’inventaire et la configuration. Si les deux premiers coïncident, on sait seulement que tous les Agents déclarés ont été entendus. Une carte oubliée ou un sous-arbre mal attribué peut ne jamais entrer dans le compte.

Comme l’écrit Heng Lu sur les couches de réalité, la clarté symbolique ne remplace pas la vérification opérationnelle. La déclaration acquiert du poids lorsqu’elle est confrontée aux capacités, à l’inventaire et à la configuration, et que chaque écart garde un propriétaire.

Une continuité propre à chaque processus

Chaque push-update ou push-change-update peut porter le Message Publisher ID local de son auteur. Le projet d’enveloppe ajoute, en option, un nom d’hôte et un compteur par processus : 32 bits, départ à 1, passage par 0 visible après 4 294 967 295. L’horodatage d’observation indique quand la valeur a été vue, pas forcément quand l’événement s’est produit, a été encodé ou livré.

Chaque champ répond à une question distincte. L’identité nomme l’auteur ; la séquence révèle un trou dans une époque ; l’identifiant de message aide à distinguer répétition et duplication ; l’heure situe la mesure ; l’état de l’abonnement indique qui était attendu. Un redémarrage ouvre une nouvelle époque, un ancien message peut arriver tard, et un identifiant local peut entrer en collision entre nœuds. La clé d’audit doit donc inclure le nœud, le processus, l’époque et l’intervalle d’état du Parent.

Une adresse, plusieurs autorités

Tous les Agents apparaissent avec la même adresse IP source. En UDP, ils peuvent partager le même port source ; en HTTPS, l’architecture prévoit un port propre à chaque processus. Le cinq-uplet, la terminaison TLS et l’identifiant d’abonnement sont des repères de routage, pas une provenance complète.

Le transport UDP combine Publisher ID et Message ID, et peut encore nécessiter l’adresse source lorsque des identifiants locaux sont réutilisés. Il déconseille aussi de dépendre de la fragmentation IP pour les gros messages. Identifier l’Agent manquant ne suffit pas si son plus grand message se perd silencieusement.

La publication directe fragmente la sécurité

Publier depuis des cartes ou processeurs réseau évite de faire traverser toutes les données au processeur de routage central. Mais l’authentification, l’autorisation, les clés, les limites de débit et les budgets de ressources se répartissent aussi. Les transports sûrs de NETCONF ou RESTCONF et NACM restent pertinents ; leurs identités et points d’application effectifs doivent être établis dans chaque déploiement. Une règle au Parent ne prouve pas son exécution par tous les Agents.

Les Publisher IDs révèlent en outre la topologie des processus. Leurs changements peuvent signaler redémarrage, extension ou réaffectation. Cette visibilité sert l’audit et peut aussi guider une cartographie hostile ou une usurpation. L’accès à la topologie brute doit être restreint sans retirer les identités de la chaîne de preuve.

La question encore ouverte

La prose exige une identité d’éditeur dans les notifications de mise à jour, tandis que l’arbre YANG courant affiche le message-publisher-id par message comme facultatif. Le minimum d’une entrée ajouté en version 21 concerne la liste d’état, pas automatiquement chaque donnée. Ce n’est pas ici un verdict de défaut, mais une question de Last Call : sous quelles conditions un Receiver doit-il rejeter ou isoler une mise à jour sans auteur ?

Il faut tester séparément la liste non vide, la présence d’une identité dans chaque mise à jour, son appartenance à l’ensemble alors actif et le traitement des écarts.

Limites

Les sources établissent les textes, l’historique et l’état des examens. Elles n’établissent ni adoption par un fournisseur, ni conformité d’une implémentation, ni topologie déployée, perte, gain de performance, incident ou exploitation. Les projets d’enveloppe, UDP et HTTPS peuvent encore évoluer.

La conclusion durable est modeste : décomposer, déclarer, émettre, observer et rapprocher sont cinq actes différents. Un seul identifiant ne peut les remplacer sans effacer la responsabilité.

Sources