Résumé

  • Les commentaires actuels de la Draft Policy ARIN-2026-1 affirment que la proposition est présentée conjointement avec le groupe de travail IETF TIPTOP, tandis que l’index d’ARIN la classe toujours « under discussion ».
  • draft-li-tiptop-address-space reste un Internet-Draft individuel, sans approbation ni statut formel de l’IETF ; le 10 juin 2026, les présidents de TIPTOP ont relevé un intérêt pour le problème mais aucun consensus clair pour adopter ce texte en l’état.
  • Un reçu interinstitutionnel versionné devrait identifier l’objet, l’acteur, la relation, l’état procédural et le prochain acte requis, au lieu de laisser le mot « conjoint » porter toutes ces significations.

La page d’ARIN-2026-1 contient une phrase courte aux effets institutionnels considérables : la proposition serait faite conjointement avec le groupe de travail IETF TIPTOP. Son lien mène pourtant à la fiche Datatracker de draft-li-tiptop-address-space, qui indique un appel à adoption, non une adoption, et rappelle qu’un Internet-Draft n’est pas approuvé par l’IETF et n’a aucun statut formel.

Ces deux mentions ne prouvent pas une tromperie. Des auteurs et participants ont très bien pu collaborer étroitement. TIPTOP travaille réellement sur les communications au-delà de la Terre. Le problème est plus étroit : à quel acte public le qualificatif « conjoint » renvoie-t-il exactement ?

Un problème peut être commun avant que sa solution le soit. Des participants peuvent échanger des textes avant que leur groupe n’en adopte un. Une présentation peut précéder un choix. Un choix architectural peut précéder une demande à l’IANA. Une politique régionale peut avancer pendant que les autres RIR et le conseil d’ARIN gardent leur propre décision ouverte. Une bonne archive ne fusionne pas ces étapes.

Les verbes ne sont pas des synonymes

La charte de TIPTOP prouve l’existence d’un groupe actif et d’un périmètre technique approuvé. Elle ne sélectionne pas, à elle seule, un modèle d’allocation d’adresses. L’ordre du jour TIPTOP de l’IETF 126 rend la frontière visible : les textes de cas d’usage et d’architecture adoptés sont rangés sous WG Document Presentations, alors que draft-li et son concurrent figurent sous Address Space Discussions.

État Preuve publique minimale
Intérêt Le problème apparaît dans la charte ou les travaux du groupe
Auteur Des personnes nommées soumettent un texte précis
Présentation Le texte obtient un créneau à une réunion
Adoption par le WG Les présidents constatent que le groupe travaillera sur ce document
Consensus Le groupe soutient un résultat technique défini
Décision institutionnelle L’IETF, l’IANA, les RIR ou un conseil accomplit son propre acte
Mise en œuvre Les dépendances de politique et d’exploitation sont satisfaites
Activation Une entrée de registre et un processus effectif existent

Dire « discuté avec TIPTOP » n’équivaut pas à « adopté par TIPTOP ». « Adopté comme document de travail » ne veut pas encore dire « résultat final approuvé ». Et aucun de ces états ne crée, à lui seul, une allocation opérationnelle.

Ce qu’établit réellement ARIN-2026-1

L’index des projets de politique d’ARIN classe ARIN-2026-1 comme Draft Policy en discussion, dans sa version du 27 mai 2026. Le texte vise un bloc IPv6 destiné aux réseaux opérant au-delà de l’orbite terrestre géostationnaire. Il ne s’agit ni d’une politique adoptée ni d’une mise en œuvre constatée.

ARIN décrit elle-même les dépendances. Il faudrait une détermination de l’IETF et de l’IANA sur l’opportunité d’un bloc distinct, l’accord des RIR, puis une décision du conseil d’ARIN selon laquelle servir ces réseaux relève de la mission de l’organisation. Le projet ne peut remplacer aucun de ces actes.

La revue du personnel et du service juridique datée du 1er avril ajoute que le projet n’était pas applicable tel qu’écrit et énumère quatre conditions préalables. Le débat peut faire évoluer le texte. Mais le statut public reste celui d’une proposition en construction.

Cette lecture ne tranche pas la meilleure technique pour les réseaux spatiaux. Elle ne conclut ni sur la propriété des adresses, ni sur la compétence juridique, ni sur la mission d’ARIN. Elle pose une question antérieure : quelle institution a approuvé quel objet ?

