Résumé

  • Ray Bellis est l'unique auteur du RFC 5625, BCP 152, publié en août 2009, et l'un des six auteurs du RFC 8490, norme proposée publiée en mars 2019. Les deux textes imposent des obligations à des logiciels qu'il n'a jamais livrés.
  • Les instruments qui nomment réellement ses devoirs — les règles de style des RFC sur la validation d'auteur et les erratas, et les règles de l'IANA sur l'examen des demandes d'affectation — rattachent ces devoirs à un document publié et à une file de registre, jamais à un déploiement en service.
  • Cette conclusion vaut pour les documents lus ici. Un contrat, une loi ou une nomination extérieure au dossier pourrait créer l'obligation manquante ; rien dans ce dossier ne le fait.

Le bloc d'adresse de BCP 152, page 12, ne contient qu'un nom, placé sous une raison sociale imprimée : Nominet UK. Voilà tout ce que la publication d'août 2009 consigne sur Ray Bellis, et c'est l'intégralité de ce qu'elle consigne. Le document qui surplombe ce bloc, RFC 5625, DNS Proxy Implementation Guidelines, passe ses pages à dicter leur conduite aux petits mandataires DNS. La section 4.1, page 4, précise comment un mandataire doit traiter les drapeaux d'en-tête DNS qu'il ne comprend pas.

L'obligation de cette clause pèse sur le mandataire. Le bloc d'adresse, lui, porte un nom et une affiliation. Il ne porte ni commission d'inspection, ni ligne hiérarchique, ni numéro à appeler quand un routeur grand public embarque un micrologiciel qui ignore purement et simplement la page 4.

Dix ans plus tard, le schéma se répète avec davantage de signatures. RFC 8490, DNS Stateful Operations, daté de mars 2019, aligne six auteurs — Bellis, Stuart Cheshire, John Dickinson, Sara Dickinson, Ted Lemon et Tom Pusateri — et consigne page 63 son affiliation chez Internet Systems Consortium, Inc. Le document impose des conditions préalables aux points d'extrémité avant l'établissement d'une session, à la section 5.1, pages 12-13 de l'édition HTML. Six personnes ont signé une règle sur les machines à états. Aucune n'a pour autant reçu de levier sur les machines.

L'appareil autour de la signature

Ce que le dossier montre, en revanche, et de façon très dense, c'est une mécanique institutionnelle qui a tranché le texte et dont on peut nommer les acteurs. La fiche Datatracker du RFC 5625 désigne Ralph Droms comme directeur de domaine responsable et le groupe de travail DNS Extensions comme rattachement. L'historique du projet prédécesseur enregistre l'approbation de l'IESG le 6 juillet 2009 et l'entrée dans la file de l'éditeur RFC le lendemain ; la note du berger de document d'avril 2009 nomme Olafur Gudmundsson, co-président du DNSEXT, comme shepherd. Pour le second texte, la fiche Datatracker le classe en norme proposée sous la responsabilité de Warren Kumari au sein du groupe dnsop, et l'historique du projet session-signal affiche l'approbation de l'IESG le 7 décembre 2018, l'entrée en AUTH48 le 11 février 2019 et l'état AUTH48-DONE le 15 mars 2019, avec Tim Wicinski comme shepherd.

Voilà une chaîne de personnes nommées accomplissant des tâches procédurales nommées : shepherd, directeur de domaine, organe d'approbation. Ce n'est pas une fonction de contrôle de conformité. Une liste de six auteurs et un scrutin d'approbation ne composent pas un service chargé de vérifier si le code d'un fournisseur se comporte correctement, et aucune clause des deux textes n'attribue un tel service à la personne dont l'adresse figure en fin de document.

Où atterrit réellement le devoir

Le devoir existe bel et bien ; il pointe simplement ailleurs. Le guide de style des RFC, RFC 7322, section 4.1.1 page 9, lie les auteurs et éditeurs nommés à la validation du document pendant l'AUTH48 et à la réponse aux demandes telles que les erratas. C'est une redevabilité envers un texte et envers ceux qui l'interrogent — une obligation réelle, dotée d'un destinataire réel, publiée en septembre 2014, cinq ans après BCP 152, donc une règle générale plutôt que le reflet de la pratique exacte de 2009.

