RFC 1466: Un plan d’allocation temporaire qui a survécu à ses prémisses

Résumé

• Les seuils par classe de la RFC 1466 et les règles échelonnées de classe C ont été remplacés par le cadre sans classe de la RFC 2050, mais le plan de 1993 ne prévoyait aucune disposition de temporisation pour la délégation régionale, la déclaration des demandeurs ou l'examen discrétionnaire.
• Le dossier publié montre une récurrence textuelle et une implémentation datée de 1993 au niveau du formulaire, mais manque de dénominateurs pour les demandes, les refus, les exceptions, les audits, les appels et les résultats, de sorte que la persistance institutionnelle ultérieure ne peut pas être attribuée au plan de 1993 sans preuves opérationnelles.

Le titre est une hypothèse, pas une citation

L'adjectif « temporaire » est l'hypothèse rétrospective de cet article. Le plan de mai 1993,RFC 1466, n'utilise ni « temporaire », « intérimaire », ni « temporisation ». Il ne donne aucune date d'expiration pour ses règles d'allocation ni aucun calendrier pour reconsidérer les institutions régionales qui leur sont associées. Sa conclusion indique que les recommandations ne feraient que retarder l'épuisement plutôt que de le reporter indéfiniment. Cela établit une efficacité technique limitée. Cela n'établit pas une expiration institutionnelle promise.

Cette distinction est essentielle car la RFC 1466 combinait plusieurs interventions différentes. Elle traitait de la rareté des numéros de réseau par classe souhaitables, en particulier les unités de classe B. Elle cherchait à réserver de l'espace d'adressage pour un futur plan de numérotation. Elle organisait les allocations de classe C de manière à ce que les techniques d'agrégation émergentes puissent utiliser des blocs contigus. Elle proposait un enregistrement géographiquement distribué comme moyen de servir une population de plus en plus internationale. Elle exigeait des demandeurs qu'ils divulguent leurs plans de réseau, et elle laissait aux registres le pouvoir de juger des exceptions.

Ces interventions n'avaient pas toutes la même durée de vie. Les tests par classe étaient liés à un environnement technique déjà sous pression. Les blocs de classe C géographiques étaient en partie un arrangement administratif et en partie une préparation à l'agrégation. La divulgation par le demandeur et le jugement du registre étaient des capacités administratives réutilisables. Les organisations régionales pouvaient continuer à servir les demandeurs même lorsque le problème initial de classe B contre classe C ne déterminait plus la taille de l'allocation.

L'introduction du plan décrivait la demande de numéros de réseau comme ayant considérablement augmenté au cours des deux années précédentes. Il conservait le Registre Internet comme registre principal et par défaut tout en proposant que des organisations qualifiées reçoivent des blocs et des responsabilités d'attribution. Son argument de service déclaré était la diversité mondiale : des registres plus proches des demandeurs pourraient mieux comprendre les langues et coutumes locales. Son argument technique concernait l'épuisement et la pression de routage. Ces arguments convergeaient dans un seul document, mais ils ne doivent pas être traités comme un mandat indivisible.

La RFC 1466 a été publiée en tant qu'Informational. Son résumé faisait état d'un consensus général parmi le Federal Engineering Planning Group, les co-présidents de l'Intercontinental Engineering Planning Group et RIPE en faveur des recommandations. C'est une preuve de l'examen par des groupes techniques nommés. Ce n'est pas un dénominateur de circonscription pour les fournisseurs de services Internet, les abonnés au réseau ou les demandeurs, et cela ne prouve pas un consentement à l'échelle des opérateurs.

La RFC 1466 n'est pas non plus à l'origine de tous les développements régionaux qui lui ont été associés par la suite. Le document indique que le RIPE NCC avait reçu un bloc de classe C avant l'adoption de la proposition. Un compte rendu rétrospectif ultérieur,RFC 7020, fait remonter à la RFC 1366 la proposition de déléguer la responsabilité aux organismes régionaux. La RFC 1466 a donc codifié, révisé et associé des dispositions spécifiques à un processus régional déjà en développement. On ne peut pas la décrire en toute sécurité comme ayant créé à elle seule l'administration régionale.

La question utile est plus étroite que de savoir si l'ensemble du plan est devenu permanent. Quelles règles techniques ont perdu leur autorité ? Quelles capacités administratives sont réapparues dans des textes ultérieurs ? Quelles dispositions ont atteint une forme datée utilisée par les demandeurs ? Quels rôles institutionnels ont été décrits à nouveau sous une logique technique modifiée ? Et quelles preuves seraient nécessaires pour passer d'une filiation textuelle à une affirmation sur une opération continue ou une causalité ?

Pénurie dans les unités par classe

L'ouverture numérique de la RFC 1466 est facile à mal interpréter car ses unités étaient des numéros de réseau, et non des adresses individuelles. Le document reproduisait des statistiques d'allocation datées de mai 1992. Sa ligne Classe A indiquait 126 unités de numéros de réseau au total et 49 allouées. Le tableau indiquait 38 pour cent, mais le calcul est49 / 126 = 38.888889%, ce qui s'arrondit à 39 pour cent plutôt qu'à 38. L'écart doit être conservé comme une caractéristique du tableau publié, et non converti silencieusement en un résultat mathématiquement exact.

La ligne Classe B indiquait 16 383 unités de numéros de réseau et 7 354 allouées. Ici7,354 / 16,383 = 44.887994%, ce qui correspond aux 45 pour cent indiqués. La ligne Classe C indiquait 2 097 151 unités de numéros de réseau et 44 014 allouées. Le rapport,44,014 / 2,097,151 = 2.098752%, correspond aux 2 pour cent indiqués lorsqu'il est exprimé en pourcentage entier.

Aucun de ces ratios ne mesure les hôtes connectés, les demandeurs servis, les demandes approuvées, les préfixes annoncés, l'utilisation des adresses, les refus ou le consentement. Ils comparent les créneaux de numéros de réseau par classe alloués avec le dénominateur indiqué pour la classe concernée. Les lignes ne sont pas interchangeables car une Classe A, une Classe B et une Classe C contenaient des quantités radicalement différentes de valeurs d'adresse d'hôte.

La RFC 1466 a caractérisé séparément la Classe A comme représentant 50 pour cent du total des adresses d'hôte IP, la Classe B 25 pour cent et la Classe C environ 12 pour cent. La part théorique de la Classe C est de 12,5 pour cent de l'espace IPv4 complet. Cette répartition de l'espace d'adressage aide à expliquer pourquoi seulement environ 2 pour cent des unités de numéros de réseau de Classe C pouvaient être allouées alors que la préoccupation restait intense : le problème immédiat n'était pas un simple décompte de toutes les valeurs IPv4 brutes.

L'adressage par classe offrait aux organisations des choix nettement discontinus. Un réseau de Classe C contenait 256 valeurs d'adresse brutes. Selon le traitement conventionnel de l'époque d'un identifiant de réseau et d'un identifiant de diffusion, il offrait 254 identifiants d'hôte utilisables. Une Classe B fournissait un champ d'hôte beaucoup plus grand. De nombreuses organisations préféraient donc une Classe B à la complexité opérationnelle de joindre de nombreux réseaux de Classe C, même lorsque leurs populations projetées n'occupaient qu'une fraction de la capacité de la Classe B.

