Résumé

  • Le 8 octobre, l’IESG a approuvé la révision 02 de la charte du groupe DNS-SD Extensions, qui transforme un objectif général en tâches protocolaires et documentaires précises.
  • Le texte autorise des travaux sur la découverte de services avec un ou plusieurs liens, mais exclut les changements du DNS général et l’intégration d’autres protocoles de nommage sans configuration.

La nouvelle charte DNS-SD élargit le cadre de travail annoncé au-delà d’un seul lien, tout en décrivant plus précisément les tâches confiées au groupe. L’Internet Engineering Steering Group (IESG) a approuvé la révision 02 le 8 octobre. Cette décision autorise un programme de travaux de normalisation et de documentation ; elle n’approuve pas un nouveau protocole et ne prouve pas que les appareils découvrent déjà des services de manière fiable entre plusieurs réseaux.

La différence apparaît lorsqu’on compare les deux textes approuvés. L’ancienne charte visait « une solution pour un DNS-SD étendu et évolutif » et demandait de documenter les difficultés entre le nommage local sans configuration et le DNS mondial, sans les résoudre. La nouvelle charte remplace cette formulation générale par plusieurs tâches : publier dans mDNS les noms enregistrés au moyen du Service Registration Protocol (SRP), améliorer l’efficience, la disponibilité ou l’efficacité de DNS-SD et de mDNS, et définir comment traiter les mises à jour concurrentes d’un même nom.

Le contexte technique explique cette séparation. DNS-Based Service Discovery et mDNS sont largement utilisés sur un lien local, par exemple dans un logement ou un bureau, mais mDNS ne découvre pas les services sur des liens distants. SRP permet à des serveurs d’enregistrer leurs services dans le DNS unicast. Un proxy de découverte peut ensuite ajouter à cet espace unicast les services appris par mDNS. Ces briques rendent possible une découverte plus large, mais leur assemblage soulève des questions de noms, de mises à jour, de portée et de visibilité.

La charte distingue aussi les catégories de livrables. Les documents de voie Standards Track pourront définir la publication des noms SRP dans mDNS, l’amélioration des mécanismes de découverte et le traitement des conflits de noms. Des documents informatifs ou de bonnes pratiques pourront expliquer comment combiner les composants pour qu’un même service DNS-SD soit accessible aux clients mDNS comme aux clients SRP. Le groupe doit prendre en compte les exigences de confidentialité et de sécurité de la RFC 8882 et coordonner ses travaux avec SNAC, d’autres groupes DNS et des organismes externes si nécessaire.

Les exclusions sont aussi déterminantes que la liste des tâches. Le groupe ne reçoit pas mandat d’intégrer DNS-SD à d’autres protocoles de nommage sans configuration, tels qu’Universal Plug and Play ou Link-Local Multicast Name Resolution. La mise à jour des protocoles DNS généraux est également hors périmètre. Une charte rend un programme plus vérifiable en indiquant quelles questions relèvent du groupe et lesquelles exigent un autre lieu de décision ; elle ne tranche pas ces questions à elle seule.

Pour les opérateurs et les fabricants d’appareils, il s’agit d’un signal de gouvernance en amont, pas d’une étape de déploiement. La charte présente la compatibilité avec les déploiements DNS-SD et mDNS existants comme souhaitable, et non comme une garantie. Les prochaines preuves utiles seront les projets de documents, leurs examens et d’éventuelles normes rattachées aux tâches approuvées. Le nouveau mandat ne démontre ni une interopérabilité complète entre liens, ni un changement du DNS général, ni une décision de sécurité applicable à un déploiement particulier.

Sources