Résumé

  • RFC 3113 recommandait à 3GPP d’utiliser les standards IETF sans les modifier lorsque c’était possible et de porter les changements nécessaires devant le groupe de travail IETF compétent, ou devant un directeur de zone.
  • La liaison transmettait documents, expertise et alertes de calendrier ; elle ne pouvait ni accorder d’exception aux procédures IETF ni confondre les règles d’approbation, de maintenance et de propriété intellectuelle des deux organisations.

Le problème n’était pas de se parler

Le futur réseau mobile de troisième génération ne pouvait pas rester une île. Ses terminaux devaient atteindre des services Internet ; son cœur de réseau devait réutiliser des protocoles déjà déployés ; ses contraintes radio devaient remonter jusqu’aux ingénieurs qui écrivaient ces protocoles. Le besoin de coopération était évident. La question difficile était de savoir ce que la coopération autorisait.

RFC 3113, publiée en juin 2001 comme document informatif, donna une réponse extraordinairement sobre. L’objectif était d’obtenir des spécifications à temps et une interopérabilité maximale avec les systèmes, appareils et protocoles Internet fixes et mobiles. Mais chaque organisation continuerait de fonctionner selon ses propres règles : politique de propriété intellectuelle, élaboration, approbation et maintenance des spécifications.

La dépendance technique ne devenait donc pas un transfert de mandat. 3GPP pouvait avoir besoin d’un protocole IETF sans pouvoir le modifier au nom de l’IETF. L’IETF pouvait bénéficier de l’expertise radio sans approuver l’architecture mobile entière. Le canal commun ne créait pas un troisième souverain.

Cette séparation rendait la coopération crédible. Sans elle, une contrainte de calendrier aurait pu se transformer en exception improvisée, un rapporteur en décideur, ou une référence externe en prétendue délégation de pouvoir.

Réutiliser avant de bifurquer

Le principe opérationnel était clair : 3GPP préférait employer les standards Internet sans changement lorsque cela était possible et ne voulait pas dupliquer le travail accompli par l’IETF. Une seule spécification partagée réduisait le risque que les réseaux fixes et mobiles attribuent des sens différents au même protocole.

RFC 3113 n’ignorait pourtant pas les besoins particuliers d’un système mobile. Une latence radio, un état de mobilité, une contrainte de terminal ou une architecture de sécurité pouvaient révéler une lacune. Dans ce cas, 3GPP devait exposer le problème au groupe de travail IETF approprié ; s’il n’en existait pas, le point d’entrée devenait le directeur de zone compétent.

Ce trajet est le cœur de l’architecture institutionnelle. La demande allait vers le détenteur du processus de changement. Elle ne passait pas par un secrétariat chargé de fabriquer une décision commune. 3GPP restait maître de ses versions et de ses dépendances. L’IETF restait maître de son texte, de son consensus et de sa publication.

Une urgence pouvait être réelle sans devenir un ordre. Une modification pouvait être techniquement justifiée sans être déjà approuvée. La liaison devait rendre visibles besoin, calendrier et interlocuteur ; elle ne devait pas transformer la pression en autorité.

L’expertise circulait dans les deux sens

Le document ne décrivait pas seulement 3GPP comme consommateur de RFC. Il présentait les groupes techniques capables d’apporter à l’IETF des connaissances sur l’accès radio, le transport physique, la mobilité, le cœur de réseau, les terminaux, les applications, l’architecture, la sécurité et l’exploitation.

Cette circulation inverse évitait qu’un protocole ouvert soit néanmoins conçu dans un environnement imaginaire. Une hypothèse bénigne sur un réseau fixe pouvait coûter très cher sur une interface radio. Un délai ou un état pouvait avoir un sens différent lorsqu’un terminal changeait d’attachement. L’expert pouvait documenter ce réel sans obtenir, par ce seul fait, le droit d’approuver le remède.

Voilà une distinction que la gouvernance technique perd facilement. L’expertise établit les contraintes et les effets. L’autorité établit qui peut adopter une modification. La présence dans une réunion, l’écriture d’un courrier ou la connaissance la plus fine du problème ne remplace pas automatiquement la procédure du principal compétent.

Le messager ne possédait pas le message

RFC 3113 privilégiait les échanges informels au niveau de travail et la participation aux listes de diffusion. Une communication formelle restait possible, facilitée par les directeurs de zone IETF et les responsables techniques de 3GPP. Un rapporteur, puis un agent de liaison, aidait à trouver la bonne destination.

Le texte verrouillait toutefois la limite : l’agent de liaison ne pouvait créer aucune exception ni disposition spéciale aux politiques et procédures de l’IETF. Il était un point de contact pour ce qui ne se résolvait pas aisément entre groupes techniques, non une voie rapide autour du consensus.

RFC 4052 généralisa ensuite la logique. Une liaison sert à prévenir la duplication sans empêcher chaque organisation de poursuivre son propre mandat. Les travaux confiés à l’IETF suivent les procédures ordinaires de l’IETF. Un agent de liaison peut rediriger une demande, suivre une dépendance et porter un message expressément autorisé ; il ne produit pas lui-même la position qu’il transporte.