La pénurie qui en résultait avait au moins trois dimensions. Premièrement, les unités de numéros de réseau de Classe B étaient consommées rapidement par rapport à leur nombre fini. Deuxièmement, les attributions importantes pouvaient laisser une grande partie de leur capacité d'adresse inutilisée. Troisièmement, remplacer une Classe B par de nombreux réseaux de Classe C pouvait multiplier les entrées de routage à moins que les techniques d'agrégation et la topologie ne permettent de représenter ces réseaux ensemble.

La RFC 1466 traitait les trois, mais pas avec une seule mesure. Ses restrictions de Classe B conservaient une unité par classe souhaitable. Son barème de Classe C convertissait les besoins projetés en allocations contiguës. Ses blocs géographiques créaient une structure administrative compatible avec une agrégation potentielle. Ses dispositions relatives aux registres régionaux répartissaient le travail d'application de ces règles. Le plan associait la gestion de la pénurie à la conception institutionnelle car quelqu'un devait recevoir les prévisions, évaluer l'architecture du réseau, préserver les informations confidentielles et décider si les exceptions étaient justifiées.

C'était une réponse façonnée par la pénurie, pas simplement un tableau de limites techniques. Une fois qu'une prévision devenait une preuve, l'allocation dépendait d'une institution capable de l'interpréter. Une fois que plusieurs réseaux contigus remplaçaient une seule Classe B, l'allocataire devait décider de la taille et de l'emplacement du bloc. Une fois que les divisions géographiques devenaient la base de la responsabilité principale, un plan de distribution technique organisait également les relations de service.

Mais les chiffres limitent la portée de cette interprétation. Le tableau ne dit rien sur la raison pour laquelle un numéro de réseau particulier a été attribué. Il ne fournit aucune population de demandes, aucune comparaison des plans acceptés et rejetés, et aucun compte rendu des demandeurs qui ont modifié ou retiré leurs demandes. Les statistiques établissent le cadre par classe dans lequel la politique a été écrite. Elles n'établissent pas les effets de chaque disposition individuelle.

La porte de la Classe B

La porte d'allocation la plus explicite du plan concernait les demandes de Classe B. Les directives antérieures favorisaient une Classe B sous-réseautée par rapport à plusieurs réseaux de Classe C. La RFC 1466 a inversé cette préférence lorsque plusieurs Classe C étaient pratiques, citant la rareté des numéros de réseau de Classe B et leur sous-utilisation par de nombreuses organisations.

Une organisation cherchant une Classe B devait satisfaire à deux critères conjonctifs : un plan de sous-réseautage documentant plus de 32 sous-réseaux et plus de 4 096 hôtes. Elle devait également soumettre un plan technique montrant pourquoi un bloc de réseaux de Classe C était déraisonnable pour sa conception. Le plan devait indiquer le nombre projeté d'hôtes et d'hôtes par sous-réseau au cours des 24 prochains mois.

Les seuils étaient importants, mais ils ne constituaient pas un droit automatique. Plus de 32 sous-réseaux sans plus de 4 096 hôtes ne satisfaisaient pas la conjonction suggérée. Plus de 4 096 hôtes sans la structure de sous-réseau requise ne le faisaient pas non plus. Même lorsque les conditions numériques étaient remplies, le registre devait encore évaluer si l'explication technique justifiait l'unité par classe la plus rare.

Le vocabulaire plaçait le jugement au centre. Le demandeur devait démontrer qu'un bloc de Classe C était déraisonnable à concevoir. Le registre décidait si la demande était justifiée et si le plan justifiait une Classe B. Dans le cas contraire, l'alternative décrite était un bloc de numéros de réseau de Classe C. Le plan soumis devait être conservé de manière strictement confidentielle et utilisé uniquement pour juger la demande.

La RFC 1466 préservait également les exceptions. Elle reconnaissait qu'une organisation pouvait être incapable d'utiliser un bloc de Classe C même sans réunir les critères suggérés pour la Classe B. Un tel demandeur pouvait expliquer la contrainte technique. Le texte n'énumérait pas toutes les topologies acceptables, n'attribuait pas de poids aux preuves et ne publiait pas de formule éliminant le jugement de l'examinateur.

Au niveau supérieur au demandeur, le Registre Internet central pouvait allouer de petits blocs de Classe B à un registre régional si cela améliorait le service à la communauté. Il pouvait émettre des directives de sous-attribution plus spécifiques, exiger une comptabilisation du bloc, recevoir les plans techniques des demandeurs et les auditer pour vérifier leur conformité aux directives. Ces clauses identifient un acteur autorisé et des formes possibles de supervision. Elles ne montrent pas qu'un audit a eu lieu, à quelle fréquence il a été envisagé ou quelles conséquences en ont découlé.

L'arrangement contenait donc une prémisse technique, un critère d'allocation, un critère institutionnel et une exception. La prémisse technique était la rareté et la sous-utilisation de la Classe B. Le critère ordinaire combinait des seuils de sous-réseau et d'hôte avec un plan technique sur 24 mois. Le critère institutionnel était la capacité du registre à évaluer et à protéger ce plan. L'exception permettait qu'un cas en dehors des seuils suggérés soit examiné pour des raisons techniques.

Ses charges étaient asymétriques. Le demandeur devait convertir une croissance future incertaine en une architecture documentée. Le registre conservait le pouvoir discrétionnaire de décider si la prévision était crédible et si plusieurs Classe C étaient pratiques. Cette asymétrie ne provenait pas seulement d'une base de données d'allocation ; elle était inscrite dans la relation probatoire entre le demandeur et l'examinateur.

Pourtant, ce serait une erreur de décrire chaque demande ultérieure d'informations du demandeur comme une survivance de cette règle de Classe B. Le test original demandait si une alternative par classe était réalisable sur un horizon de deux ans. En novembre 1996, le cadre publié utilisait la longueur du préfixe, l'utilisation et les allocations par étapes. L'examen des prévisions a réapparu, mais l'objet de l'examen et ses horizons temporels ont changé. La continuité d'une fonction administrative n'est pas la continuité du seuil d'origine.

Classe C contiguës et arithmétique de l'agrégation

La RFC 1466 tentait de conserver les unités de Classe A et de Classe B en attribuant plusieurs Classe C lorsque c'était possible. Cette réponse créait son propre problème de routage. Si chaque Classe C apparaissait séparément, le nombre d'entrées de routage pouvait croître rapidement. Le plan organisait donc les unités de Classe C en blocs contigus de puissances de deux compatibles avec l'agrégation.

