RFC 1366 et le moment où l’allocation régionale est devenue envisageable

Résumé

• La RFC 1366 proposait de distribuer l’enregistrement tout en préservant la coordination centrale de l’IANA et du Registre Internet et en regroupant l’espace de classe C géographiquement pour répondre à la distance de service, à la pénurie liée aux classes et à l’agrégation du routage.
• Le texte et la mise en œuvre européenne précoce montrent une régionalisation réelle, mais n’établissent pas d’exclusivité territoriale permanente, de propriété, de consentement à l’échelle des opérateurs ni de mécanisme complet de remplacement et d’appel.

Le problème mesuré combinait une charge administrative et une tension architecturale. Dans son instantané de juin 1992 par classes, la RFC 1366 comptait 49 créneaux de numéros de réseau de classe A attribués sur 126, 7 354 créneaux de classe B sur 16 383, et 44 014 créneaux de classe C sur 2 097 151. Les réseaux de taille moyenne étaient difficiles à servir efficacement: les numéros de classe B étaient rares, mais attribuer de nombreux réseaux de classe C non liés augmentait les tables de routage. La RFC 1366 répondait en distribuant l’enregistrement, en réservant des blocs de classe C organisés géographiquement, en attribuant des groupes contigus en fonction de projections sur 24 mois, et en maintenant l’IANA et le Registre Internet central comme acteurs de coordination et par défaut.

La contre-preuve la plus forte à tout récit de concurrence régionale ouverte apparaît dans le document lui-même. La RFC 1366 décrivait un registre régional unique par zone géographique comme important pour une sous-attribution efficace et équitable. Elle associait cette préférence à des exigences de reconnaissance régionale, de statut institutionnel, de ressources opérationnelles, de conformité aux directives centrales et de coordination des sous-attributions. En même temps, les abonnés pouvaient toujours contacter le Registre Internet central, qui restait la racine et promettait un service si nécessaire. Le texte proposait donc une concentration au niveau régional avec un recours central, mais ne fournissait pas de frontières régionales fixes, de durée de désignation, de procédure d’accréditation périodique, de dossier de sélection comparatif, de droit de portabilité ni de mécanisme de remplacement publié.

La mise en œuvre européenne s’est déroulée par actes datés et non simultanés. Les documents RIPE situent le début opérationnel du Network Coordination Centre au 1er avril 1992, le décrivent comme agissant en tant que registre délégué à partir du 1er mai, rapportent la demande du Registre Internet central en juillet de traiter les demandes européennes, et datent le transfert automatique de ces demandes au 1er août. À la fin du trimestre de mars 1993, RIPE 87 faisait état de 10 348 numéros de réseau attribués et d’un journal partiel de 143 demandes. RIPE 92 décrivait plus tard plus de 10 000 numéros de réseau pendant la première année de fonctionnement, tandis que RIPE 99 revendiquait rétrospectivement plus de 14 000 pour cette même année et rapportait séparément, à son point d’observation du 25 octobre 1993 après 18 mois, plus de 60 registres de fournisseurs de services et 21 registres de pays non fournisseurs. Les rapports ne fournissent pas de jeu de données figé commun permettant de réconcilier ces totaux.

Le constat circonscrit est lourd de conséquences, mais plus étroit qu’un récit d’origine constitutionnel. La RFC 1366 a traité un problème opérationnel, a ajouté une préférence pour un fournisseur unique au niveau régional, et s’est accompagnée d’une délégation de blocs observable, de réattributions locales, de transmission des demandes, d’échanges de bases de données, d’évaluation des demandes et de délégation DNS inverse en Europe. Il s’agissait d’une RFC informative, non d’un standard Internet ni d’un vote à l’échelle des opérateurs. Le dossier disponible identifie les groupes techniques et de coordination qui ont examiné ou mis en œuvre la conception, mais pas de dénominateur complet des opérateurs concernés, de comparaison des candidats, de registre d’objections, d’appel de désignation, de processus de remplacement ni de preuve que le recours central nominal était utilisable de manière uniforme en pratique.

Octobre 1992: une file d’attente centrale face à un réseau en expansion

La RFC 1366, « Guidelines for Management of IP Address Space »a été rédigée par Elise Gerich de Merit Computer Network et publiée en octobre 1992. Elle annonçait son statut sans ambiguïté: le mémo fournissait des informations à la communauté Internet et ne spécifiait pas un standard Internet. Cette classification ne rendait pas le document trivial. Une RFC informative pouvait coordonner des institutions, définir un plan pratique et influencer les procédures opérationnelles. Ce qu’elle ne pouvait pas fournir uniquement par sa publication, c’était la procédure d’approbation associée à un standard, et encore moins un vote de l’ensemble des réseaux qui dépendraient plus tard du système d’allocation.

Les noms institutionnels entourant le document exigent de la prudence. Le résumé de la RFC 1366 développe FEPG en « Federal Engineering Task Force »; ses remerciements utilisent « Federal Engineering Planning Group »; et laRFC 1367l’appelle « FNC Engineering and Planning Group ». La source est incohérente, de sorte qu’aucune expansion unique ne doit être traitée comme canonique sans ambiguïté. FEPG est l’abréviation la plus sûre.

La RFC 1366 indiquait que le FEPG avait examiné la proposition au nom du Federal Networking Council, aux côtés des coprésidents de l’International Engineering Planning Group et de RIPE. Elle faisait état d’un consensus général parmi ces groupes en faveur des recommandations. Les remerciements attribuaient aux membres du FEPG et de l’IEPG des contributions substantielles, faisaient remonter les concepts à une session Birds of a Feather de l’IETF sur l’adressage à Cambridge (Massachusetts) en juillet 1992, et nommaient Jon Postel et Yakov Rekhter comme relecteurs et contributeurs.

Il s’agit là d’un cadre de création substantiel, mais chaque acteur occupait un rôle limité. Gerich était l’auteure. Le FEPG et le conseil fédéral relevaient d’une structure fédérale de mise en réseau. L’IEPG apportait une participation internationale en matière d’ingénierie et de planification. Une session BoF de l’IETF offrait un lieu pour développer et tester des idées techniques. RIPE était à la fois un groupe de coordination et un acteur de mise en œuvre émergent. L’IANA et le Registre Internet central étaient les acteurs censés réserver l’espace, maintenir la racine, reconnaître les registres et coordonner la délégation. Les fournisseurs de réseau, les abonnés, les registres locaux et les demandeurs étaient des populations concernées, non interchangeables avec les groupes de rédaction et d’examen.

L’expression « consensus général » étaye donc une déclaration attribuée aux relecteurs nommés. La RFC 1366 ne donne aucun nombre de entités, liste de présence, vote, dénominateur d’affiliation ou registre d’objections à partir desquels calculer un soutien plus large. La participation à la discussion n’est pas en soi une approbation; la mise en œuvre n’est pas un vote rétrospectif. Rien dans cette limitation n’efface l’expertise ou l’influence des groupes impliqués. Cela empêche que leur examen soit silencieusement élargi en une autorisation universelle des opérateurs.

Le cas pratique a commencé avec la croissance et l’internationalisation. La RFC 1366 indiquait que la demande de numéros de réseau avait considérablement augmenté au cours des deux années précédentes. Une population mondiale plus diversifiée devait interagir avec un service central d’enregistrement conçu dans un environnement antérieur et plus concentré géographiquement. Des registres situés plus près des demandeurs pourraient fournir un service dans les langues pertinentes et travailler plus efficacement avec les coutumes administratives locales. La distribution, dans ce cadre, réduisait d’abord la distance organisationnelle. Elle n’exigeait pas initialement de prétendre que les régions géographiques possédaient les ressources de numéros ou une juridiction politique sur celles-ci.

