Résumé

  • Charleston Road Registry veut subordonner l’enregistrement sous .mcp à quatre formes vérifiables de participation à MCP.
  • Le .MCP Policy Council aurait un droit de consentement sur les changements de politique, sans que le dossier public précise sa composition ni ses voies de recours.

Un nom de domaine et un protocole ouvert ne sont pas la même institution. Le Model Context Protocol organise des échanges entre logiciels. Une extension comme .mcp, si elle était déléguée, serait administrée par un registre qui accorde des noms selon son contrat. Le rapprochement entre les deux peut être utile, mais il introduit une question nouvelle : faut-il appartenir à une catégorie reconnue pour obtenir une adresse dans cet espace ?

La candidature publique de Charleston Road Registry Inc. (CRR), l’entité juridique de Google Registry, propose quatre réponses possibles à cette question. Le demandeur pourrait prouver une contribution aux dépôts officiels de MCP, exploiter un serveur MCP actif et conforme, détenir ou représenter une entrée dans le registre officiel MCP, ou être membre en règle de l’Agentic AI Foundation (AAIF). Selon les réponses du candidat, le registre vérifierait ces conditions avec l’aide d’un .MCP Policy Council. À la question 151, CRR précise que toute modification de la politique nécessiterait le consentement de ce conseil.

Ces catégories ne se recouvrent pas. La contribution se mesure dans des dépôts de code ; l’exploitation, dans une activité technique en cours ; l’inscription au registre MCP, dans un statut de représentation ; l’adhésion à l’AAIF, dans une relation institutionnelle. Un débutant, un mainteneur, un fournisseur d’outils et un membre d’organisation n’ont donc pas les mêmes preuves à produire ni les mêmes risques de contestation. Le dossier décrit les quatre portes d’entrée, mais ne fixe pas publiquement le seuil de preuve, le traitement des erreurs ou un mécanisme d’appel.

Le point le plus sensible est l’autorité qui encadrerait ces critères. Le nom du .MCP Policy Council apparaît dans le dossier comme assistant du registre pour l’application des règles et comme détenteur d’un droit de consentement pour les modifier. La réponse publique ne précise pas qui choisit ses membres, leur durée de mandat, les conflits d’intérêts, la représentation des personnes concernées ou le lien formel avec les organes de gouvernance de MCP. Ce silence n’établit ni captation ni mauvaise foi. Il empêche simplement de savoir à qui une personne exclue pourrait demander des comptes.

La gouvernance publiée du projet MCP est distincte. Sa page officielle décrit un Steering Group ainsi que des rôles de Lead, Core et Maintainer ; elle indique que la gouvernance technique revient à des personnes et non à des sièges réservés aux entreprises. Elle ne mentionne pas le .MCP Policy Council. Rien dans ces documents n’autorise à présenter ce conseil comme la direction technique de MCP, ni à supposer que les décisions du projet lieraient automatiquement le registre. Le registre peut gérer les conditions contractuelles d’un nom ; cela ne lui donne pas pour autant la maîtrise des contributions, de la conformité des implémentations ou de l’évolution du protocole.

Le calendrier de l’ICANN doit lui aussi être lu avec prudence. Le fichier publié le 7 octobre place cinq demandes dans un groupe initial de contention .mcp : CRR, OPENAI OPCO, Radix, ShortDot et Tidal Case. Les cinq résumés publics indiquent « Active / Pre-Evaluation Processing ». Seul celui de CRR affiche Community dans le champ public tldTypes; les quatre autres listes sont vides, ce qui ne prouve pas qu’elles n’ont aucun argument communautaire. L’ICANN ne présente pas ces groupes comme définitifs avant la fin de l’évaluation des chaînes.

Si CRR conserve sa désignation communautaire et choisit de participer à une Community Priority Evaluation, l’issue peut influer sur la priorité dans ce groupe. Le guide de candidature en vigueur traite la CPE comme une évaluation indépendante destinée à départager les demandes en contention. Elle suppose que les étapes requises d’évaluation et de règlement des différends soient accomplies, et les Registry Commitments proposés font d’abord l’objet d’un examen distinct. Une candidature communautaire qui réussit peut l’emporter sur les candidatures non communautaires ; si plusieurs réussissent, elles vont aux enchères.

La CPE compte quatre critères et exige 12 points sur 16. Elle ne décide pas si MCP existe en tant que communauté : le candidat désigne sa communauté, tandis que l’évaluation porte sur la priorité de sa demande. Ce n’est pas un vote sur la légitimité des organes techniques de MCP.

La Note 72 sert de question de gouvernance, pas de règle à transposer. Elle rappelle qu’une liste de diffusion, une réunion ou un accord politique ne crée pas automatiquement un titre de propriété. Son propos concerne toutefois le pouvoir des registres Internet régionaux sur les ressources de numérotation. Un registre de domaine relève d’un autre contrat et doit administrer les enregistrements. La question pertinente est donc plus limitée : les exclusions seront-elles motivées, révisables et contestables ? Les demandeurs sauront-ils qui détient le pouvoir de modifier la règle ?

.mcp n’est ni délégué ni approuvé. Le dossier permet déjà de séparer les risques : la participation au protocole n’équivaut pas à l’éligibilité à un domaine ; la vérification doit être accompagnée d’un recours ; le pouvoir d’amendement du conseil doit être documenté ; et une décision de registre ne vaut pas approbation de MCP. Si la candidature progresse, la charte du conseil comptera autant que la liste des critères.

Sources