La division géographique doit être décrite dans l'unité correcte. La RFC 1466 divisait la plage allant de 192.0.0.0 à 207.255.255.255 en huit blocs, chacun couvrant deux valeurs du premier octet. Chaque bloc contenait 131 072 unités de numéros de réseau de Classe C :2 × 65,536. Cela représente 6,25 pour cent de l'espace théorique de 2 097 152 unités de numéros de réseau de Classe C. C'est également131,072 × 256 = 33,554,432adresses IPv4 brutes.

Le dénominateur théorique de 2 097 152 unités de Classe C est distinct du total de 2 097 151 imprimé dans le tableau d'allocation de la RFC 1466. La différence ne doit pas être masquée en traitant les deux chiffres comme s'ils provenaient du même calcul. Le tableau rapportait son inventaire par classe ; la part de 6,25 pour cent du bloc découle du champ théorique de numéro de réseau de Classe C à 21 bits.

Le plan réservait la moitié supérieure de la plage de Classe C, principalement non attribuée, de 208.0.0.0 à 223.255.255.255, jusqu'à nouvel ordre. Dans la moitié inférieure, de 192.0.0.0 à 193.255.255.255 était décrite comme multirégionale car des attributions y étaient antérieures à la mise en œuvre. L'Europe a reçu le bloc 194–195, l'Amérique du Nord 198–199, l'Amérique centrale et du Sud 200–201, et la bordure du Pacifique 202–203. Trois autres blocs de deux octets ont été conservés pour plus de flexibilité.

La RFC 1466 qualifiait la division de principalement administrative et disait qu'elle jetait les bases de registres distribués. Elle était également conçue pour être compatible avec les techniques potentielles d'agrégation d'adresses. La compatibilité est le bon niveau d'affirmation. La contiguïté géographique seule ne provoquait pas l'agrégation de routage. Le fait qu'un bloc puisse être annoncé comme une seule route dépendait de la topologie du réseau, des relations avec les fournisseurs, de la politique de routage et de la technologie effectivement déployée.

À l'intérieur de ces grands blocs, le plan utilisait un barème échelonné basé sur la projection sur 24 mois par l'organisation des adresses de système d'extrémité nécessaires. Moins de 256 adresses correspondaient à une Classe C ; moins de 512 à deux ; moins de 1 024 à quatre ; moins de 2 048 à huit ; moins de 4 096 à 16 ; moins de 8 192 à 32 ; et moins de 16 384 à 64 réseaux de Classe C contigus.

Ces seuils se référaient aux tailles de blocs d'adresses brutes. Ils ne doivent pas être fusionnés silencieusement avec les exemples d'hôtes utilisables. Une Classe C contient 256 valeurs brutes mais 254 identifiants d'hôte utilisables selon la convention de l'époque. Trente-deux Classe C contiennent 8 192 valeurs brutes. Traitées comme 32 réseaux de Classe C distincts, elles contiennent 8 128 de ces identifiants d'hôte utilisables. Soixante-quatre Classe C contiennent 16 384 valeurs brutes et 16 256 créneaux d'hôtes utilisables par classe. La même étendue d'adresses contiguës correspond à un seul préfixe/18, mais cette notation de préfixe n'efface pas la distinction entre les valeurs brutes et la convention d'hôte utilisable appliquée aux réseaux de Classe C distincts.

Le barème prévoyait des exceptions. Si le réseau d'un abonné comprenait des réseaux locaux logiquement distincts pour lesquels le bloc par défaut était difficile à utiliser, les critères pouvaient être appliqués par réseau local. La RFC 1466 donnait un exemple de 600 hôtes répartis sur dix Ethernets, produisant potentiellement dix attributions de Classe C. Elle mettait également en garde contre le gaspillage excessif là où le sous-réseautage était possible et permettait aux registres de demander une explication technique.

Un abonné nécessitant plus de 4 096 adresses uniques pouvait prétendre à une Classe B, mais le registre régional pouvait honorer une demande de bloc de Classe C plus important. Soixante-quatre Classe C contiguës étaient décrites comme le bloc ordinaire maximal, avec des écarts déterminés au cas par cas. Le barème était donc structuré mais pas mécanique.

Cette disposition révèle un plan qui penchait déjà au-delà des étiquettes de classe qu'il utilisait formellement. Son vocabulaire d'allocation restait celui de la Classe C, mais les puissances de deux, la contiguïté au niveau des bits et un préfixe de 18 bits pointaient vers une représentation sans classe. Le plan ne résolvait pas la tension entre conservation et pression de routage ; il organisait les allocations de manière que les techniques de routage ultérieures puissent la gérer.

Une source visuelle rétrospective ne peut pas fournir le chaînon causal manquant. LaVisual History of Internet IPv4 Address Allocationsde CAIDA a été publiée le 18 juillet 2020. Sa méthode déclarée regroupe les blocs d'adresses par l'organisation régulant l'allocation, en utilisant le fichier d'espace d'adressage IPv4 de l'IANA et les RFC comme base de source. Le matériel public ne fournit pas d'instantané de source historique reproductible, de dénominateur d'événement d'allocation, d'exclusions, de dossiers de demandeurs ou de raisons de décision. Il peut illustrer le regroupement rétrospectif de CAIDA. Il ne peut pas montrer que la RFC 1466 a causé une allocation, qu'un registre a refusé une alternative, ou qu'un demandeur a utilisé ou refusé une voie de repli.

Service régional, responsabilité déléguée et un repli central

Les dispositions régionales de la RFC 1466 étaient justifiées d'abord comme une réponse de service à un Internet de plus en plus diversifié. Un registre situé plus près d'une communauté pourrait mieux servir les demandeurs dans les langues et coutumes locales. L'Europe, l'Amérique du Nord, l'Amérique centrale et du Sud, et la bordure du Pacifique ont été désignées comme des zones suffisamment matures dans lesquelles la délégation pouvait être envisagée.

La proximité seule ne suffisait pas. Une organisation candidate devait être légitimée par les autorités de réseau dans sa zone géographique, bien établie et reconnue au-delà de la fonction de registre. Elle devait engager des ressources adéquates pour un service stable, rapide et fiable. Elle devait suivre les directives de l'IANA et du Registre Internet et coordonner les qualifications et les stratégies de sous-allocation avec le centre.

Le plan indiquait également qu'un registre régional devait être impartial et largement reconnu par les fournisseurs de réseau et les abonnés. Il considérait qu'un seul registre à ce niveau régional était important pour une sous-allocation efficace et équitable. Ces déclarations étaient des critères de sélection institutionnelle. Elles ne constituaient pas la preuve que tous les fournisseurs ou abonnés concernés autorisaient le candidat. Le document ne fournit aucun dénominateur de circonscription pour les « autorités de réseau », la reconnaissance ou le soutien du groupe d'examen.

Une fois sélectionné, un registre régional était habilité par l'IANA et le Registre Internet à fournir un service d'enregistrement dans une zone géographique. Là où il en existait un, la responsabilité principale de l'allocation à partir du bloc de Classe C concerné pouvait lui être déléguée. Là où aucune autorité désignée n'existait, le registre central restait l'option par défaut.