L’adressage par classes faisait de la charge de travail plus qu’un problème de service. Le tableau 1 de la RFC 1366 rapportait un instantané de juin 1992 en unités de créneaux de numéros de réseau. Pour la classe A, 49 créneaux attribués divisés par un total de 126 donnent 38,8889 %, ce qui s’arrondit à 39 % plutôt qu’aux 38 % imprimés dans la RFC. Pour la classe B, 7 354 divisés par 16 383 donnent 44,8892 %, ce qui correspond aux 45 % imprimés. Pour la classe C, 44 014 divisés par 2 097 151 donnent 2,0988 %, ce qui correspond aux 2 % imprimés.

La première divergence doit rester visible plutôt que d’être corrigée silencieusement. Plus important encore, l’unité du tableau n’était pas les demandeurs, les organisations, les demandes, les préfixes routés, les refus ou les hôtes utilisés. Elle mesurait les créneaux de numéros de réseau attribués dans les trois classes à un instantané administratif. Elle ne contient aucun dénominateur de demandes, aucun inventaire des attributions restituées par la suite, ni aucune mesure de l’efficacité avec laquelle chaque réseau attribué était utilisé.

Le déséquilibre traduisait néanmoins un véritable problème d’ingénierie. Un réseau de classe C fournissait un petit champ d’hôtes; un réseau de classe B offrait bien plus de capacité que ce dont de nombreuses organisations de taille moyenne avaient besoin. L’attribution libérale de classe B consommait la classe moyenne relativement rare. Remplacer par plusieurs réseaux de classe C annoncés indépendamment économisait des créneaux de classe B mais pouvait ajouter de multiples entrées de routage. La politique d’enregistrement, la conservation des adresses et la croissance des tables de routage étaient devenues liées.

La préoccupation de routage avait un point de référence empirique. LaRFC 1338, publiée en juin 1992, reproduisait une série mensuelle de routes annoncées de Merit contenant 1 525 routes en avril 1990 et 4 775 en février 1992. La différence était de 4 775 moins 1 525, soit 3 250 routes annoncées supplémentaires. Par rapport à la référence d’avril 1990, cela représentait une augmentation de 213,1 % sur 22 mois.

La RFC 1338 identifiait la source comme Merit et reliait les chiffres aux informations de routage sans défaut illustrées par la base de données de routage de NSFNET. Il ne s’agissait pas d’un recensement de tous les routeurs. L’unité d’observation était une route annoncée dans cette série mensuelle aux deux dates d’observation nommées, non une demande d’adresse, un demandeur, un abonné, un opérateur, un réseau attribué ou un utilisateur d’Internet. Sa valeur était de démontrer la pression à un point de vue de routage important, pas de fournir un dénominateur universel.

L’allocation contiguë ne réduisait pas non plus automatiquement la table observée. La RFC 1338 expliquait que les bénéfices de l’agrégation dépendaient du support du routage inter-domaine pour des paires réseau-et-masque arbitraires. L’administration des adresses pouvait préparer des blocs agrégables avant que les routeurs ne les utilisent comme des destinations uniques. Le multihébergement, les changements de fournisseur et les exceptions pouvaient préserver ou réintroduire des routes plus spécifiques. Le plan administratif était donc un prérequis pour l’agrégation, non la preuve que l’agrégation avait déjà été déployée ou que chaque routeur observait le même résultat.

La RFC 1366 réunissait ces pressions en une seule réponse. L’enregistrement serait distribué. Une grande partie de l’espace de numéros de réseau de classe C serait divisée en larges blocs géographiques. Les attributions dans ces blocs utiliseraient des puissances de deux contiguës dimensionnées en fonction des besoins projetés. L’IANA et le Registre Internet central conserveraient des fonctions de coordination, la responsabilité des classes plus étroitement contrôlées et le service là où il n’existait pas de registre régional.

Le document marquait aussi son horizon. Ses recommandations visaient à retarder l’épuisement plutôt qu’à l’empêcher indéfiniment. Une grande partie supérieure de la plage de classe C alors principalement non attribuée devait rester réservée jusqu’à nouvel ordre. Le plan cherchait à maintenir l’architecture existante utilisable pendant que les technologies d’adressage et de routage évoluaient. L’urgence dictait la conception; le texte ne prétendait pas avoir écrit un règlement permanent.

La RFC 1174 avait déjà distribué le service sans abolir le centre

L’architecture précédente était apparue deux ans plus tôt dans laRFC 1174, rédigée par Vinton Cerf et publiée en août 1990. Ce document était également informatif et présentait expressément des recommandations plutôt qu’un standard Internet. Il consignait le point de vue officiel de l’Internet Activities Board dans des recommandations au Federal Networking Council.

La RFC 1174 proposait de conserver des fonctions centralisées d’IANA et de Registre Internet. À l’époque, la fonction IANA était assurée par l’Information Sciences Institute de l’Université de Californie du Sud, tandis que le DDN Network Information Center de SRI International assurait la fonction de Registre Internet pour les numéros de réseau et de système autonome. Le Registre Internet resterait le registre principal et le choix par défaut lorsqu’aucune autorité d’enregistrement déléguée n’avait été identifiée.

La distribution se ferait par délégation contrôlée. Le Registre Internet pourrait allouer des blocs de numéros de réseau et de système autonome à des organisations approuvées par le Coordinating Committee for Intercontinental Research Networking et leur donner le pouvoir d’attribuer plus avant. Les registres candidats devaient rencontrer l’IANA et le Registre Internet, examiner les exigences opérationnelles et documenter le mode de fonctionnement distribué proposé.

La conception de la base de données révèle à quel point cette distribution était limitée. La RFC 1174 recommandait des bases de données d’enregistrement agrégées tenues par le Registre Internet, avec des copies fournies aux registres délégués pour la redondance et l’accès. Les mises à jour, cependant, resteraient centralisées au Registre Internet; des copies complètes pourraient ensuite être redistribuées par transfert de fichiers ou une autre méthode rapide. C’était une architecture de lecture répliquée et de mise à jour centralisée. Elle offrait plusieurs emplacements de service sans supposer que plusieurs rédacteurs indépendants pouvaient modifier en toute sécurité le registre faisant autorité en même temps.

Cette distinction est importante pour l’analyse institutionnelle. Distribution ne signifiait pas que chaque registre délégué possédait un espace de noms autonome ou que le contrôle central de l’unicité disparaissait. Un service local ou régional pouvait recevoir des demandes et exercer l’autorité d’attribution déléguée tandis que les mises à jour autoritatives étaient sérialisées centralement. Le centre restait responsable d’éviter les identifiants en double et de maintenir un enregistrement complet.

La RFC 1174 recommandait également d’abandonner l’ancien statut binaire « connecté ». L’enregistrement était devenu lié à l’autorisation de se connecter aux installations Internet parrainées par le gouvernement fédéral. À mesure que les réseaux commerciaux, universitaires, de recherche, intermédiaires et non américains se multipliaient, cette catégorie binaire ne décrivait plus la variété des accords d’accès et de transit. Le document proposait de collecter des déclarations de politique d’utilisation acceptable, d’accès et de transit tout en permettant aux réseaux enregistrés d’entrer dans la base de données de noms pertinente, indépendamment de la connectivité approuvée par le gouvernement fédéral.

