Résumé

  • Un président de groupe d’étude de l’ITU-T pouvait mandater un délégué pour parler officiellement, mais l’IETF devait accorder à son avis le même poids qu’à celui de tout autre participant du groupe de travail.
  • L’approbation, l’acheminement et l’archivage rendaient une liaison vérifiable ; ils ne prouvaient ni l’accord du destinataire, ni la publication, ni la mise en œuvre.

Un délégué entre dans une réunion avec un mandat irréprochable. Son président l’a autorisé, la liste officielle a été transmise et personne ne conteste qu’il expose bien la position de son groupe d’étude. Pourtant, cette authenticité ne lui donne pas le dernier mot.

C’est la frontière la plus féconde de RFC 3356. Le texte précisait que l’opinion d’un délégué officiel de l’ITU-T recevait, dans un groupe de travail de l’IETF, le même poids que celle de tout autre participant. Le mandat répondait à la question « qui parle ? ». Il ne répondait pas à « qui décide ici ? ».

Publié en août 2002, ce RFC informatif remplaçait RFC 2436. L’essentiel du texte était commun avec le Supplément 3 de la série A de l’ITU-T, approuvé par le TSAG le 30 novembre 2001. Ce voisinage documentaire reflétait un besoin réel : signalisation, numérotation, routage, sécurité, gestion et accès faisaient travailler les deux organisations sur des surfaces proches.

Mais leurs machines institutionnelles n’étaient pas identiques. À l’IETF, les groupes de travail délibéraient surtout sur des listes publiques ouvertes, sous la conduite de responsables de domaine et de l’IESG. À l’ITU-T, les travaux se structuraient en Questions, groupes de travail, groupes d’étude et rapporteurs, avec un rôle plus marqué des réunions. Collaborer ne pouvait donc pas signifier appliquer une procédure unique sous deux sigles.

RFC 3356 commençait par organiser la découverte. Un groupe d’étude devait inscrire dans son programme l’objectif et le résultat attendu d’une collaboration. Un groupe de travail de l’IETF devait faire de même dans sa charte. Cette petite exigence empêchait qu’une simple proximité thématique soit présentée comme une copropriété du sujet.

La liste NewWork fournissait une alerte précoce. Les projets de chartes et les annonces de BOF y étaient relayés vers l’ITU-T ; les programmes de travail de l’ITU-T devaient circuler dans l’autre sens. Le délai de création d’un groupe IETF pouvait n’être que de deux semaines, d’où la recommandation d’une veille continue.

Une alerte ouvrait une fenêtre de réaction. Elle ne réservait pas le domaine, n’imposait pas une pause et ne créait aucun droit de veto. Elle produisait un reçu d’attention, non un titre de compétence.

La représentation formelle ajoutait une chaîne d’autorisation. Un participant de l’IETF pouvait se rendre à une réunion de l’ITU-T comme délégué de l’ISOC après accord du groupe de travail ou du domaine concerné ; le président de l’IAB transmettait l’inscription. Inversement, le président d’un groupe d’étude pouvait désigner un délégué habilité à parler de ses activités.

Cette désignation protégeait la provenance. Elle empêchait qu’une opinion personnelle soit vendue comme position officielle. Pourtant, une fois dans l’espace IETF, le délégué rejoignait le processus existant. Son titre ne fabriquait ni voix supplémentaire, ni veto, ni consensus automatique.

La même séparation valait pour les messages. Les échanges informels entre experts étaient encouragés. Une communication formelle devait toutefois être expressément approuvée et identifiée comme venant du groupe d’étude, du groupe de travail, du groupe de rapporteur ou du domaine compétent.

Les messages ITU-T vers l’IETF étaient adressés aux présidents et responsables de domaine, copiés vers une adresse dédiée aux déclarations de liaison, déposés sur une page de liaisons et attribués à une personne responsable du traitement. Ces traces répondent à des questions importantes : quel texte a été reçu, où a-t-il été publié et qui devait agir ?

Elles ne disent pas si le groupe était d’accord. Une déclaration archivée peut être informative, contestée, dépassée ou en attente. Un responsable nommé possède une obligation de suivi, pas un pouvoir de transformer la réception en assentiment.

Le transfert de documents exigeait la même prudence. Pour envoyer un Internet-Draft à l’ITU-T comme contribution de l’ISOC, le groupe IETF devait confirmer l’intérêt mutuel, l’utilité de l’envoi et l’exactitude du statut annoncé ; les responsables de domaine validaient ensuite. Ils autorisaient un transfert pour examen, pas la promotion du projet au rang de norme.

Dans l’autre sens, un texte de projet de Recommandation devait rester identifié comme document de travail du groupe d’étude concerné, avec son état de développement et ses contacts. Son habillage en Internet-Draft ne l’intégrait pas magiquement au consensus IETF. À l’époque, ce format était temporaire et expirait après six mois.

RFC 3356 préférait donc qu’un organisme documente intégralement le résultat et que l’autre le cite. Le texte commun ou conjoint était déconseillé parce que les procédures d’approbation et de révision différaient. Une référence reliait les spécifications sans confondre la garde éditoriale.

RFC 2026 décrivait la façon dont l’IETF pouvait référencer une norme ouverte externe ; la Recommandation A.5 jouait un rôle comparable côté ITU-T. L’identité des mots n’abolissait pas la différence entre les chaînes de remplacement, les décisions et les responsables de maintenance.

Les RFC 4052, 4053 et 4691 ont ensuite précisé la gestion des liaisons, le traitement des déclarations et la conduite des représentants. RFC 6756 a remplacé RFC 3356 en 2012 tout en conservant l’idée essentielle : le représentant communique et explique, tandis que l’organisme destinataire garde sa décision.

Ces textes ne prouvent pas que chaque liaison réelle ait été parfaite. Ils ne documentent ici ni conflit précis ni résultat d’interopérabilité. Ils décrivent une surface de contrôle : mandat, message, livraison, traitement, consensus, publication et mise en œuvre doivent produire des preuves différentes.

Un représentant peut être authentique sans être souverain. Une lettre peut être officielle sans être acceptée. C’est précisément parce que le délégué parlait au nom d’une institution que le groupe de travail devait préserver, et montrer, sa propre décision.

Sources