Le plan ne rendait pas la voie régionale textuellement absolue. Un demandeur pouvait contacter directement le Registre Internet central. Selon les circonstances, le demandeur pouvait être dirigé vers le registre régional, mais le registre central disait qu'il serait prêt à servir tout abonné au réseau si nécessaire.

Ce repli doit rester une partie de l'architecture de 1993. Il empêche que le document soit réécrit comme un octroi inconditionnel de compétence exclusive. En même temps, sa signification pratique est inconnue. La RFC 1466 ne définit pas « nécessaire », n'établit pas de test de service exécutoire et ne précise pas comment un désaccord sur l'orientation serait résolu. La source confirme la voie dans le plan publié ; elle ne révèle pas sa fréquence, son accessibilité ou ses conséquences pour le demandeur.

La position pré-adoption du RIPE NCC limite encore plus la causalité centrée sur la RFC. La RFC 1466 indique que le RIPE NCC avait déjà reçu le bloc de Classe C de 193.0.0.0 à 193.255.255.255 avant l'adoption de la proposition et avait accepté d'allouer à l'intérieur de celui-ci selon les nouvelles directives. Le plan a donc attaché ses critères à une délégation existante plutôt que de créer cette délégation à partir de rien.

Le compte rendu rétrospectif de la RFC 7020 renforce ce point sans résoudre tous les détails historiques. Il indique que la RFC 1366 a proposé de déléguer la responsabilité aux organismes régionaux et note la succession à travers la RFC 1466 et la RFC 2050. Il indique également que le système de registre de numéros a considérablement changé après la RFC 2050. Cela établit une filiation reconnue dans un document Informationnel de 2013, et non un mandat inchangé s'étendant de 1993 à un système ultérieur à cinq registres.

L'affirmation défendable pour 1993 est que la RFC 1466 a codifié les qualifications des délégués régionaux, a associé des blocs de Classe C géographiques à une responsabilité régionale principale et a conservé un repli central. Elle a lié le service, l'allocation et la coordination à l'intérieur d'une structure institutionnelle en développement. Que le niveau régional ait perduré par la suite parce qu'il offrait un meilleur service, détenait des ressources déléguées, réduisait la charge de travail centrale ou devenait coûteux à remplacer nécessite des preuves au-delà de la disposition elle-même.

RIPE 95: une implémentation datée au niveau du formulaire

Leformulaire de demande de numéro de réseau IP européen et notes complémentaires, RIPE 95, offre une vue plus concrète mais étroitement limitée. Publié le 1er octobre 1993, il indiquait qu'il n'était valable que jusqu'au 30 décembre 1993. C'est la preuve d'un formulaire européen particulier et de canaux de soumission prescrits pendant cette période, et non d'un règlement opérationnel indéfiniment.

Son introduction décrivait un arrangement distribué dans lequel InterNIC déléguait des blocs au RIPE NCC, qui à son tour déléguait aux registres Internet locaux. Les demandeurs étaient invités à postuler d'abord via un registre local. Le client d'un fournisseur de services Internet devait contacter ce fournisseur ; un demandeur sans un tel fournisseur était orienté vers le registre local approprié non-fournisseur de services. Une personne incertaine quant à la bonne voie pouvait contacter le RIPE NCC pour obtenir des conseils. Le formulaire n'autorisait pas généralement l'incertitude comme motif pour contourner la voie locale de première instance.

Les demandes de Classe B suivaient une escalade plus claire. Le demandeur soumettait via un registre local. Si le registre local considérait la demande justifiée, il transmettait le dossier au RIPE NCC, qui seul attribuait les numéros de Classe B en Europe dans le cadre de l'arrangement indiqué. C'est la preuve de canaux prescrits et de niveaux d'examen. Ce n'est pas une preuve du nombre de demandes transmises, refusées ou modifiées.

Le formulaire divisait les informations en données administratives publiques et données techniques confidentielles. Les champs publics couvraient le nom du réseau, la description de l'organisation, le pays, les contacts administratifs et techniques, les adresses et les détails de communication. La section technique, décrite comme confidentielle et exclue de la base de données publique RIPE, demandait la classe et la quantité demandées, les machines actuelles, les estimations de machines à un et deux ans, les sous-réseaux actuels et projetés, le statut de connectivité Internet, les numéros de réseau existants et les pays dans lesquels le réseau fonctionnerait.

Ses exemples rendent visible la distinction brut/utilisable. Le formulaire indiquait une Classe C comme un maximum de 254 hôtes, deux comme 508, quatre comme 1 016, huit comme 2 032, 16 comme 4 064 et 32 comme 8 128. Il s'agissait des maxima d'hôtes utilisables conventionnels de l'époque après exclusion de deux identifiants par réseau de Classe C. Ils ne modifiaient pas le barème brut de la RFC 1466 de 256 valeurs d'adresse par Classe C.

Les demandes de plus de deux Classe C nécessitaient une description de réseau plus complète. Les demandeurs devaient rendre compte de la taille des sous-réseaux, des réseaux de transit et des serveurs terminaux. Les allocations existantes importaient : les organisations cherchant un espace supplémentaire devaient décrire les numéros de réseau utilisés et inutilisés, les sous-réseaux installés, les hôtes connectés et d'autres faits structurels. Les objectifs déclarés étaient une utilisation efficace et des attributions contiguës lorsque c'était possible afin que les informations de routage puissent être agrégées.

Pour les demandes de Classe B, RIPE 95 décrivait les critères comme extrêmement stricts en raison de la rareté mondiale. Les estimations d'hôtes devaient être étayées par des informations telles que le nombre d'employés, la répartition géographique et les types d'hôtes. Les demandeurs devaient expliquer pourquoi des Classe C contiguës ne pouvaient pas prendre en charge la conception. La commodité administrative était expressément écartée. Les demandes de plusieurs Classe B nécessitaient une justification détaillée capable de convaincre à la fois le registre local et le RIPE NCC.

C'est une preuve plus solide qu'un simple document de politique pour une proposition limitée : les exigences d'information de l'ère RFC ont atteint un formulaire de demandeur daté en Europe. Les champs montrent comment les machines projetées, les sous-réseaux, les attributions antérieures et la connectivité étaient rendues lisibles pour les examinateurs. La voie locale de première instance et l'escalade de Classe B identifient le chemin administratif prescrit.

Le formulaire est une preuve beaucoup plus faible pour l'adjudication. Il ne contient aucun dénominateur pour les demandes complétées, les orientations, les approbations, les refus ou les retraits. Il ne montre pas si deux demandeurs similaires ont été traités de la même manière, si les examinateurs ont suivi chaque champ, comment les exceptions ont été motivées, si les prévisions ont été vérifiées ultérieurement ou si un demandeur considérait le processus comme légitime. Un formulaire standard peut démontrer une divulgation attendue sans démontrer des décisions cohérentes.

Il ne peut pas non plus établir la continuité jusqu'en 1996. Sa date d'expiration est explicite. Un formulaire ultérieur a pu conserver, modifier ou supprimer des champs individuels, mais cette conclusion nécessite l'instrument ultérieur. RIPE 95 doit donc rester une observation datée : une implémentation au niveau du formulaire de certaines parties de l'architecture de 1993, limitée à la fin de 1993 et à l'Europe.