Le résultat de l’appel à adoption

Le document décisif est le message des présidents de TIPTOP du 10 juin 2026. Ils constatent un soutien au travail sur la question d’espace d’adressage. Ils ne voient cependant pas, à cette date, de consensus clair du groupe pour adopter draft-li-tiptop-address-space en l’état.

Cette formulation positive et négative doit rester entière. L’IETF ne « rejette » pas le sujet. Le groupe reconnaît le problème mais n’a pas choisi le modèle cité. Les présidents mentionnent draft-kumari-tiptop-address-space, proposent une équipe de conception et demandent une comparaison plus nette.

Les deux textes sont des Internet-Drafts individuels sans statut formel. Le premier organise un registre spatial dédié. Le second conserve un rôle central pour l’IANA et les RIR existants. Leur coexistence montre précisément pourquoi « conjoint » est trop large : le groupe de travail n’avait pas encore transformé son intérêt pour le problème en choix du mécanisme.

Le constat est daté. Il ne prouve pas que draft-li ne sera jamais adopté, ni qu’un texte de synthèse n’apparaîtra pas. Il interdit seulement de raconter l’appel de juin comme une adoption déjà acquise.

Une architecture adoptée n’est pas une allocation

Le projet d’architecture IP de TIPTOP a, lui, le statut de document du groupe de travail. Il cite draft-li comme travail en cours et précise que le mémo d’architecture ne demande aucune action à l’IANA.

Cette différence est utile. Une architecture peut décrire les contraintes d’un réseau sans fixer le mécanisme d’allocation. La politique d’adresses, la délégation du registre et l’activation opérationnelle restent des objets distincts.

Le registre IANA de l’espace IPv6 unicast mondial, figé ici dans son état mis à jour le 10 octobre 2025, ne montre aucune allocation dédiée à l’espace extra-terrestre. Cette absence n’est pas une prédiction. Elle signifie seulement que la proposition ne doit pas être décrite comme un état actuel du registre.

Le reçu qui manque

Il n’est pas nécessaire d’interdire le mot « conjoint ». Il faut pouvoir l’auditer. Un reçu versionné pourrait être joint à toute attribution interinstitutionnelle.

Champ du reçu Contenu attendu
Déclarant L’acteur qui publie l’attribution
Objet Nom, version, empreinte et URL stable du document cité
Acteur attribué Auteurs, participants, présidents, WG, IETF, IANA, RIR ou conseil
Relation Consultation, coauteur, présentation, adoption, consensus ou exécution
Acte probant Courriel, procès-verbal, appel, vote, résolution ou entrée de registre
Période Date de début, état courant et éventuelle fin
Alternatives Autres modèles encore examinés
Dépendances Décisions restant nécessaires
Lignée Révision, remplacement, retrait ou correction

Appliqué à ARIN-2026-1, le reçu pourrait nommer la coordination entre participants, l’état de Draft Policy, la version exacte de draft-li, l’appel à adoption et son résultat. Si une équipe de conception produit demain un document adopté par TIPTOP, un nouvel événement s’ajouterait sans effacer la chronologie précédente.

Le champ « acteur » empêcherait surtout une dérive fréquente. Des participants de l’IETF ne sont pas « l’IETF ». Des auteurs de TIPTOP ne sont pas le groupe de travail. Les présidents peuvent constater un résultat de consensus ; ils ne créent pas ce consensus par leur seul titre. La précision protège chaque mandat.

Ce que les sources ne démontrent pas

Aucune source examinée ne démontre une mauvaise foi, une coordination impropre ou un usage volontairement trompeur du nom de l’IETF. Aucune ne prouve l’absence de discussions privées. Elles ne disent pas quel modèle technique doit gagner et ne ferment pas la possibilité d’un futur consensus.

Elles démontrent une séquence plus modeste : ARIN-2026-1 est en discussion ; ses commentaires emploient une attribution conjointe ; le modèle cité demeure un projet individuel ; l’appel de juin n’a pas dégagé de consensus clair pour son adoption en l’état ; un modèle concurrent subsiste ; l’architecture adoptée et la demande d’allocation sont deux objets différents.

La coopération n’est donc pas niée. Elle doit simplement porter ses dates et ses signatures.

Sources