Cela séparait l’administration des numéros de l’application de la politique réseau. Un registre pouvait enregistrer un numéro unique au niveau mondial sans décider de chaque question concernant le routage, l’interconnexion, le transit ou l’utilisation acceptable. Les administrateurs réseau continueraient à prendre ces décisions selon leurs propres politiques. Le registre était une infrastructure de coordination essentielle, mais le contrôle du registre n’incluait pas automatiquement un contrôle complet sur le fonctionnement du réseau.

Les verbes de recommandation restent importants. La RFC 1174 proposait, suggérait et anticipait. Elle n’a pas publié de liste auditée montrant que chaque délégation, processus de réplication ou séparation des politiques avait été mené à bien. Son chemin d’approbation via le CCIRN, l’IANA et le Registre Internet était un canal institutionnel défini, pas un dénominateur de tous les opérateurs qui pourraient être concernés.

La RFC 1366 a hérité de cette architecture plutôt que de la remplacer par des registres territoriaux autonomes. Elle appelait le Registre Internet la racine, le préservait comme choix par défaut dans les régions non couvertes, plaçait les registres distribués sous les directives de l’IANA et du Registre Internet et conservait le contact direct comme une option déclarée. La régionalisation impliquait une véritable délégation et une responsabilité régionale, mais elle restait imbriquée dans une coordination centrale.

Cette structure résiste à deux simplifications opposées. L’une réduit la régionalisation à une décentralisation cosmétique parce que le centre a survécu. Pourtant, les registres régionaux étaient censés exercer une réelle responsabilité de service et de sous-allocation. L’autre traite les blocs géographiques comme des transferts de souveraineté ou de propriété. La RFC 1366 décrivait la réservation, l’allocation, l’attribution, l’enregistrement et la délégation. Elle ne définissait pas un transfert de propriété.

Le mot difficile était « un »

La disposition la plus forte de la RFC 1366 en faveur de la concentration doit être lue directement: elle décrivait « un seul registre régional par zone géographique à ce niveau » comme important pour une sous-allocation efficace et équitable. « Un » s’opposait à des registres régionaux pairs opérant au même niveau sur la même zone géographique. « À ce niveau » laissait place à de nombreux registres fournisseurs de services, de pays ou autres registres locaux au-dessous de l’organisation régionale. Le Registre Internet central restait également au-dessus et pouvait recevoir des approches directes. La singularité au niveau régional était donc réelle, mais elle n’équivalait pas à un bureau unique traitant toutes les demandes ni à la disparition du service central.

Les autres mots fournissaient une justification sans conception complète de la responsabilité. « Régional » désignait une couche administrative, non une législature ou un peuple souverain. « Géographique » associait le service et les blocs d’allocation à de vastes zones du monde tout en laissant non résolus la définition des frontières et les réseaux transrégionaux. « Efficace » faisait vraisemblablement référence à une sous-allocation cohérente, une duplication réduite, une charge centrale moindre et des blocs favorables à l’agrégation, mais la RFC ne contenait aucune étude comparative des coûts. « Équitable » était un objectif déclaré sans métrique d’égalité, audit des décisions, référence de service ou voie d’appel publiés. La phrase établit fortement une préférence pour un fournisseur unique. Elle ne peut, sans preuves supplémentaires, fixer la durée d’une désignation, prouver une exclusivité permanente, établir la propriété ou démontrer le consentement de chaque opérateur dans la zone de service.

La disposition relative au service direct est tout aussi importante. La RFC 1366 disait que les abonnés pouvaient contacter le Registre Internet, pourraient être orientés vers le registre régional selon les circonstances, et pourraient être servis centralement si nécessaire. Cela préservait une racine et un recours nominal. Le document ne définissait pas « nécessaire », ne précisait pas quand l’orientation pouvait être refusée, ne publiait pas d’obligation de réponse pour le centre, ni n’établissait si le service direct fournirait une révision de la décision du registre régional. Un recours au sein de la hiérarchie délégante n’est pas automatiquement une portabilité entre fournisseurs pairs, et une option textuelle n’est pas une preuve d’utilisabilité pratique.

La clause du registre unique mérite ce contrepoids, mais pas une dilution. Traiter le recours central comme une preuve que l’exclusivité était absente reviendrait à mal lire la hiérarchisation proposée. Traiter la préférence régionale comme une concession territoriale irrévocable irait au-delà du langage opérationnel. La RFC 1366 concevait une concentration à un niveau à l’intérieur d’une hiérarchie coordonnée centralement.

Des critères de sélection sans dossier de sélection reproductible

La RFC 1366 essayait de définir ce que devrait être un registre régional plutôt que de simplement nommer une organisation disponible. Elle proposait cinq critères. Ensemble, ils montrent que l’auteur comprenait la délégation comme une décision institutionnelle, et non comme une simple configuration technique. Ils révèlent aussi combien de la procédure de décision restait non formulée.

Premièrement, les « autorités de mise en réseau » de la zone géographique devaient légitimer le candidat. Le terme n’avait pas de dénominateur fourni. Un réseau national de recherche, un ministère, un opérateur, un fournisseur de services, un consortium universitaire, un entité aux normes et un forum d’exploitation de réseaux pouvaient chacun revendiquer un type d’autorité différent. La RFC n’identifiait pas de catégories obligatoires, ne déterminait pas combien d’approbations étaient suffisantes, n’expliquait pas si les objections avaient du poids, ni ne disait comment les revendications contradictoires seraient résolues.

Le texte environnant exigeait aussi que le registre soit impartial et largement reconnu par les fournisseurs de réseau et les abonnés de sa région. « Largement » n’était pas converti en test. Cela pouvait signifier une reconnaissance entre pays, parmi les principaux dorsales, au sein d’un forum de coordination technique ou parmi les organisations déjà connues des évaluateurs. Aucune liste de fournisseurs et d’abonnés n’était jointe, de sorte qu’aucun lecteur ne peut reproduire le taux de reconnaissance ou identifier quelles organisations concernées étaient absentes.

Deuxièmement, un candidat devait être bien établi et posséder une légitimité en dehors de la fonction de registre. Cela réduisait le risque de confier une coordination critique à une organisation dont le seul statut provenait de sa sélection. Des travaux techniques existants, une continuité financière, une maturité organisationnelle et un rôle de coordination reconnu pouvaient tous étayer ce critère. Pourtant, la RFC n’offrait pas de divulgation financière standard, d’examen de gouvernance, d’évaluation des conflits ou de fiche comparative.

Troisièmement, l’organisation devait s’engager à fournir des ressources adéquates pour un service stable, ponctuel et fiable. C’était le critère le plus mesurable via le personnel, les budgets, les délais de réponse, l’exactitude des bases de données, la disponibilité et les dispositions de continuité. Le document ne spécifiait aucun seuil ni aucune conséquence si les performances se dégradaient par la suite.

Quatrièmement, le registre devait attribuer les numéros conformément aux directives de l’IANA et du Registre Internet. Cinquièmement, il devait se coordonner avec le Registre Internet central sur les qualifications et les stratégies de sous-allocation. Ces conditions limitaient l’autonomie régionale. Un registre délégué n’était pas autorisé à construire un système de numérotation incompatible ni à ignorer le registre racine.

La langue et les coutumes locales figuraient dans la justification de la distribution, mais pas dans les cinq critères formels. La RFC 1366 suggérait que des registres géographiquement situés pourraient servir les communautés plus efficacement à ces égards. Elle n’exigeait pas un ensemble particulier de langues, de formulaires traduits, de bureaux locaux ou de couverture de service mesurable. La justification était plausible, en particulier dans un réseau en internationalisation rapide, mais elle n’était pas opérationnalisée comme un test d’accréditation.