Novembre 1996: un remplacement textuel, pas un événement instantané

En novembre 1996, laRFC 2050a expressément rendue obsolète et remplacé la RFC 1466. Publiée en tant que Best Current Practice 12, elle indiquait que les directives et procédures antérieures avaient été mises à jour et modifiées à la lumière de l'expérience. Textuellement, la succession est sans ambiguïté.

Sa note de statut exige de la précision. L'Internet Engineering Steering Group a déclaré que l'approbation reflétait sa conviction que la politique représentait fidèlement la pratique actuelle d'attribution des registres. La note ajoutait immédiatement que l'approbation ne constituait pas une approbation ou une recommandation de l'IESG. Elle anticipait également une réévaluation en décembre 1997 après de nouvelles discussions.

Cette note étaye une affirmation de codification publiée et de pratique actuelle revendiquée. Elle n'authentifie pas une décision distincte de maintien institutionnel, n'établit pas une mise en œuvre uniforme dans tous les registres et ne prouve pas que chaque disposition a pris effet simultanément à la publication. Le statut de la RFC, l'obsolescence, la pratique revendiquée et la mise en œuvre sont des propositions distinctes.

Les changements techniques étaient substantiels. La RFC 2050 organisait la distribution autour de trois objectifs : conservation, routabilité et enregistrement. La conservation signifiait une distribution équitable basée sur les besoins opérationnels et la prévention du stockage. La routabilité signifiait une distribution hiérarchique qui favorisait l'évolutivité du routage, tout en refusant expressément de garantir que les adresses attribuées seraient routées. L'enregistrement signifiait la tenue d'un registre public pour préserver l'unicité et faciliter le dépannage.

Le document reconnaissait que ces objectifs pouvaient entrer en conflit les uns avec les autres et avec les intérêts des utilisateurs finaux et des fournisseurs de services. Il appelait à l'analyse et au jugement dans les cas individuels. Le pouvoir discrétionnaire ultérieur avait donc une base nouvellement articulée à trois objectifs plutôt que de simplement répéter le problème de Classe B contre Classe C.

La RFC 2050 décrivait une hiérarchie établie de l'IANA, des registres régionaux et des registres locaux. À l'époque, elle nommait trois registres régionaux : InterNIC, RIPE NCC et APNIC. Cette description de 1996 ne doit pas être remplacée par la géographie ultérieure à cinq registres. Les registres régionaux opéraient dans de vastes zones géopolitiques, coordonnaient les registres locaux et étaient décrits comme établis sous l'autorité de l'IANA avec le consensus de la communauté Internet régionale.

L'allocation était désormais explicitement sans classe. Les registres régionaux émettaient des blocs sur des limites de bits prises en charge par CIDR. Les attributions étaient faites par longueur de préfixe plutôt que comme Classe B ou Classe C. Les hypothèses par classe faites pour des raisons de commodité administrative nécessitaient une justification spéciale. Une organisation qui aurait pu auparavant être décrite comme recevant une Classe B recevrait plutôt un préfixe/16si cette taille était justifiée, quelle que soit la classe d'adresse historique.

La hiérarchie des fournisseurs est devenue centrale pour la routabilité. Un fournisseur de services Internet répondant aux conditions de routage spécifiées, y compris le multi-hébergement qualifiant ou la connexion directe à un échange majeur défini, pouvait demander de l'espace à un registre régional dans sa zone géographique. Un fournisseur sans registre régional désigné pouvait contacter un autre registre régional, qui pouvait traiter ou transmettre la demande. Les autres fournisseurs étaient généralement invités à obtenir de l'espace auprès d'un fournisseur en amont afin que les attributions puissent s'intégrer dans les agrégats de fournisseurs.

Le document avertissait que les adresses émises directement par un registre étaient parmi les moins susceptibles d'être routables globalement. Il encourageait les fournisseurs à traiter les attributions clients comme des prêts pour la durée de la connectivité et envisageait la renumérotation lorsqu'un client changeait de fournisseur. Il s'agissait d'une relation différente entre l'agrégation et l'allocation par rapport à la large grille géographique de Classe C de la RFC 1466.

Pour les nouveaux fournisseurs de services, la RFC 2050 prescrivait un démarrage lent. L'allocation initiale devait être minimale et basée sur le besoin immédiat démontré. Les blocs ultérieurs pouvaient augmenter après que le registre régional ait vérifié l'utilisation. Les registres parents déterminaient les tailles initiales et ultérieures. Le nombre projeté de clients avait peu d'influence, et une allocation supplémentaire était destinée à couvrir environ trois mois d'attributions.

Cette règle d'allocation aux fournisseurs doit rester distincte de la directive d'attribution aux entreprises finales. Pour une entreprise finale, la RFC 2050 indiquait une utilisation immédiate de 25 pour cent et une utilisation de 50 pour cent en un an. Elle définissait l'utilisation comme le nombre d'hôtes connectés divisé par le nombre total d'hôtes possibles sur le réseau. Une organisation devait montrer une grande confiance dans sa projection sur un an et fournir des documents justificatifs. La topologie pouvait justifier des exceptions, mais les pourcentages étaient présentés comme la directive commune.

Le document ultérieur exigeait également des plans techniques de réseau. Avant l'attribution, un registre devait examiner les masques de sous-réseau, les hôtes par sous-réseau, la topologie, les plans de routage et les limitations de protocole, les informations sur le sous-réseau et les hôtes couvrant au moins un an. Les attributions d'adresses précédentes entre les divisions et les filiales devaient être prises en compte. Les registres pouvaient exiger des preuves corroborantes et des informations confirmant l'identité de l'organisation.

Ces exigences d'information ressemblent à l'architecture de 1993 à un niveau élevé, mais servaient un test modifié. La RFC 1466 utilisait une prévision sur 24 mois pour déterminer si plusieurs Classe C étaient raisonnables et pour sélectionner un bloc par classe échelonné. La RFC 2050 utilisait le besoin immédiat, l'utilisation sur un an, les preuves d'utilisation antérieure, le dimensionnement du préfixe, l'agrégation par fournisseur et les allocations par étapes. Le demandeur fournissait toujours des informations ; les informations ne répondaient plus à la même question d'allocation.

Le pouvoir d'audit a également changé. La RFC 1466 permettait au registre central d'auditer les plans techniques régionaux de Classe B. La RFC 2050 indiquait que toutes les demandes d'adresse étaient soumises à un audit et à une vérification par les moyens qu'un registre régional jugeait appropriés. Les fausses informations pouvaient entraîner l'invalidation et le retour des adresses attribuées au pool libre. Les registres régionaux pouvaient fixer des seuils de taille nécessitant un deuxième avis.

