Résumé

  • Datée du 6 septembre 2026 et mise à jour dans Datatracker le 7, la révision 01 de draft-zhang-dawn-agent-discovery-framework reste une soumission individuelle, sans statut officiel dans le processus de normalisation de l’IETF.
  • Elle sépare la découverte locale de la fédération entre domaines. Une passerelle assainit les métadonnées, applique une politique d’exportation puis signe une Federation Metadata Record destinée à des pairs authentifiés.
  • La nouvelle correspondance avec le modèle MDI décrit origine, capacité, fraîcheur et provenance. Elle ne prévoit ni destinataires autorisés, ni droit de retransmettre, ni version de la politique ayant autorisé la sortie.
  • Daniel Kade propose une enveloppe de diffusion, liée au condensat de la fiche. Elle conserverait la décision de partage sans devenir une preuve d’identité de l’agent, un indice de confiance ou une permission de l’exécuter.

Un projet ne vaut pas mandat

La fiche Datatracker présente le texte de Bin Zhang comme un Internet-Draft individuel actif. Aucun flux RFC, Area Director responsable ou téléconférence n’y est associé. Le document vise un résultat informatif. Sa révision fournit donc une proposition à examiner, non l’architecture choisie par l’IETF.

Le vocabulaire du texte exige une autre précaution. Il évoque un groupe de travail DAWN, alors que la page officielle de DAWN maintient le groupe au stade BoF et indique qu’il n’a pas encore de charte. Le compte rendu de l’IETF 126 décrit précisément une séance de formation éventuelle : la charte était un point de départ, pas un consensus. La gouvernance du sujet demeure donc aussi provisoire que le protocole.

Cette réserve n’enlève rien à l’intérêt de la révision 01. Elle dessine deux plans. Le plan local récupère les annonces d’agents dans un site, par mDNS, un annuaire ou un autre mécanisme. Une Federation Gateway se place ensuite à la frontière administrative. Son moteur de politique d’exportation sélectionne les fiches, retire certains champs et fabrique un résumé léger pour la fédération.

Le détail riche ne voyage pas avec ce résumé. La Capability Card reste chez l’origine et doit être demandée en unicast authentifié. Ce découplage réduit le volume répliqué et conserve un second contrôle d’accès. Surtout, l’administrateur peut taire un agent ou montrer des sous-ensembles distincts à deux partenaires. La souveraineté promise par le projet réside dans ce choix initial.

La révision rend visible ce qui manque

La comparaison officielle avec la version 00 ajoute un tableau reliant le Minimum Discoverable Information de DAWN à la Federation Metadata Record. On peut désormais suivre la politique jusqu’aux données réellement prévues.

La fiche contient l’identifiant et le type de l’entité, éventuellement un point de terminaison, un résumé des capacités et l’adresse de la Capability Card. Elle prévoit une indication d’authentification, une référence de confiance, une date de publication, une durée de vie, une provenance, l’identifiant de la passerelle d’origine et un état de fiche. Un Geographic-Hint approxime aussi le Scope Hint du modèle MDI.

Ce dernier champ ne définit pas un périmètre d’autorisation. Une localisation grossière ne dit pas quels membres d’une fédération peuvent recevoir la fiche. Le TTL élimine une information devenue ancienne ; il ne limite pas les copies réalisées avant l’échéance. La provenance raconte l’origine ; elle ne consigne pas les conditions de diffusion.

Le tableau ne comporte ainsi ni classe de confidentialité, ni audience, ni interdiction de retransmettre, ni nombre maximal de sauts. Il n’identifie pas davantage la politique ou sa version. Une passerelle destinataire peut vérifier les octets signés, mais elle ne peut pas reconstruire la décision qui a produit ces octets.

Au premier échange, le défaut reste masqué. A sait qu’elle a autorisé B et refusé C. La section sur le plan de fédération permet expressément de fournir des sous-ensembles différents. Le problème commence quand B participe à une seconde relation ou alimente un mécanisme de réplication plus large.

Signé ne veut pas dire librement transmissible

Le modèle de sécurité exige une signature de la passerelle d’origine. Chaque destinataire doit la vérifier et rejeter une fiche invalide. C’est une propriété forte : B ne peut pas modifier silencieusement la fiche de A ni en fabriquer une au nom de A. Le projet admet toutefois qu’un membre malveillant peut inventer ses propres agents ; l’admission dans la fédération reste une politique administrative hors protocole.

La signature répond à « qui a produit cette fiche ? ». Elle ne répond pas à « A a-t-elle autorisé B à la communiquer à D ? ». D peut recevoir exactement les octets signés par A et prouver leur authenticité tout en ignorant si leur présence chez lui respecte le choix de A.

Dans une fédération fermée, le modèle d’appairage structuré peut reporter cette règle sur la configuration. L’annexe prévoit des politiques d’importation et d’exportation propres à chaque pair. Une petite communauté connaît les sessions, encadre les réflecteurs et peut attribuer une fuite à un chemin déterminé.

Le modèle gossip cherche une autre propriété : la croissance horizontale et la résistance aux pannes. Chaque passerelle compare périodiquement le résumé de son annuaire avec quelques voisines et transmet les fiches manquantes. Le projet reconnaît lui-même que les politiques précises par fiche sont difficiles à appliquer dans ce mode. Un déploiement mixte ajoute un pont entre l’appairage structuré et la rumeur, en conservant une FMR commune et opaque au transport. L’interopérabilité progresse ; le contexte local de politique risque de s’arrêter au pont.

Il ne s’agit pas de condamner la rumeur. Il faut simplement refuser de faire de l’authenticité une autorisation implicite de réplication.

Une enveloppe plutôt qu’un deuxième annuaire

Une correction légère peut préserver la minceur de la FMR. Une distribution-envelope, signée et liée au condensat exact de la fiche, porterait l’identifiant de l’origine, la référence de politique et son époque. Elle nommerait une classe de destinataires ou un segment de fédération, puis exprimerait l’une de trois règles : pas de retransmission, un prochain saut désigné, ou circulation permise dans un segment borné.

L’enveloppe comprendrait aussi une échéance et un pointeur de retrait. Un identifiant opaque de décision d’exportation permettrait à l’origine d’auditer ce qu’elle a libéré sans publier ses règles internes. Lors d’une traduction entre protocoles, un reçu du saut précédent indiquerait quel pont a accepté de maintenir la contrainte.

La règle ne sera jamais une protection absolue contre un pair malhonnête qui copie hors protocole. Elle donne en revanche une instruction exploitable aux logiciels conformes, une cause précise à un refus et une trace aux auditeurs. Une passerelle qui ne sait pas représenter la limite peut alors fermer le passage au lieu de convertir « authentique » en « librement retransmissible ».

Enfin, l’enveloppe doit rester à sa place. Elle n’établit ni identité stable, ni réputation, ni capacité réelle, ni autorisation d’invoquer l’agent. Le projet exclut justement l’évaluation complète de la confiance, la négociation de capacités, l’indexation de l’Internet ouvert et les règles commerciales. Le mécanisme proposé ne tranche qu’une question : sous quelle politique ces métadonnées peuvent-elles poursuivre leur chemin ?

Sources