Le second devoir se situe dans une file de registre. Le registre des paramètres DNS de l'IANA, mis à jour le 9 novembre 2026, classe Bellis parmi les experts des TYPEs d'enregistrement de ressources et comme expert secondaire des codes d'option EDNS0 ; les experts des codes de type DSO y sont Ted Lemon, Sara Dickinson et John Dickinson. Les règles de ce rôle figurent dans le RFC 8126 : la section 5.1 page 27 confie à l'expert désigné la coordination de l'examen d'une demande d'affectation et la transmission d'une recommandation à l'IANA, la section 5.2 pages 27-28 exige des décisions défendables et traite la récusation en cas de conflit, notamment lorsque l'expert a rédigé la spécification examinée, la section 5.2.1 pages 28-29 place la nomination et la révocation des experts entre les mains de l'IESG, et la section 5.3 page 29 impose célérité et transparence.

Lisez la clause de récusation avec attention, car elle joue exactement à l'inverse d'un mandat de police. La règle anticipe qu'un auteur puisse devoir se retirer du jugement d'une demande touchant sa propre spécification. Une règle de conflit qui réduit la portée de l'expert ne constitue pas un pouvoir sur les implémenteurs.

Deux registres qui ne concordent pas

Le profil Datatracker indiquait, au moment de sa consultation, que « Ray does not currently have any active roles ». Le registre de l'IANA, dans sa mise à jour du 9 novembre 2026, le liste comme expert. Aucune des deux pages ne se réconcilie avec l'autre, et aucune pièce examinée ici n'explique l'écart. Une phrase au présent sur le panneau des rôles d'un profil n'est pas un inventaire des nominations passées, et un champ d'expertise dans un registre n'est pas une preuve d'autorité sur un réseau. Les deux énoncés méritent d'être conservés exactement tels que chaque page les a formulés.

Les présidences de groupe dessinent la même forme. Le compte rendu de la téléconférence de l'IAB du 19 mars 2014, section 2.2, indique que Bellis a remplacé Alissa Cooper à la présidence du groupe geopriv. Le compte rendu du groupe Homenet à l'IETF 93 le cite avec Mark Townsley comme présidents, dans une séance datée du 22 juillet 2015. Qu'est-ce qu'un président doit personnellement ? Le RFC 2418 est précis : la section 3.1 page 11 rend le président responsable de la rédaction et de la diffusion des comptes rendus de séance, délégation admise, et la section 6.1 page 17 exige un bref rapport de fin de séance au directeur de domaine. De la paperasse remontant la hiérarchie. Rien sur l'audit du déploiement de qui que ce soit.

La lacune a un titulaire, et ce n'est pas l'auteur

Aucune disposition des documents lus pour cet article n'attribue à Bellis, du seul fait de sa qualité d'auteur, le devoir de surveiller, de signaler ou de faire respecter la conformité d'un implémenteur. C'est une conclusion sur un dossier circonscrit — BCP 152 et RFC 8490 dans leurs deux présentations, les deux historiques Datatracker, le profil, le registre IANA, le RFC 7322, le RFC 8126 et le RFC 2418 — et elle n'établit pas qu'un contrat de travail, une exigence d'achat, un programme de certification ou une loi, ailleurs, confie ce devoir à cet homme.

Le test honnête d'une mise en cause personnelle comporte donc cinq volets : la source du devoir, le rôle ou le contrôle effectif de la personne, l'acte ou l'omission, le lien causal avec une conséquence opérationnelle, et une sanction assortie d'une instance. Là où le devoir et le contrôle s'arrêtent au texte et au registre, l'attribution doit s'arrêter aussi. Un mandataire qui déforme des drapeaux inconnus produit un résolveur cassé, et l'auteur de la page 4 n'est pas celui qui détient les identifiants de cette machine.

Suivez donc la fonction. La conformité du code revient à qui l'a écrit ; la configuration, la supervision et la réponse aux incidents reviennent à qui l'exploite ; les exigences reviennent à qui a acheté ou audité ; la contrainte coercitive revient uniquement à un acteur doté d'un contrat, d'une loi ou d'un autre instrument créateur de devoir. Si aucun de ces acteurs n'a reçu la tâche de surveiller un déploiement précis, il existe une lacune de redevabilité qu'il faut nommer — et combler par une attribution, non en enrôlant rétroactivement l'homme dont le nom figure sur la règle.

La signature est une affirmation sur le texte. Le réseau en service répond à qui détient les clés.