Les voies de confidentialité et de recours étaient décrites plus complètement. Les informations identifiées comme sensibles par un demandeur devaient être traitées comme confidentielles. Si le registre attributaire ne pouvait garantir la confidentialité, son parent pouvait procéder à l'attribution. Une organisation insatisfaite d'une décision d'attribution avait le droit écrit de faire appel au registre parent, avec un appel ultérieur possible ultimement à l'IANA une fois les autres voies épuisées.

Il s'agissait de pouvoirs et de garanties publiés. Leur inclusion ne dit rien en soi sur la sélection des audits, la fréquence des appels, les taux d'annulation ou l'accès en pratique. Pourtant, ils démontrent que le cadre ultérieur n'était pas simplement la RFC 1466 avec les noms de classe supprimés. Il a refondu l'allocation autour de CIDR, de la hiérarchie des fournisseurs, de l'utilisation, du démarrage lent, de la vérification et de l'appel.

L'obsolescence textuelle importe donc. Après novembre 1996, la base de référence publiée faisant autorité était la RFC 2050, et non une RFC 1466 qui continuait silencieusement. De même, la publication ne peut pas montrer la date à laquelle chaque formulaire régional, habitude d'examinateur, outil logiciel ou canal de demandeur a changé. La continuité des règles et la continuité institutionnelle doivent être évaluées séparément.

Quatre explications pour une persistance apparente

Trois grandes caractéristiques associées à la RFC 1466 sont réapparues après que ses mécanismes par classe ont perdu leur autorité : les organisations régionales, les charges d'information des demandeurs et l'examen discrétionnaire. Leur récurrence n'identifie pas sa propre cause.

Quatre explications méritent d'être considérées. La première est le besoin technique continu. L'allocation unique, les pools d'adresses finis et l'agrégation de routage pourraient justifier indépendamment des registres coordonnés et un examen fondé sur des preuves après que le problème de Classe B a changé.

La deuxième est la responsabilité déléguée. Une organisation détenant des blocs d'adresses, des enregistrements et des obligations envers les registres en aval avait des responsabilités pratiques qui n'ont pas disparu lorsqu'une RFC successeur est apparue. La continuation pourrait refléter la nécessité de préserver des attributions exactes et un service opérationnel plutôt qu'un attachement au texte antérieur.

La troisième combine le coût de changement et l'inertie administrative. Le personnel, les formulaires, les bases de données, les canaux confidentiels, les relations d'escalade et les connaissances des demandeurs existants rendent le remplacement institutionnel coûteux. Ce mécanisme est plausible une fois que l'infrastructure existe, mais la plausibilité n'est pas une mesure. Les sources examinées ne chiffrent pas la transition et ne documentent pas une alternative rejetée.

La quatrième est la codification textuelle ultérieure. La RFC 2050 décrivait la hiérarchie régionale, la documentation des demandeurs, la vérification et les appels dans un cadre sans classe. Cela montre que les auteurs ultérieurs ont reformulé et réorganisé de larges fonctions administratives. C'est plus faible qu'un enregistrement de décision authentifié identifiant un organisme responsable, une disposition de 1993 conservée, les raisons de la conservation et une date de mise en œuvre.

Ces explications ne sont pas mutuellement exclusives. Le besoin technique continu peut coexister avec la responsabilité déléguée. Une institution utile peut aussi être coûteuse à remplacer. La codification ultérieure peut reconnaître des arrangements qui se sont développés par la pratique plutôt que de les créer. Les preuves permettent de tester sélectivement chaque possibilité, pas une allocation numérique de causalité.

Les organisations régionales après la grille géographique

La disposition précise de 1993 associait des organisations régionales qualifiées à une responsabilité principale au sein de grands blocs de Classe C, tout en préservant le service central par défaut et un repli direct. Son cadre technique était l'allocation par classe compatible avec une agrégation potentielle. Son cadre institutionnel était un modèle en développement de service géographiquement distribué.

En 1996, la RFC 2050 décrivait les registres régionaux comme des composants établis d'une hiérarchie à trois niveaux. L'IANA leur allouait ; ils coordonnaient les registres locaux ; les registres locaux et les fournisseurs servaient les utilisateurs en aval. Le mécanisme n'était plus le simple appariement d'une organisation régionale avec un bloc de Classe C de deux octets. Il impliquait des allocations CIDR, un adressage basé sur les fournisseurs, des enregistrements de réattribution et un examen hiérarchique.

Le texte ultérieur ne reprenait pas toute la liste de qualification de 1993. La langue et les coutumes, la légitimité en dehors de la fonction de registre, une seule organisation régionale par zone et le service central universel « si nécessaire » n'ont pas été reformulés sous la même forme. La RFC 2050 faisait plutôt référence au consensus de la communauté Internet régionale, à l'autorité de l'IANA et à la coordination des registres locaux.

Les preuves observées au cours de la période restent limitées. RIPE 95 montre un arrangement local-à-régional européen fin 1993. La RFC 2050 codifie une hiérarchie régionale en novembre 1996 et la caractérise comme pratique actuelle des registres, sous réserve de la limitation de la note de l'IESG. La RFC 7020 reconnaît plus tard la filiation institutionnelle tout en notant un changement ultérieur majeur.

Le besoin technique continu est une alternative forte à la causalité centrée sur la RFC. L'unicité des adresses exigeait une coordination, et l'agrégation bénéficiait d'une distribution hiérarchique. Le service régional pouvait réduire la charge de travail centrale et placer les examinateurs plus près des demandeurs. Aucun de ces besoins ne dépendait de l'utilisation continue de la carte de Classe C de 1993.

La responsabilité déléguée est également plausible. Le RIPE NCC détenait déjà un bloc avant l'adoption de la RFC 1466. Une fois que les registres régionaux et locaux détenaient de l'espace d'adressage, tenaient des registres et servaient les organisations en aval, un remplacement brutal aurait nécessité des transferts de données, d'autorité et de fonctions techniques. Les sources montrent que ces responsabilités existaient ; elles n'établissent pas les instruments complets par lesquels chacune a été maintenue.

Le coût de changement est suggéré par l'infrastructure au niveau du formulaire visible dans RIPE 95. Les demandeurs avaient des canaux reconnus, des champs publics et confidentiels, des contacts locaux et une voie d'escalade pour l'examen de Classe B. Remplacer ces arrangements imposerait un effort. Aucune preuve examinée ne montre qu'une alternative proposée a été rejetée parce que le coût était jugé excessif.

La codification ultérieure est le fait documentaire le plus clair. La RFC 2050 a publié une hiérarchie sous un régime d'allocation différent. Qualifier cela de réadoption textuelle évite de confondre la publication avec la preuve d'une décision de maintien distincte ou d'un fonctionnement universel.

Le repli central est l'endroit où une affirmation de continuité inchangée échoue le plus nettement. La RFC 1466 disait que le registre central servirait un abonné si nécessaire. La RFC 2050 décrivait plutôt les canaux ordinaires des fournisseurs et régionaux, le contact interrégional là où aucun registre régional n'existait, l'intervention du parent pour la confidentialité et les appels hiérarchiques. Ces mécanismes de niveau supérieur ne sont pas les mêmes que l'assurance antérieure.