La chaîne de décision restait incomplète. L’IANA et le Registre Internet habilitaient le registre; les autorités régionales de mise en réseau le légitimaient; et le candidat acceptait les règles centrales. Le texte ne précise pas qui vérifiait les ressources, comment les candidats étaient comparés, si les acteurs centraux pouvaient en choisir un malgré les objections régionales, si l’un ou l’autre possédait un veto, et ce qui se passait si la reconnaissance déclinait par la suite.

Il n’y avait pas non plus d’appel de désignation publié. Un candidat déçu ne disposait d’aucun processus déclaré pour inspecter l’évaluation ou demander un réexamen. Un abonné pouvait contacter le Registre Internet central, mais ce cheminement opérationnel ne révisait pas nécessairement le statut de l’organisation régionale. La correction du service et le remplacement institutionnel étaient des problèmes distincts, et seul le premier bénéficiait même d’un recours général.

Les critères rendaient donc la délégation régionale plus disciplinée qu’une simple commodité informelle. Ils ne créaient pas un régime d’accréditation et de renouvellement reproductible. Le dossier de création étaye une sélection par des institutions de coordination identifiables selon des principes établis; il laisse sans réponse l’étendue, la durée et la contestabilité du mandat.

Les blocs géographiques étaient une technique d’allocation, pas un territoire

La RFC 1366 proposait de diviser une partie de la plage de classe C en huit blocs égaux. Après avoir observé que les préfixes 192 et 193 étaient déjà utilisés tandis qu’une grande partie de 194 à 223 restait non attribuée, elle réservait 208 à 223 jusqu’à nouvel ordre et organisait 192 à 207 en paires de blocs/8.

La RFC décrivait chaque paire comme contenant 131 072 « adresses », mais l’unité de classe opérationnelle était de 131 072 créneaux de numéros de réseau de classe C. Chaque créneau correspondait nominalement à une plage de taille/24de 256 valeurs IPv4 brutes. En multipliant 131 072 par 256, on obtient 33 554 432 valeurs brutes dans chaque bloc de deux/8. Par rapport au dénominateur de classe C de la RFC 1366 de 2 097 151 créneaux de numéros de réseau, 131 072 créneaux représentaient environ 6,25 %, ce qui correspond à la description arrondie du document d’environ 6 %.

Les étiquettes étaient provisoires et larges: 192-193 était multirégional; 194-195 était l’Europe; 196-197 était « Autres »; 198-199 était l’Amérique du Nord; 200-201 était l’Amérique centrale et du Sud; 202-203 était le pourtour du Pacifique; et 204-207 fournissaient deux autres blocs « Autres ». Il ne s’agissait pas d’une carte mûre de cinq institutions permanentes. Elle contenait quatre zones géographiques nommées, une plage multirégionale et trois plages flexibles.

Là où un registre régional qualifié existait, la responsabilité principale d’allocation au sein du bloc concerné pouvait lui être déléguée. Là où il n’en existait pas, le Registre Internet central poursuivrait les attributions tout en suivant les divisions géographiques. La géographie pouvait donc façonner l’allocation avant qu’une institution régionale ait été sélectionnée. Le plan de blocs et la carte de couverture institutionnelle étaient liés mais non identiques.

Les attributions au sein d’un bloc devaient utiliser des puissances de deux contiguës en fonction du besoin projeté de l’abonné sur 24 mois. La séquence ordinaire était un réseau de classe C pour moins de 256 adresses, deux réseaux contigus pour moins de 512, quatre pour moins de 1 024, huit pour moins de 2 048 et seize pour moins de 4 096. Il s’agissait de règles de dimensionnement pour une attribution dans le cadre du plan, non de décomptes de demandes, de demandeurs ou de décisions réussies.

Les adresses brutes et les hôtes utilisables doivent être distingués. Un/24contient 256 valeurs IPv4 brutes. Selon le traitement conventionnel de l’époque, les identifiants d’hôte tout à zéro et tout à un n’étaient pas disponibles pour les hôtes ordinaires, laissant 254 identifiants d’hôte utilisables. Seize/24contigus contiennent donc 4 096 valeurs brutes mais 4 064 hôtes conventionnellement utilisables. L’exemple normal de classe C contiguë de la RFC 1366 s’arrêtait à seize réseaux et orientait les besoins supérieurs à 4 096 adresses uniques vers une probable considération de classe B.

Le formulaire européen publié plus tard sous le nom deRIPE 83affichait un exemple allant jusqu’à 32 réseaux de classe C. Dans la convention d’hôtes de ce formulaire, 32 multiplié par 254 donnait 8 128 hôtes utilisables; les mêmes 32/24contenaient 8 192 valeurs brutes. La comparaison montre une continuité dans le dimensionnement par puissances de deux, mais pas un seuil supérieur identique. Un formulaire utilisé dans la pratique régionale pouvait étendre l’option de classe C affichée au-delà de l’exemple ordinaire de seize réseaux de la RFC 1366.

La classe B restait contrôlée centralement dans la RFC 1366. Les conditions de base du document exigeaient plus de 32 sous-réseaux et plus de 4 096 hôtes, avec une considération au cas par cas lorsque les blocs de classe C n’étaient pas pratiques. Un registre régional pouvait aider à l’évaluation, mais l’IANA et le Registre Internet conservaient la responsabilité de la classe. La régionalisation était donc substantielle sans être exhaustive pour toutes les catégories d’adresses.

Le plan géographique avait aussi des limites de routage. L’agrégation fonctionne le plus proprement lorsque la hiérarchie d’allocation et la topologie de routage s’alignent. Les fournisseurs peuvent traverser les frontières, les organisations peuvent être multi-hébergées, les clients peuvent changer de fournisseur, et les réseaux internationaux peuvent couvrir de vastes régions. La RFC 1338 reconnaissait que le multihébergement et les changements de fournisseur pouvaient nécessiter des exceptions ou une renumérotation. Les propres catégories multirégionale et « Autres » de la RFC 1366 reconnaissaient qu’une carte politique bien ordonnée ne pouvait pas contenir tous les arrangements de réseau.

Rien dans le texte opérationnel n’accordait la propriété d’un bloc à un registre ou à une population. Une étiquette géographique organisait la responsabilité administrative et préparait l’espace d’adresses pour l’agrégation. Ce n’était ni un titre de propriété ni une frontière légale. Les conséquences pratiques pouvaient néanmoins être considérables: une fois les registres, les demandeurs, les bases de données et les blocs organisés régionalement, les choix futurs se feraient à l’intérieur de cette structure. L’influence institutionnelle, cependant, est analytiquement distincte de la propriété.

La RFC 1367 a placé des dates proposées à côté du plan

Le calendrier compagnon de la RFC 1366, laRFC 1367, a été rédigé par Claudio Topolcic et publié en octobre 1992. Il était également informatif. Son langage était inhabituellement clair sur le statut: il suggérait un calendrier, appelait ce calendrier un brouillon, et disait qu’il avait été assemblé à partir de la session sur l’adressage de l’IETF de juillet 1992 et de discussions avec un certain nombre — mais pas tous — de parties compétentes et intéressées, y compris l’IANA et le Registre Internet.

La première échéance, le 31 octobre 1992, demandait que les critères initiaux de registre régional soient en place et que l’IANA accepte les demandes des registres potentiels. Les numéros de classe A étaient décrits comme pratiquement impossibles à obtenir. Les numéros de classe B exigeraient une justification raisonnable, les blocs de classe C étant préférés lorsque c’était possible. L’allocation de classe C suivrait le plan d’adressage, le Registre Internet central agissant là où aucun registre régional n’avait été désigné.