Même le courrier formel garde une chaîne de preuve. Une déclaration au nom d’un groupe exige la discussion et l’accord des présidents du groupe. Une déclaration de zone exige le directeur ; une parole au nom de toute l’IETF exige son président. RFC 4053 donne la bonne image : une liaison écrite est une lettre professionnelle. Elle peut demander une action ; elle n’est pas l’action.

Les documents ouverts limitaient l’ambiguïté

Les deux organisations encourageaient le partage des brouillons d’intérêt commun. En 2001, RFC 3113 insistait sur l’accès par le Web et sur les contacts capables d’expliquer la structure documentaire de l’autre monde. Cette ouverture permettait d’identifier une dépendance par un texte et une version, non par le souvenir d’une réunion.

Elle ne supprimait pas les catégories. Un Internet-Draft n’est pas un RFC approuvé. Une liste de dépendances n’est pas une décision de publication. Une Technical Specification 3GPP et un Technical Report n’ont pas le même statut. Une déclaration reçue ne prouve pas que sa demande a été acceptée.

RFC 4691 décrivit plus tard un travail concret : 3GPP, 3GPP2 et OMA transmettaient périodiquement leurs listes de dépendances, et l’agent de liaison pouvait porter une demande de numéro RFC accéléré au directeur de zone. Le dispositif rendait le temps visible. Il ne promettait pas que l’IETF pourrait toujours respecter le calendrier demandé.

Vingt-cinq ans plus tard, la frontière reste reconnaissable

L’IETF affiche encore 3GPP dans sa liste de relations de liaison et renvoie toujours à RFC 3113. Un Internet-Draft publié en mars 2026 propose de remplacer l’ancien texte parce que les structures, les noms et les mécanismes d’accès aux documents ont vieilli. Il affirme cependant que les principes de haut niveau demeurent : réutilisation sans changement si possible, absence de duplication, retour des modifications vers l’IETF.

Il faut respecter son statut. Ce projet est un travail en cours, pas un successeur déjà approuvé. Il témoigne d’une intention de conserver la frontière ; il ne prouve pas que RFC 3113 est déjà obsolète.

Les minutes d’une réunion de coordination de mars 2026 montrent une interface réelle, donc imparfaite : échanges prolongés, retour oublié, dépendance envers des projets non terminés, préférence de 3GPP pour les RFC stables, et cas où l’IETF ne prévoit aucune mise à jour. Parfois 3GPP traite lui-même le besoin ; parfois un groupe IETF doit répondre. Il n’existe pas de bouton commun qui transforme chaque problème en résultat uniforme.

La séparation était une propriété de sûreté

3GPP contrôlait ses spécifications et son calendrier. Les groupes IETF contrôlaient le travail protocolaire IETF. L’IAB établissait la relation de liaison. Les agents entretenaient la route. Les éditeurs choisissaient des références exactes. Les implémenteurs choisissaient les versions qu’ils traduisaient en code. Les opérateurs supportaient le résultat assemblé.

Aucune preuve ne couvrait toute la chaîne. Une référence 3GPP prouvait une dépendance, pas l’approbation IETF du système mobile. Un RFC prouvait une publication, pas un déploiement. Une liaison prouvait une demande, pas un accord. Un compte rendu prouvait une discussion, pas l’interopérabilité.

La garde divisée protégeait donc le système. Si un agent avait pu déroger au processus pour sauver une date de livraison, le canal serait devenu un pouvoir sans contrôle. Si l’IETF avait pu étendre la propriété d’un protocole à toute l’architecture 3GPP, une dépendance serait devenue une annexion. Si 3GPP avait copié et modifié les protocoles en privé, deux Internet auraient porté le même vocabulaire.

RFC 3113 choisit un meilleur compromis : montrer la dépendance, partager les textes, envoyer les experts au bon endroit, laisser chaque décision à son propriétaire et conserver la version réellement employée. Les deux mondes partageaient un système. Ils ne partageaient pas un pouvoir indivisible, et c’est justement cette limite qui rendait leur coopération durable.

Sources

  1. https://www.rfc-editor.org/rfc/rfc3113.txt
  2. https://www.rfc-editor.org/rfc/rfc2850.txt
  3. https://www.rfc-editor.org/rfc/rfc2026.txt
  4. https://www.rfc-editor.org/rfc/rfc4052.txt
  5. https://www.rfc-editor.org/rfc/rfc4053.txt
  6. https://www.rfc-editor.org/rfc/rfc4691.txt
  7. https://www.rfc-editor.org/rfc/rfc3131.txt
  8. https://www.ietf.org/about/liaisons/
  9. https://www.ietf.org/archive/id/draft-kes-rfc3113bis-01.html
  10. https://datatracker.ietf.org/doc/minutes-interim-2026-ietf3gpp-01-202603160445/
  11. https://wiki.ietf.org/group/iab/3gpp_liaison_relationship
  12. https://www.3gpp.org/ftp/Information/Working_Procedures/archive/2019-08-23/3GPP_WP.htm