Les sources ne montrent pas si le repli de la RFC 1466 a été fréquemment utilisé, rarement utilisé, réduit, transformé ou laissé en sommeil. Elles n'établissent pas non plus son caractère exécutoire ou sa commodité pratique. La conclusion prudente est que l'administration régionale a persisté dans la forme publiée tandis que sa base technique et sa hiérarchie de service ont changé. Le rôle a perduré ; la grille d'allocation de 1993 et le langage de repli n'ont manifestement pas perduré inchangés avec lui.

Divulgation du demandeur après les seuils par classe

La RFC 1466 exigeait qu'un demandeur de Classe B présente des projections de sous-réseau et d'hôte, explique pourquoi les Classe C étaient déraisonnables et divulgue un plan technique sur 24 mois. Son barème de Classe C dépendait également d'une estimation sur deux ans des adresses de système final nécessaires. RIPE 95 a traduit les exigences connexes en champs couvrant les machines actuelles et futures, les sous-réseaux, la connectivité, les attributions antérieures et la structure du réseau.

La RFC 2050 a conservé la proposition générale selon laquelle une demande n'était pas auto-validante. Un registre examinait les preuves concernant les plans de réseau, la topologie, le routage, l'utilisation antérieure et l'utilisation prévue. Les fournisseurs cherchant des allocations supplémentaires devaient démontrer l'utilisation. Les entreprises finales étaient confrontées à des attentes d'utilisation immédiate et sur un an. Une corroboration pouvait être exigée.

Les acteurs porteurs différaient selon le niveau. Un registre local ou un fournisseur pouvait recevoir une demande ordinaire. Un registre régional pouvait examiner les allocations plus importantes ou directes. Un registre parent pouvait intervenir en matière de confidentialité, de deuxième avis ou d'appels. Le demandeur restait dépendant d'une évaluation institutionnelle, mais l'organisme d'examen et le but probatoire variaient.

Le mécanisme a changé plus que la récurrence des formulaires ne pourrait le suggérer. En 1993, une projection sur deux ans permettait de choisir entre l'éligibilité à la Classe B et les blocs de Classe C en puissances de deux. En 1996, un nouveau fournisseur commençait avec un espace minimal basé sur le besoin immédiat, tandis que l'espace supplémentaire du fournisseur couvrait environ trois mois après vérification de l'utilisation. Une entreprise finale était évaluée par rapport à une utilisation immédiate et sur un an, définie par les hôtes connectés sur les hôtes possibles.

Ce changement a considérablement réduit le rôle de la croissance spéculative pour les fournisseurs. La RFC 2050 indiquait que la clientèle projetée avait peu d'effet sur les allocations des registres parents. L'utilisation historique et les besoins par étapes sont devenus plus importants. La collecte d'informations a survécu, mais sa logique est passée du choix d'unités par classe au contrôle de l'allocation sans classe dans le temps.

La pénurie persistante fournit une explication indépendante. Un pool fini et une demande incertaine créent une raison de demander des preuves aux demandeurs même si aucun formulaire antérieur n'existe. La routabilité en ajoute une autre : la topologie et les relations avec les fournisseurs affectent la capacité d'un préfixe à contribuer à l'agrégation. La charge d'information ultérieure pouvait donc être justifiée par les conditions techniques actuelles plutôt que par une habitude héritée.

La capacité administrative existante reste un contributeur plausible. Les examinateurs savaient déjà comment traiter les plans confidentiels, les attributions antérieures et les projections. Les demandeurs rencontraient déjà des questions standardisées. Un test technique modifié pouvait être inséré dans des canaux familiers. C'est un récit crédible d'adaptabilité, pas une preuve que l'inertie a causé les règles ultérieures.

La codification publiée est à nouveau le résultat le plus solide. La RFC 2050 exigeait une documentation dans un nouveau cadre. L'article peut établir la récurrence textuelle et une implémentation au niveau du formulaire de 1993. Il ne peut pas établir l'utilisation ininterrompue du même formulaire, une pratique d'examinateur stable ou des effets cohérents sur la période 1993–1998.

La postérité institutionnelle est donc plus étroite que la survie d'un seuil particulier. La caractéristique durable était une architecture de demande dans laquelle un demandeur fournissait des preuves de réseau et un registre les interprétait par rapport à des objectifs de ressource partagée et de routage. Les tests des 32 sous-réseaux, 4 096 hôtes et 24 mois n'ont pas survécu en tant que grammaire générale d'allocation.

Pouvoir discrétionnaire recodifié sous différents objectifs techniques

La RFC 1466 réservait le jugement à plusieurs endroits. Les attributions de Classe A restaient à la discrétion de l'IANA. Un demandeur de Classe B en dehors des seuils suggérés pouvait faire valoir que les Classe C étaient techniquement inutilisables. Une allocation de Classe C pouvait s'écarter du barème par défaut lorsque la structure du réseau local le justifiait. Les blocs de Classe C plus grands et d'autres exceptions étaient déterminés au cas par cas.

Son audit possible concernait la supervision par le registre central des plans techniques soutenant les attributions régionales de Classe B. L'autorité était permissive : le registre pouvait exiger une comptabilisation et pouvait auditer. Cette formulation établit le pouvoir discrétionnaire d'agir, et non la preuve que l'action était fréquente ou systématique.

La RFC 2050 a recodifié le pouvoir discrétionnaire plus largement. La conservation, la routabilité et l'enregistrement pouvaient entrer en conflit les uns avec les autres et avec les intérêts individuels. Les registres étaient censés exercer un jugement. Les considérations topologiques pouvaient justifier des écarts par rapport aux directives d'utilisation. L'efficacité du routage, l'historique des attributions antérieures et les plans de réseau étaient évalués au cas par cas. Des deuxièmes avis pouvaient être exigés au-dessus d'un seuil régional.

Le document ultérieur indiquait également que toutes les demandes étaient soumises à un audit et à une vérification et permettait l'invalidation lorsque l'attribution reposait sur de fausses informations. En même temps, il formalisait les obligations de confidentialité et une voie de recours. L'architecture publiée combinait l'autorité de l'examinateur avec des voies déclarées de recours supérieur.

Ce n'était pas une continuation inchangée de la RFC 1466. Le jugement antérieur était centré sur la sélection de classe, la faisabilité de multiples Classe C et les écarts par rapport à un barème par classe. Le jugement ultérieur concernait la longueur du préfixe, le besoin immédiat, l'utilisation, l'agrégation par fournisseur, la probabilité de routage et la conception de réseau sans classe. Des verbes institutionnels similaires cachaient des objets techniques différents.

Le besoin continu est particulièrement convaincant ici. Aucun seuil fixe ne peut représenter toutes les topologies, et la conservation peut entrer en conflit avec l'agrégation de routage. Le jugement d'expert peut persister parce que les cas varient, et non parce qu'une organisation est incapable d'abandonner une pratique antérieure.