Un examen et un éventuel réajustement étaient prévus pour le 14 février 1993. Pour le 15 avril, le Registre Internet devait commencer à allouer tous les réseaux selon le plan d’adressage dans des blocs de classe C de taille appropriée, tandis que les numéros de classe B deviendraient plus difficiles à obtenir. La dernière date indiquée, le 6 juin 1993, était la disponibilité prévue d’un mécanisme d’agrégation d’adresses sur Internet.

Ces dates décrivent une séquence prévue et un niveau administratif: critères et réception des candidatures à l’IANA, poursuite de l’allocation centrale là où la couverture était absente, examen plus strict de la classe B, utilisation plus large de blocs de classe C contigus et support de routage anticipé. La RFC 1367 ne contenait pas de rapports d’achèvement pour aucune de ces étapes. Son invitation à une discussion ouverte, sa consultation incomplète et son réajustement explicite résistent tous à un traitement comme mandat auto-exécutoire.

La mise en œuvre doit être établie ailleurs et fonction par fonction. Un bloc délégué, une demande transmise, une mise à jour de base de données, une réattribution locale, une délégation DNS inverse, une évaluation de demande et une route agrégée étaient des actes différents. Ils ne se sont pas nécessairement produits à la même date et ne prouvent pas la réalisation de chaque jalon prévu.

L’Europe mettait en œuvre par morceaux

L’Europe fournit la preuve immédiate la plus claire parce que la pratique régionale se développait avant l’apparition de la RFC 1366. Le dossier n’est pas une simple chaîne où une RFC a été publiée et une région auparavant inactive a obéi. Les procédures opérationnelles, les décisions du registre central, la coordination de RIPE et le travail sur la RFC se chevauchaient.

RIPE 65, version 0.6 datée du 1er juillet 1992, disait que le RIPE Network Coordination Centre avait agi comme registre délégué pour les numéros de réseau IP européens depuis le 1er mai. Il décrivait une politique d’allocation aux fournisseurs de services, aux centres d’information réseau et aux centres d’opérations réseau plutôt que directement aux organisations individuelles. Ces intermédiaires réattribueraient les numéros aux demandeurs.

L’examen rétrospectif d’octobre 1993 fournit une séquence distincte.RIPE 99, daté du 25 octobre 1993 et examinant les 18 premiers mois du NCC, plaçait son début opérationnel au 1er avril 1992. Il disait que le Registre Internet central avait demandé au RIPE NCC en juillet 1992 de traiter toutes les demandes des organisations européennes. Après consultation avec le président de RIPE et les groupes de travail concernés, le NCC avait accepté malgré des procédures incomplètes. À partir du 1er août, les demandes européennes reçues centralement par courriel ou courrier étaient transmises au RIPE NCC.

Ces dates peuvent décrire différentes fonctions sans contradiction. Les opérations ont commencé en avril; un certain travail de registre délégué a été signalé à partir de mai; une demande centrale de traitement exhaustif pour l’Europe est arrivée en juillet; la transmission systématique a commencé en août. La « délégation » pouvait englober la réception de blocs, la réattribution locale, l’examen de certaines demandes, les tâches de base de données ou le fait de devenir la destination normale de réception. Les documents ne réduisent pas ces actes à une seule date de transfert universelle.

RIPE 72, version 0.7 datée du 16 octobre 1992, décrivait à nouveau l’activité de registre délégué à partir du 1er mai. Il documentait le transfert de blocs complets de classe C vers les fournisseurs de services et les centres de réseau locaux, le retour de l’espace inutilisé sur demande, la communication des réattributions dans la base de données RIPE, l’évitement du stockage, et des allocations contiguës en puissances de deux alignées sur des frontières de bits appropriées. La procédure anticipait l’agrégation mais disait aussi que le supernetting n’avait pas encore été formellement adopté. La compatibilité procédurale était présente avant le déploiement universel du routage.

La hiérarchie visible pour un demandeur était documentée dans RIPE 83, daté du 23 mars 1993. Le formulaire disait que le processus autrefois centralisé en Europe avait été remplacé par un système distribué: le registre mondial déléguait des blocs au RIPE NCC, le RIPE NCC déléguait aux registres locaux, et les demandeurs s’adressaient généralement à leur fournisseur de services ou à un registre local non fournisseur. Les demandes de classe B commençaient localement mais étaient transmises au RIPE NCC pour examen si le registre local les jugeait justifiées.

Le formulaire demandait les nombres actuels de machines et de sous-réseaux ainsi que les projections à un et deux ans. Il demandait des informations sur la connectivité, les numéros IP existants, les pays d’exploitation prévus et la structure du réseau. Les données d’enregistrement administratif entreraient dans la base de données publique RIPE, tandis que les informations techniques utilisées pour l’évaluation étaient décrites comme confidentielles. C’est une preuve solide d’un cheminement administratif vivant. Un formulaire, cependant, enregistre les données requises et la procédure déclarée plutôt que la distribution des résultats.

RIPE 83 rend également l’unité d’allocation visible. Ses exemples utilisaient des calculs d’hôtes utilisables de 254, 508, 1 016, 2 032, 4 064 et 8 128 pour un, deux, quatre, huit, seize et 32 réseaux de classe C. Cette séquence diffère des totaux d’adresses brutes de 256 à 8 192. Le plus grand exemple de classe C affiché dépassait le plafond ordinaire de seize réseaux de la RFC 1366, montrant que la mise en œuvre précoce pouvait préserver le mécanisme binaire tout en ajustant sa plage pratique.

La preuve de charge de travail délimitée la plus détaillée provient deRIPE 87, le rapport trimestriel de mars 1993. Pour le trimestre considéré, il indiquait que 143 demandes avaient été reçues. Les canaux de réception imprimés étaient 51 du Registre Internet mondial, 86 envoyées directement au RIPE NCC et 5 reçues des registres locaux. Ces sous-totaux totalisent 142, et non 143. Le rapport ne fournit pas de quatrième catégorie ni de correction qui réconcilie la différence d’une demande.

RIPE 87 excluait expressément les simples orientations où un demandeur était simplement dirigé vers le registre local approprié sans que le RIPE NCC reçoive une demande. Le total de 143 n’est donc pas un dénominateur pour toutes les demandes d’adresses européennes, toutes les demandes de registre local ou toutes les organisations cherchant des numéros pendant le trimestre. Les 86 soumissions directes ne peuvent pas non plus établir un contournement réussi du système régional: il s’agissait de demandes reçues par le centre régional, non la preuve qu’un demandeur évitait l’administration régionale ou obtenait un service central.

Le même journal trimestriel rapportait des mesures de délai de réponse pour sa population de demandes enregistrées. Il disait que 82,5 % des demandes recevaient une réponse — pas seulement un accusé de réception — le jour même de leur réception, et que 97,9 % recevaient une réponse dans les sept jours civils suivant la réception par le RIPE NCC. Il rapportait séparément des délais moyens écoulés d’un peu moins de cinq jours pour une allocation de classe C traitée par le NCC et d’un peu moins de dix jours pour une allocation de classe B.

Ces délais appartiennent au trimestre de rapport de mars 1993 et aux populations décrites par RIPE 87. Le rapport ne publiait pas les effectifs sous-jacents pour chaque catégorie de délai, ne distinguait pas chaque type de résultat, n’incluait pas les orientations simples et ne mesurait pas les demandes traitées entièrement par les registres locaux. Une réponse n’est pas nécessairement une allocation, et une statistique de service trimestrielle n’est pas une mesure comparative de tous les arrangements de registre possibles.