L'héritage administratif peut encore avoir de l'importance. Un registre déjà équipé pour recevoir des plans et protéger des informations confidentielles pouvait étendre l'examen à l'utilisation et aux preuves de routage. La délégation hiérarchique plaçait également le jugement à plusieurs niveaux. Pourtant, les sources ne révèlent pas si les examinateurs ont appliqué une culture interprétative stable à travers la rupture documentaire.

La codification ultérieure est observable dans le texte. La cohérence opérationnelle ne l'est pas. Une exception écrite indique que les cas atypiques peuvent être examinés ; elle ne révèle pas la fréquence ou l'orientation des exceptions. L'autorité d'audit identifie un pouvoir ; elle ne révèle pas la méthode de sélection, les constatations ou les conséquences. Une voie de recours écrite identifie un remède ; elle n'établit pas l'accessibilité, l'utilisation ou l'annulation.

L'affirmation de postérité appropriée est donc fonctionnelle et limitée. Le pouvoir discrétionnaire des registres sur la conservation des ressources et la conception du réseau est réapparu dans la RFC 2050, avec un langage d'audit plus large et une disposition de recours écrite. Les critères substantiels ont changé, et les preuves ne montrent pas que le pouvoir discrétionnaire ultérieur a été causé par la RFC 1466 ou exercé uniformément.

Ce que le dossier publié établit — et ce qu'il retient

La séquence documentaire est claire à plusieurs égards. La RFC 1466 a été publiée en mai 1993 en tant que plan Informationnel. Elle contenait des statistiques par classe, des tests de Classe B, des barèmes de Classe C contiguës, des critères de qualification régionaux, des exceptions au cas par cas et un repli central direct. Elle reconnaissait également que le RIPE NCC détenait un bloc de Classe C avant l'adoption.

RIPE 95, valable jusqu'au 30 décembre 1993, montre un formulaire européen demandant des informations réseau actuelles et projetées et prescrivant une voie de registre local de première instance. La RFC 2050 a été publiée en novembre 1996 en tant que BCP 12, a expressément remplacé la RFC 1466 et a codifié l'allocation sans classe, la hiérarchie des fournisseurs, le démarrage lent, l'examen de l'utilisation, la vérification et les appels. La RFC 7020 a fourni une filiation rétrospective de 2013 tout en reconnaissant un changement ultérieur significatif.

Le dossier est mince lorsque l'unité passe d'un document à un cas. Aucune source examinée ne fournit de dénominateur pour le total des demandes, approbations, refus, retraits, exceptions, audits, appels, contacts directs avec le Registre Internet, orientations ou demandes abandonnées. Il n'y a pas de population liée montrant quel canal un demandeur a utilisé en premier, quelles preuves ont été demandées, comment un examinateur a raisonné, quel bloc a été attribué, si une exception s'est appliquée, si un audit a eu lieu ou si un appel a modifié le résultat.

Les registres d'allocation agrégés ne peuvent pas récupérer tous ces faits. Un bloc émis identifie un résultat d'allocation, mais pas les alternatives rejetées, les demandes retirées, les demandeurs non retenus, les motifs de l'examinateur ou la voie par laquelle la demande est arrivée. Un regroupement rétrospectif des blocs par organisation de régulation ne peut pas identifier quelle règle a causé une attribution individuelle.

Les dénominateurs manquants limitent les affirmations de différentes manières. Sans cas de contact direct avec le Registre Internet, le repli de 1993 ne peut pas être classé comme robuste, nominal ou impraticable. Sans populations d'exceptions, les seuils publiés ne peuvent pas être traduits en régularité réelle. Sans registres d'audit, l'autorité ne peut pas être convertie en fréquence d'application. Sans registres d'appel, un recours écrit ne peut pas être évalué en termes d'accès ou d'effet.

La correspondance contemporaine autour de la RFC 2050 répondrait à une question différente. Le successeur disait avoir mis à jour et modifié les dispositions antérieures à la lumière de l'expérience, mais les sources examinées ici ne fournissent pas un compte rendu complet, clause par clause, de ce que les auteurs entendaient conserver, de ce qu'ils considéraient comme obsolète ou de ce qui était peut-être déjà tombé en désuétude. Le remplacement textuel prouve la succession. Il ne divulgue pas tous les motifs du remplacement.

L'absence de ces enregistrements n'est pas une preuve de consentement, d'opposition, d'équité ou d'échec. C'est une limite à l'inférence. Les documents montrent ce que les institutions ont publié, ce qu'un formulaire de fin 1993 demandait aux demandeurs de fournir et comment un successeur de 1996 décrivait le système de registre. Ils n'établissent pas un historique opérationnel à l'échelle de la population.

Cette limite protège également contre une erreur inverse : supposer la persistance institutionnelle simplement parce que les comptes rendus rétrospectifs ultérieurs reconnaissent une filiation. Une filiation peut contenir une révision approfondie. La RFC 2050 a déplacé les seuils par classe, changé l'unité d'allocation en longueur de préfixe, formalisé le démarrage lent et refondu l'agrégation autour des fournisseurs et de CIDR. La RFC 7020 elle-même indique que le système a considérablement changé après 1996.

Une réponse limitée

La RFC 1466 n'était pas textuellement temporaire. Elle ne fournissait aucune expiration, aucune étiquette intérimaire et aucune temporisation institutionnelle. Sa déclaration selon laquelle les recommandations ne feraient que retarder l'épuisement décrivait les limites du remède technique, et non la promesse que la délégation régionale, la divulgation par le demandeur ou le jugement du registre expireraient avec l'allocation par classe.

Elle a cependant été textuellement rendue obsolète en novembre 1996. La RFC 2050 a matériellement déplacé son test de Classe B, son algorithme géographique de Classe C et son barème par classe de 24 mois. L'allocation par longueur de préfixe, les frontières CIDR, la hiérarchie des fournisseurs, le démarrage lent, l'utilisation vérifiée et les projections d'entreprise finale sur un an sont devenus le cadre publié.

Certaines capacités administratives associées au plan de 1993 sont réapparues. Les organisations régionales occupaient une position publiée entre l'IANA et les registres en aval. Les demandeurs continuaient de fournir des preuves de réseau. Les registres continuaient de juger de la rareté, de la topologie et de l'agrégation, désormais selon des critères différents. RIPE 95 fournit un exemple daté d'implémentation au niveau du formulaire, tandis que la RFC 2050 fournit une codification ultérieure et une affirmation sur la pratique actuelle.

Les sources n'établissent pas que la RFC 1466 a causé la persistance de ces capacités. L'administration régionale était déjà en développement avant son adoption. Le besoin technique continu, la responsabilité déléguée, le coût de changement, l'inertie administrative et la codification ultérieure restent des explications plausibles et qui se chevauchent. Le dossier ne répartit pas leur poids causal.

La distinction finale est donc nette. La RFC 1466 n'était pas textuellement temporaire ; elle a été textuellement rendue obsolète en 1996 ; et les preuves publiées montrent une implémentation limitée au niveau du formulaire et une codification ultérieure sans prouver que le plan de 1993 a causé la persistance opérationnelle qui lui est attribuée.