RIPE 87 disait également que plus de 90 % des cas de classe B évalués étaient jugés non justifiés selon les critères convenus avec le registre mondial et l’IANA. Il ne précisait pas combien de cas de classe B étaient évalués, de sorte que le numérateur ne peut pas être récupéré à partir du pourcentage. Dans la procédure décrite, ces cas étaient transmis au registre local approprié pour une attribution de classe C. « Non justifié » selon les critères de classe B ne doit pas être converti en un registre complet de refus, de préjudice pour le demandeur, d’appels ou d’échec final à obtenir un espace d’adresses.

La section sur l’espace d’adresses de RIPE 87 rapportait que, pendant le trimestre, le RIPE NCC avait attribué 14 numéros de réseau de classe B, délégué 32 blocs de numéros de réseau de classe C et réservé 15 blocs de classe C. Il disait que les registres européens avaient attribué 3 235 réseaux de classe C pendant le trimestre, portant le total déclaré à 10 348 numéros de réseau attribués à la fin du trimestre de mars 1993. Ce sont des unités administratives à différents niveaux: numéros de réseau de classe B individuels, blocs délégués ou réservés, et numéros de réseau de classe C attribués. Aucun n’est un décompte de demandeurs.

RIPE 87 enregistre également un acte de mise en œuvre distinct dans le système de noms. Il disait que la zone DNS inverse 193.in-addr.arpa avait été déléguée au RIPE NCC le 16 mars 1993 et que 11 sous-domaines avaient ensuite été délégués à des registres locaux détenant des blocs de classe C au point d’observation du rapport. L’unité était les sous-domaines DNS inverses sous cette zone, non les demandes d’adresses ou les décisions d’allocation. Cela démontre une hiérarchie opérationnelle au-delà du registre d’attribution sans prouver la réalisation du jalon de routage de la RFC 1367.

Les totaux annuels et rétrospectifs nécessitent un traitement séparé.RIPE 92, publié le 3 septembre 1993 sous le titre « The First Year of the RIPE NCC », décrivait l’année d’exploitation d’avril 1992 à mars 1993 et disait que plus de 10 000 numéros de réseau IP avaient été attribués. L’unité était les numéros de réseau attribués via le système de registre européen, non les valeurs IPv4 brutes ou les organisations demandeuses. Son énoncé arrondi est largement compatible avec les 10 348 de RIPE 87 à la fin du trimestre de mars.

RIPE 99 a déclaré plus tard qu’après un an de fonctionnement, le système de registre européen avait attribué plus de 14 000 numéros de réseau IP. C’est également une affirmation rétrospective sur la première année, mais elle est matériellement supérieure aux 10 348 de RIPE 87 et aux « plus de 10 000 » de RIPE 92. Les rapports disponibles ne fournissent pas de jeu de données figé commun, de date de clôture, de traitement des entrées historiques, de règle de compilation rétrospective ou de numérateur exact suffisant pour réconcilier les trois chiffres. Le compte rendu prudent préserve chaque source, date, fenêtre et unité plutôt que de fabriquer un total combiné.

Les décomptes de registres de RIPE 99 se réfèrent à un point d’observation différent. Au 25 octobre 1993, après 18 mois de fonctionnement du NCC, il disait que le système distribué était alors en place avec plus de 60 registres de fournisseurs de services et 21 registres de pays non fournisseurs de services. Ce sont les registres signalés comme existant à la date d’examen d’octobre. Ils ne doivent pas être déplacés en arrière et étiquetés comme des décomptes de la première année.

RIPE 99 a été rédigé par un comité d’examen de RIPE et approuvé comme représentant les vues de RIPE. Il louait l’exactitude et la rapidité du NCC et décrivait la fonction de registre comme extrêmement bien gérée. C’est une preuve contemporaine précieuse d’une institution proche du travail. Ce n’est pas une enquête indépendante de chaque opérateur européen. Les références du rapport au consentement au sein de RIPE concernent la circonscription de RIPE et ses processus internes; elles ne fournissent pas un dénominateur pour tous les fournisseurs, abonnés ou demandeurs touchés par la hiérarchie de registre.

L’examen documentait également l’improvisation. Le plan d’activité du NCC de mai 1991 n’incluait pas explicitement le rôle de registre IP européen. Selon RIPE 99, des activités au-delà du plan original ont été proposées, discutées au sein de RIPE et mises en œuvre lorsqu’une conclusion positive était atteinte. La demande centrale de juillet 1992 a accéléré la fonction de registre avant que chaque procédure ne soit réglée. C’est la preuve d’une adaptation par un organe de coordination actif plutôt que la preuve d’un mandat régional complet préexistant.

Au niveau des blocs supérieurs, leRegistre d’espace d’adresses IPv4 de l’IANAactuel, dans la version mise à jour le 2025-10-10, répertorie 193/8, 194/8 et 195/8 sous RIPE NCC avec des dates1993-05. Ce sont des dates au niveau du mois dans un registre actuel. Elles ne constituent pas un instantané contemporain de mai 1993, des dates exactes de sous-allocation, des enregistrements de transfert, des fichiers de demande ou une preuve de motivation.

La ligne actuelle pour 193/8 est néanmoins pertinente pour la carte publiée. La RFC 1366 avait placé 192-193 dans un bloc multirégional tout en identifiant 194-195 pour l’Europe. Le traitement ultérieur de 193/8 par le registre sous RIPE NCC montre que la carte d’octobre 1992 n’a pas été appliquée comme une partition immuable. Elle ne peut pas à elle seule expliquer le processus de décision ni dater chaque délégation de niveau inférieur.

Pris dans leur ensemble, les documents européens montrent la mise en œuvre comme une chaîne d’actes séparés: exploitation d’un centre de coordination, réception de blocs, réattribution via des registres locaux, transmission des demandes, évaluation des requêtes, échange de données d’enregistrement, délégation de la responsabilité du DNS inverse et enregistrement de l’administration des adresses au plus haut niveau. La chaîne était réelle, mais ni simultanée ni réductible à une seule date de mandat.

Ce que le dossier opérationnel établit

La preuve de mise en œuvre la plus forte concerne le service distribué. La RFC 1174 recommandait la délégation; la RFC 1366 fournissait les qualifications régionales et un plan de blocs géographiques; RIPE 65 et RIPE 72 documentaient des procédures d’allocation fonctionnelles; RIPE 83 orientait les demandeurs à travers une hiérarchie mondiale-régionale-locale; et RIPE 87 mesurait une partie de la charge de travail résultante. C’est plus qu’une aspiration institutionnelle.

Le recours central a un profil de preuve différent. La RFC 1366 promettait que le Registre Internet resterait prêt à servir les abonnés si nécessaire. RIPE 99 disait que les demandes européennes arrivant centralement étaient transmises au RIPE NCC à partir du 1er août 1992. RIPE 87 a ensuite enregistré 51 demandes trimestrielles reçues du registre mondial, mais celles-ci étaient transmises dans le processus régional. Le dossier examiné manque d’un journal complet des demandeurs servis directement par le centre, orientés régionalement, bénéficiant d’une exception ou autorisés à insister sur un traitement central.

L’allocation contiguë est également passée de la proposition à la procédure. Les documents RIPE utilisaient des puissances de deux, des blocs alignés et une demande projetée. Pourtant, la préparation administrative et l’effet sur le routage restaient distincts. Les rapports d’allocation ne mesurent pas si un agrégat a été annoncé, accepté par un routeur particulier, divisé par le multihébergement ou supplanté par des routes plus spécifiques. La série Merit décrivait la pression de routage à un point de vue identifié; les registres d’enregistrement décrivaient l’activité d’allocation.

La compétence opérationnelle a reçu un certain soutien rétrospectif. RIPE 87 publiait des délais de réponse et des mesures de charge de travail, tandis que RIPE 99 louait l’exactitude et la rapidité. Ces observations concernent les premières performances du RIPE NCC. La RFC 1366 n’avait pas fixé de repères numériques avant la sélection, de sorte que le succès ultérieur ne peut pas reconstruire l’évaluation des candidats ni établir quelles alternatives ont été envisagées.

La reconnaissance est moins reproductible. RIPE avait un rôle de coordination établi, des organisations participantes et un cadre formel via RARE. Ces faits correspondent à la préférence de la RFC 1366 pour un statut en dehors de la fonction de registre. Il manque une liste complète des fournisseurs et abonnés régionaux, un registre des soutiens et des objections, les soumissions de candidats concurrents et un test documenté pour « largement reconnu ».

L’Europe montre aussi comment un registre régional unique pouvait coexister avec une pluralité substantielle. Les registres de fournisseurs de services et de pays traitaient les demandeurs sous le RIPE NCC. Le centre coordonnait les blocs, les procédures et les relations de base de données au niveau régional. La disposition du registre unique concentrait donc l’autorité à un niveau particulier plutôt que de centraliser chaque interaction avec les clients.

Ce que le dossier opérationnel ne peut pas régler, c’est la durée et le recours attachés à cette concentration. Les documents examinés ne révèlent pas de période de désignation fixe, d’accréditation périodique, de portabilité pour les demandeurs entre fournisseurs régionaux pairs, de déclencheur de remplacement automatique ou de procédure transparente pour établir un second registre au même niveau. Une dépendance continue peut renforcer la légitimité pratique au fil du temps, mais elle ne recrée pas un processus d’autorisation omis au moment de la sélection.

Acteurs, autorité et le recours manquant

L’autorité dans cette histoire était fonctionnelle avant d’être générale. L’IANA coordonnait les identifiants numériques. Le Registre Internet maintenait les fonctions centrales d’enregistrement et d’attribution. Les groupes de planification fédéraux et internationaux examinaient les propositions. Les entités de l’IETF développaient les mécanismes techniques. RIPE coordonnait les réseaux européens entités. Le RIPE NCC et les registres locaux traitaient le travail administratif. Les opérateurs déterminaient le routage et l’interconnexion; les demandeurs cherchaient des ressources selon les procédures en résultant.

L’IANA et le Registre Internet possédaient la capacité pratique de réserver des blocs, de reconnaître un registre, de maintenir l’enregistrement racine et d’acheminer les demandes via un chemin de service choisi. Cette capacité est une preuve d’autorité opérationnelle à l’intérieur du système alors en usage. Ce n’est pas un enregistrement que chaque opérateur présent ou futur a accordé un mandat institutionnel illimité.

L’examen du FEPG reliait la proposition à la coordination fédérale des réseaux. L’IEPG et la discussion sur l’adressage de l’IETF élargissaient le cadre technique. RIPE apportait l’expertise régionale et l’expérience de mise en œuvre. Chacun était significatif; aucun, selon les preuves examinées, ne représentait un électorat mondial dénombré.

Le double rôle de RIPE ne mérite ni rejet ni exagération. Il a contribué à l’examen tandis que son centre de coordination devenait le registre européen. Les institutions les plus proches de la mise en œuvre possèdent souvent l’expertise la plus pertinente. Elles peuvent aussi devenir bénéficiaires de l’architecture qu’elles contribuent à façonner. Les rapports de RIPE sont des preuves primaires de ses procédures, de son activité et de son point de vue institutionnel, non une preuve indépendante de consentement à travers une région indéfinie.

Les demandes montrent une dépendance à un chemin de service, mais soumettre une demande n’approuve pas nécessairement chaque caractéristique de la structure institutionnelle. Un opérateur peut se conformer parce que le processus est utile, reconnu ou pratiquement inévitable. La communication des bases de données, la coopération en matière de routage et la participation des registres locaux peuvent construire une légitimité par la pratique. Ils répondent néanmoins à une question différente de celle de savoir qui pouvait désigner, auditer ou remplacer l’organisation régionale.

Le dossier examiné ici ne contient pas d’archives complètes de rédaction de l’auteur, de correspondance du FEPG ou de l’IEPG, de transcription de la session BoF sur l’adressage de l’IETF, de comparaison des registres candidats, de dénominateur d’approbation régionale, de registre d’objections ou de dossier d’appel de désignation. Cette lacune ne doit pas être convertie en opposition cachée. Elle empêche également que le silence devienne un consensus mesuré.

Un historique d’autorisation plus solide nécessiterait des preuves reliant les institutions nommées aux circonscriptions pour lesquelles elles prétendaient agir: soumissions de candidats, dossiers d’évaluation, correspondance avec les fournisseurs et les abonnés, objections documentées, exceptions au service central, discussions sur le remplacement et décisions expliquant comment la reconnaissance a été évaluée. Sans un tel matériel, le dossier précoce établit un arrangement techniquement raisonné et opérationnellement mis en œuvre tout en laissant son mandat complet incomplet.

L’alternative réalisable à l’époque n’était pas un registre partagé moderne

Un contrefactuel utile commence par accepter la nécessité de la distribution. En 1992, un service de réception purement central était de plus en plus difficile à concilier avec la croissance internationale, la langue, les procédures locales et l’échelle administrative. La question plus précise est de savoir si le service distribué exigeait un fournisseur unique au niveau régional.

Une alternative réalisable à l’époque suivait l’architecture réelle de base de données de la RFC 1174. Plusieurs services de réception ou d’attribution accrédités auraient pu traiter les demandeurs au sein d’une vaste région tandis que le Registre Internet central sérialisait les mises à jour faisant autorité. Les services délégués pourraient recevoir des pools d’adresses distincts, appliquer des critères communs et soumettre les modifications à une file d’attente de mise à jour centrale. Des copies répliquées pourraient ensuite être redistribuées pour l’accès et la redondance.

Il ne s’agissait pas d’une véritable réplication multi-écrivains. Le Registre Internet central resterait l’autorité ordonnant les modifications et empêchant les attributions en double. Une telle conception pourrait offrir de multiples interfaces de service sans exiger que plusieurs institutions modifient le même état faisant autorité en même temps. Son goulot d’étranglement serait le chemin de mise à jour central: la latence, la reprise après panne et la réconciliation après des soumissions retardées exigeraient toujours des procédures explicites.

La prévention des collisions dépendrait soit d’un partitionnement strict des pools, soit d’une confirmation centrale avant attribution. Avec des blocs partitionnés, chaque service pourrait agir dans sa plage sans entrer en collision avec un pair, mais la capacité inutilisée pourrait se retrouver bloquée et le rééquilibrage nécessiterait des transferts coordonnés. Avec une confirmation centrale, les pools pourraient être plus flexibles, mais les demandeurs et les registres subiraient la latence des mises à jour et la vulnérabilité à une interruption centrale.

L’agrégation introduisait un autre compromis. Attribuer à chaque service un pool contigu distinct pourrait préserver de larges agrégats. Permettre à un demandeur de changer de fournisseur tout en conservant ses adresses pourrait percer des trous dans ces agrégats ou exiger un routage plus spécifique. Exiger une renumérotation lors d’un changement protégerait l’agrégation au prix d’un travail de transition pour le demandeur. L’alternative nécessitait donc une règle pour la continuité des adresses, et pas seulement un guichet supplémentaire.

Le service en langue locale pourrait s’améliorer grâce à des fournisseurs spécialisés, en particulier dans une région trop diverse pour qu’un seul centre serve également. Il pourrait aussi devenir inégal: des communautés rentables ou bien connectées pourraient attirer plusieurs registres tandis que d’autres recevraient peu de couverture. L’accréditation devrait évaluer la portée géographique et linguistique, sans supposer que la concurrence se répartirait équitablement.

Des critères communs créeraient leur propre problème de gouvernance. Plusieurs fournisseurs pourraient interpréter différemment les besoins projetés ou la justification de la classe B, encourageant les demandeurs à choisir le service le plus permissif. Empêcher un tel forum shopping exigerait des audits, des directives partagées, un examen des résultats divergents et un pouvoir de corriger ou de suspendre les fournisseurs. La pluralité réduit la dépendance à un seul registre seulement si la couche d’accréditation et d’audit est crédible.

Le recours central aurait également besoin d’une définition. Si la racine acceptait les demandes chaque fois qu’un fournisseur régional était lent ou restrictif, elle pourrait devenir un service concurrent et saper la planification régionale. Si elle renvoyait automatiquement les demandeurs, elle offrirait peu de redondance pratique. Une alternative viable devait préciser quand le centre interviendrait, s’il pouvait passer outre une décision régionale, et si le service direct était une exception opérationnelle ou un véritable chemin de révision.

La reprise après défaillance est tout aussi concrète. Un service régional pourrait perdre du personnel, du financement, de la connectivité ou l’intégrité de sa base de données. Dans un modèle multi-services, un autre fournisseur accrédité pourrait reprendre la réception, mais les enregistrements faisant autorité, les demandes en cours et les pools inutilisés devraient être transférés en toute sécurité. Dans le modèle à registre unique, le centre ou les registres locaux pourraient assurer la continuité, pourtant la RFC 1366 ne décrivait pas de processus de passation testé. Aucune des deux structures ne rendait la défaillance institutionnelle sans coût.

Le remplacement et l’appel doivent être distingués. Un demandeur pourrait contester une décision d’allocation individuelle sans demander le retrait du registre. Un fournisseur ou une circonscription régionale pourrait contester la performance ou la reconnaissance du registre sans contester une demande particulière. Le premier problème appelle une révision des critères et des preuves; le second appelle des règles d’accréditation, d’audit et de remplacement. La disposition de contact direct central de la RFC 1366 n’abordait que partiellement le premier et ne définissait pas le second.

Une seconde alternative, plus ambitieuse, aurait permis une véritable réplication multi-écrivains: plusieurs registres mettant à jour l’état faisant autorité avec une réconciliation ultérieure. Les documents de la période examinée n’établissent pas qu’il s’agissait de l’architecture prévue. Elle aurait exigé des partitions d’allocation sans conflit ou un ordonnancement robuste des transactions, un échange de mises à jour authentifié, la détection d’enregistrements divergents, la reprise après des partitions réseau et une règle déterminant quel écrivain prévalait. Traiter un registre partagé à consonance moderne comme une option sans effort en 1992 effacerait la raison technique pour laquelle la RFC 1174 conservait des mises à jour centralisées.

La conception régionale à registre unique réduisait plusieurs coûts de coordination. Une seule organisation pouvait gérer un bloc cohérent, maintenir une relation unique avec l’IANA et le Registre Internet, appliquer une procédure régionale unique et coordonner la hiérarchie des registres inférieurs. Ses registres locaux pouvaient toujours fournir un service spécifique au fournisseur, au niveau du pays et linguistique. Cela rendait la singularité au niveau régional compatible avec la distribution en dessous.

Le coût était une dépendance concentrée. Si l’organisation régionale devenait lente, incohérente, sous-financée ou insuffisamment représentative, les demandeurs manquaient d’une alternative déclarée entre pairs. Le service central offrait une redondance potentielle, mais l’orientation pouvait renvoyer le demandeur au même niveau régional. La conception nécessitait donc une révision continue et une possibilité de remplacement au moins autant que des critères d’entrée.

La RFC 1366 articulait l’avantage de coordination plus complètement que le mécanisme de responsabilisation. Elle identifiait la stabilité, la rapidité, la fiabilité et la reconnaissance comme des qualités souhaitables mais ne définissait pas comment elles seraient surveillées, quelles preuves comptaient, quand une désignation expirerait, ou comment un nouveau registre pourrait remplacer un titulaire.

Le contrefactuel ne prouve pas que plusieurs fournisseurs auraient produit de meilleurs résultats. Des services accrédités multiples auraient entraîné des coûts réels en ordonnancement des mises à jour, gestion des pools, agrégation, renumérotation, audit et transition. Ce que la comparaison révèle est plus étroit: le service régional, l’unicité centrale et la concentration en un fournisseur unique étaient trois choix séparables. Le besoin opérationnel des deux premiers n’établissait pas par lui-même la nécessité permanente du troisième.

Le moment où l’allocation régionale est devenue envisageable

La RFC 1366 a rendu l’allocation régionale concrète en reliant des problèmes qui ne pouvaient plus être traités indépendamment. La croissance internationale mettait à rude épreuve une interface de service unique. La langue et la proximité administrative favorisaient la distribution. La rareté de la classe B rendait les vieilles habitudes de dimensionnement insoutenables. Les attributions multiples de classe C menaçaient la croissance du routage à moins que les blocs ne soient contigus et compatibles avec l’agrégation.

La RFC 1174 avait fourni l’architecture sous-jacente: conserver l’IANA et le Registre Internet central, déléguer les fonctions d’attribution par l’intermédiaire d’organisations approuvées, distribuer des copies de la base de données tout en centralisant les mises à jour, et séparer l’enregistrement de l’application de la politique réseau. La RFC 1366 a ajouté des qualifications régionales, un plan géographique de classe C, des seuils de dimensionnement et une préférence expresse pour un registre unique au niveau régional. La RFC 1367 a placé des dates proposées à côté de ce plan sans prouver que chaque jalon s’est réalisé.

L’Europe fournit la preuve la plus solide de la pratique. Entre avril 1992 et octobre 1993, le dossier public documente un centre de coordination opérationnel, des procédures de registre délégué, le transfert central des demandes, des registres de fournisseurs de services et de pays, la délégation de blocs de classe C, des formulaires de demandeur, l’évaluation des requêtes, la coordination des bases de données, la délégation DNS inverse et des volumes d’attribution substantiels rapportés. Les actes se sont produits à différentes dates et à différents niveaux administratifs. Leurs statistiques ne peuvent pas être réduites à un seul registre de demandes, de demandeurs ou d’autorisation.

La clause du registre unique appartient à l’intérieur de cette réalisation opérationnelle, non à l’extérieur. Elle offrait un moyen de coordonner les blocs et les procédures tout en permettant de nombreux points de service locaux. Elle concentrait aussi la dépendance au niveau régional. La RFC 1366 préservait une racine et un recours centraux mais laissait incertaines les conditions pratiques de la révision centrale.

Le dossier qui en résulte s’arrête à une frontière claire. Un problème opérationnel a été traité. Une concentration institutionnelle a été ajoutée. Une mise en œuvre datée peut être observée. Ce qui reste manquant, c’est un compte rendu complet de l’autorisation au sein de la population concernée, une mesure reproductible de la reconnaissance, et un processus établi pour l’appel, le remplacement et la continuité si le registre régional désigné cessait de répondre aux qualités sur lesquelles sa sélection reposait.