De la faveur à la procédure: les premiers critères écrits pour les demandes d’adresses

Résumé

• Le plus ancien tableau de quantités publié trouvé dans les documents RFC et RIPE examinés est la RFC 1366 d'octobre 1992. La RFC 1174 confirme qu'un modèle de numéros Internet (Internet-Number-Template) existait déjà en août 1990, et les formulaires et manuels d'adresses antérieurs à 1990 n'ont pas été recherchés de manière exhaustive.
• Les règles publiées et les communications opérationnelles documentent des données d’entrée de plus en plus connaissables, des points de référence quantitatifs, des vérifications d’analyse syntaxique, des procédures de correction, des plans d'ingénierie confidentiels, des exceptions énoncées et, finalement, un droit de recours. Elles décrivent la conception procédurale et la pratique du registre; les documents trouvés ne montrent pas comment une demande identifiée s'est terminée.
• Les preuves de pratique examinées se composent d'une discussion partielle de demande et de trois observations opérationnelles ou institutionnelles, et non de quatre cas de demandeurs aboutis. Aucune chaîne complète identifiée ne relie une demande initiale, les critères contemporains, les corrections, les motifs, l'attribution finale, la révision et un recours ayant modifié le résultat, de sorte que la cohérence et les taux de succès ou de refus restent non mesurés.

Le 22 mars 1994, Keith Mitchell de PIPEX a demandé à un groupe de registres locaux européens comment gérer une justification problématique pour un espace d'adressage. PIPEX avait reçu ce que Mitchell a appelé «quelques demandes d'enregistrement» pour un nombre important non spécifié de réseaux de classe C. Chaque réseau proposé ne contiendrait apparemment que cinq ou six hôtes. La réponse habituelle de PIPEX dans de telles circonstances était d'attribuer peut-être un ou deux réseaux de classe C et de recommander le sous-réseautage.

L'obstacle invoqué par les demandeurs était technique. Selon le récit de Mitchell, le logiciel de routage pour les serveurs Novell ou le produit LAN WorkPlace de la société ne pouvait pas découper un espace de classe C en sous-réseaux. Si cette prémisse était fondée, un réseau par segment physique pourrait faciliter le fonctionnement des systèmes des demandeurs. Cela consommerait également plus de numéros de réseau que l'approche normale de PIPEX. Mitchell a demandé si le registre local devait accommoder cette limitation ou la traiter comme un problème du fournisseur.

La discussion s'est rapidement transformée en vérification des faits.Ian Harding a renvoyé au Guide du superviseur NetWare de Novell, où un exemple de configuration suggérait que le sous-réseautage était pris en charge.Bob Day a proposé une attribution immédiate « raisonnable », assortie d'un avertissement selon lequel la même explication aurait moins de poids lors d'une demande ultérieure.John Williams a décrit une installation utilisant un espace de classe C découpé en sous-réseauxet a expliqué que le proxy ARP résolvait un problème de résolution d'adresse connexe. Dans un autre message,Day a conseillé de rejeter la raison invoquée tout en cherchant une réponse définitive par l'intermédiaire d'un contact chez Novell.

Il s'agissait d'un examen par les pairs d'une limitation logicielle alléguée, non d'un cas d'attribution abouti. Les archives ne contiennent pas les demandes, l'identité des demandeurs, les quantités précises demandées, les versions logicielles, les schémas de réseau, les prévisions de croissance, les modifications ultérieures ni aucune évaluation de l'effet sur l'agrégation globale des routes. La correspondance s'arrête avant une décision motivée, une attribution, un refus, une révision ou un recours.

Néanmoins, cet échange capture un moment administratif significatif. Un registre local n'a pas accepté une justification technique simplement parce qu'un demandeur l'avait fournie. Les opérateurs ont comparé l'affirmation avec la documentation et l'expérience déployée. Ils ont exploré un accommodement provisoire et ont considéré si le fournisseur d'équipement devait supporter une partie du coût d'ajustement. Le jugement technique était exercé à la vue des pairs plutôt qu'au cours d'une conversation entièrement privée.

La fin manquante empêche ce fragment d'avoir plus de poids. Le conseil d'attribuer une quantité « raisonnable » ne fournit ni quantité ni résultat. Une configuration réussie ailleurs peut affaiblir une affirmation générale sur la capacité du produit tout en laissant ouvert le coût du changement d'une installation particulière. Le conseil de rejeter une raison n'est pas un refus de la demande. Les demandeurs ont pu réviser leurs plans, fournir des preuves supplémentaires, accepter un bloc plus petit ou abandonner le problème; le dossier ouvert ne permet pas de choisir entre ces voies.

Cette limite encadre la question historique. Pendant la période examinée ici, les formulaires publics et les directives numériques ont clairement changé ce qu'un demandeur était censé divulguer. Certaines étapes administratives sont devenues lisibles par machine et corrigible. Les tableaux ont créé des points de référence par rapport auxquels les écarts pouvaient être reconnus. La question la plus difficile est de savoir si ces instruments contrôlaient régulièrement le jugement final. Pour y répondre, il faut des transactions, pas seulement des documents d'orientation.

Ce que couvre cette enquête

Le corpus public examiné pour cet article comprend les registres de numéros attribués; les RFC sur la politique des identificateurs, les critères de gestion des adresses, les calendriers de mise en œuvre, le traitement des enregistrements et la pratique des registres; les formulaires de demande RIPE et les annonces de version; certains comptes rendus de réunions RIPE; et quatre artefacts opérationnels ou institutionnels examinés en détail.

La séquence des RFC va du registre des numéros attribués de 1988 à la RFC 1174, la RFC 1366, la RFC 1367, la RFC 1400, la RFC 1466, la RFC 1467 et la RFC 2050. Les principaux formulaires destinés aux demandeurs sont RIPE-095 et son successeur immédiat, RIPE-098. Les quatre artefacts de pratique sont la discussion PIPEX, un avis du 19 mars 1993 sur les contrôles d'attribution et de mise à jour, la description par Daniel Karrenberg en mai 1993 de la pratique d'attribution conservatrice, et le compte rendu de RIPE-18.

Il s'agit d'une enquête limitée aux sources publiques. Les manuels, modèles, mémorandums et correspondances antérieurs spécifiques aux adresses n'ont pas été recherchés de manière exhaustive. Leguide du Computer History Museum pour les archives SRI ARC/NICidentifie 281 boîtes couvrant une histoire institutionnelle beaucoup plus large, avec des dates en vrac s'étendant jusqu'au début des années 1990. Le guide est une carte des fonds possibles plutôt qu'une preuve du contenu ou de l'utilisation d'un formulaire non examiné.

« Premier » dans le titre est donc une question en cours d'audit. La RFC 1174 établit qu'un modèle de numéros Internet (Internet-Number-Template) était déjà en vigueur en août 1990. Le premier tableau de quantités publié trouvé dans les documents RFC et RIPE examinés apparaît dans la RFC 1366 en octobre 1992. Cette constatation laisse la place à un formulaire, un manuel ou une instruction antérieure qui pourrait modifier la chronologie.

Le dénominateur de pratique nécessite la même retenue. Les quatre artefacts ne sont pas quatre cas aboutis. L'un est une discussion partielle concernant un « couple » non spécifié de demandes; les autres sont un avis de contrôle opérationnel, un compte rendu illustratif d'un responsable et un compte rendu de réunion de rapports non identifiés. La population plus large des demandes, corrections, octrois, refus et dossiers restreints n'a pas de décompte fiable dans le matériel examiné.

Onze étapes à l'intérieur d'une demande d'adresse

Un seul mot comme « traitement » cache plusieurs événements administrativement distincts. Les documents révèlent onze étapes, et les preuves nécessaires pour une étape ne peuvent pas simplement être empruntées à une autre.

Soumissioncommence par l'acheminement de la demande vers le bureau responsable. La bonne destination variait selon la date, la région, l'affiliation réseau, le type de ressource et la présence d'un registre délégué. Un message envoyé à la mauvaise boîte aux lettres pouvait être transféré ou renvoyé avant que quiconque n'examine le besoin technique.

Syntaxeconcerne la représentation de la demande. Une machine ou un employé devait reconnaître le modèle et analyser son contenu. Un formulaire obsolète ou un champ mal formé pouvait interrompre la transaction même lorsque le plan de réseau sous-jacent était solide.

Complétudedemande si la soumission contient les éléments nécessaires à l'évaluation. Selon l'instrument, ces éléments comprenaient les machines actuelles et projetées, le nombre de sous-réseaux, les avoirs existants, les plans de connexion, la topologie, les dispositions de routage et les contacts responsables. Une demande d'informations supplémentaires laisse la question de fond ouverte.

Besoin techniqueconcerne la conception du réseau elle-même. Les responsables devaient juger si chaque machine proposée avait besoin d'une adresse unique au niveau mondial, si un bloc de réseaux de classe C pouvait remplacer une classe B, si le sous-réseautage était pratique et si les prévisions reposaient sur des plans crédibles.

Préoccupation de routage global ou d'agrégationappartient à un niveau différent du problème de routage interne du demandeur. Des annonces fragmentées imposaient des coûts aux routeurs et aux opérateurs de l'Internet entier. La limitation Novell alléguée dans la discussion PIPEX concernait la configuration des demandeurs eux-mêmes; le fil de discussion conservé ne contient aucune évaluation de l'agrégation globale.

Exceptionest un écart par rapport à un critère ordinaire. Une topologie dispersée pouvait nécessiter plus de numéros de réseau que le seul total d'hôtes ne l'impliquait. Une contrainte d'équipement pouvait également être invoquée, bien qu'un responsable puisse contester sa prémisse. Une catégorie d'exception publiée réduit les motifs pertinents de discrétion même lorsque le cas qui en résulte n'est pas public.

Motifexplique pourquoi la demande a évolué comme elle l'a fait. Une erreur d'analyse, une prévision manquante et un jugement selon lequel l'espace de classe C pouvait répondre au besoin sont des explications différentes. Un enregistrement des motifs relierait les faits acceptés et la version applicable à une réponse procédurale ou de fond.

Correctionpermet au demandeur de réparer, clarifier ou compléter la soumission. Cela peut impliquer de corriger l'interprétation d'un analyseur, de fournir un plan d'ingénierie ou de mettre à jour une prévision. La correction se produit dans le cadre du processus initial et peut laisser la question de l'attribution éventuelle intacte.

Résultatest la décision administrative: octroi tel que demandé, octroi sous une autre quantité ou forme, renvoi, report pour information, retrait, refus ou statut non résolu. Une entrée ultérieure montrant un bloc attribué ne révèle qu'une partie de cette histoire.

Révisionest le réexamen par le registre attributaire, un registre parent ou un autre niveau autorisé. Ses preuves comprendraient la décision contestée, le dossier fourni au réviseur et l'évaluation du réviseur.

Recoursenregistre ce que la révision a accompli. Une décision pouvait être confirmée, modifiée, renvoyée pour travail supplémentaire ou remplacée par une autre décision. L'existence d'une révision ne dit rien en soi sur le fait que le résultat ait changé.

Le fil PIPEX atteint la soumission, l'évaluation du besoin technique, une exception alléguée et la vérification des faits par les pairs. Décrire sa portée exacte est plus utile que de l'appeler un cas incomplet et de suppléer mentalement les étapes manquantes.

Avant un tableau de quantités public

Le premier matériel de la séquence examinée montre un registre de numéros en fonctionnement avant de révéler une formule d'attribution publique.

RFC 1062,Internet Numbers, est parue en août 1988 en tant que rapport d'état officiel. Elle identifiait l'Hostmaster au DDN Network Information Center, exploité par SRI International, comme la source des informations sur les numéros de réseau courants. Le document énumérait les numéros de réseau attribués, les numéros de système autonome et les contacts responsables. Il distinguait les environnements de recherche, de défense, gouvernementaux et commerciaux, tout en notant qu'un réseau numéroté indépendamment devait demander une autorisation d'interconnexion séparément.

Cette séparation est facile à négliger. L'enregistrement fournissait l'unicité et les informations de contact; il n'accordait pas automatiquement la connectivité. La liste des numéros attribués montre également le déséquilibre de visibilité qui persisterait tout au long de la période. Les attributions finalisées entraient dans des registres publics durables, tandis qu'une demande retirée, redirigée ou refusée pouvait ne laisser aucune entrée correspondante. Le registre ne peut pas reconstituer la quantité initialement demandée, les preuves fournies ou le raisonnement derrière la classe d'adresse choisie.

En août 1990, laRFC 1174faisait explicitement référence au « modèle actuel de numéros Internet » (Internet-Number-Template). Vinton Cerf est l'auteur de ce document informatif, qui représentait l'avis officiel de l'Internet Activities Board et transmettait des recommandations au Federal Networking Council.

La RFC 1174 décrivait l'IANA comme une fonction remplie par l'Information Sciences Institute de l'Université de Californie du Sud. Elle indiquait que l'IANA avait confié la responsabilité des identificateurs de réseau et de système autonome à un registre Internet exploité par SRI International au DDN-NIC. L'architecture recommandée conservait les fonctions centrales de l'IANA et du registre Internet tout en permettant aux organisations approuvées de recevoir des blocs et de procéder à des attributions supplémentaires.

Une deuxième recommandation concernait le concept de plus en plus problématique de statut « connecté ». La RFC 1174 proposait de supprimer les références au statut de connexion des formulaires d'enregistrement, d'ajouter des informations sur l'utilisation acceptable, la politique d'accès et de transit, et d'admettre les réseaux enregistrés dans le système de noms de domaine sans faire de ce statut la condition déterminante. Les champs de pays et de politique de trafic faisaient partie des modifications proposées au modèle existant.

Ces recommandations clarifiaient la différence entre l'enregistrement des identificateurs et l'application de la politique d'accès au réseau. Elles montrent également que la conception des formulaires était déjà un instrument de la politique institutionnelle. La RFC ne reproduit pas la version exacte du modèle alors en circulation et ne date pas l'adoption opérationnelle de ses modifications proposées. Ses champs étaient qualitatifs et juridictionnels plutôt qu'un barème reliant la demande à une quantité d'adresses.

Octobre 1992: un point de référence numérique

RFC 1366,Guidelines for Management of IP Address Space, a été publiée en octobre 1992 par Elise Gerich de Merit. Elle était informative, ne spécifiait pas de norme Internet, proposait un plan de gestion des adresses et a ensuite été rendue obsolète par la RFC 1466.

La structure régionale proposée était liée à des qualifications institutionnelles. Les autorités de réseau d'une zone géographique devaient légitimer un registre candidat. L'organisation devait être bien établie et posséder une légitimité extérieure à la fonction de registre. Elle devait disposer de ressources suffisantes pour un service stable, rapide et fiable, s'engager à suivre les directives de l'IANA et du registre Internet, et être disposée à se coordonner avec le registre Internet sur les qualifications et les stratégies de sous-attribution. Le registre Internet restait la racine et le registre par défaut pour les régions sans délégué reconnu.

Ces dispositions liaient la délégation technique au statut régional et à la capacité organisationnelle. Un bloc de numéros à lui seul ne faisait pas d'un bureau un registre régional qualifié. En même temps, les critères étaient énoncés de manière prospective; la RFC 1366 ne contient aucune évaluation continue de la manière dont chaque candidat les satisfaisait.

Le document imposait des restrictions strictes pour l'examen de la classe B. Une organisation devait satisfaire à deux conditions conjonctives: un plan de sous-réseautage documentant plus de 32 sous-réseaux et plus de 4 096 hôtes. La RFC 1366 n'attachait pas la formulation ultérieure des 24 mois aux deux seuils de la classe B. Elle reconnaissait également les circonstances dans lesquelles les blocs de classe C ne pouvaient pratiquement pas remplacer une classe B et permettait que ces circonstances soient examinées au cas par cas.

Pour l'espace de classe C, la RFC faisait correspondre la projection d'un demandeur du nombre d'adresses IP uniques requises sur 24 mois à des blocs contigus:

• moins de 256 adresses correspondait à un réseau de classe C;
• moins de 512 correspondait à deux réseaux de classe C contigus;
• moins de 1 024 correspondait à quatre;
• moins de 2 048 correspondait à huit;
• moins de 4 096 correspondait à seize.

L'unité était le nombre d'adresses IP uniques projetées. Il ne s'agissait pas du nombre d'employés, de clients, de sous-réseaux physiques ou de créneaux d'hôtes utilisables conventionnels. Un réseau de classe C contenait 256 valeurs d'adresse numériques, bien que les configurations d'hôtes ordinaires réservent les valeurs de réseau et de diffusion.

La formulation littérale a une limite non résolue. Chaque ligne dit « moins de », laissant les puissances exactes de deux telles que 256, 512, 1 024, 2 048 et 4 096 en dehors des lignes telles qu'elles sont écrites. Des exemples ailleurs dans le document aident à révéler l'échelle prévue mais ne réécrivent pas le tableau. Le qualifier de point de référence public est plus précis que de l'appeler un algorithme complet.

À l'intérieur d'une ligne, les demandeurs et les responsables pouvaient désormais se référer au même horizon de demande et à la même taille de bloc. Si une projection acceptée tombait en dessous de 1 024 adresses, la ligne publiée indiquait quatre réseaux de classe C contigus. Une quantité différente s'écarterait de cette ligne. La RFC 1366 n'imposait aucune obligation générale de publier une explication spécifique au cas pour un tel écart, et la projection acceptée pouvait rester privée. Néanmoins, le tableau réduisait le vocabulaire de la décision: la quantité pouvait être comparée à une base de référence articulée.

Une grande partie du travail restant consistait à décider quelle entrée était crédible. Une projection sur deux ans pouvait être soigneusement établie ou relever du vœu pieux. Certaines machines pouvaient utiliser un espace privé ou non unique. Une topologie physique pouvait rendre le bloc ordinaire inadapté. Les responsables devaient encore évaluer les preuves techniques, mais leur jugement s'exerçait désormais autour d'un calendrier numérique visible.

LaRFC 1367associée, rédigée par C. Topolcic en octobre 1992, proposait un calendrier de mise en œuvre. Elle prévoyait la poursuite des procédures à partir du 31 octobre 1992, un examen le 14 février 1993 et une attribution selon le plan d'adressage en blocs de classe C de taille appropriée à partir du 15 avril 1993.

Un rapport d'état ultérieur, laRFC 1467, a remplacé ce calendrier en août 1993. Topolcic a rapporté que la plupart des jalons administratifs avaient été mis en œuvre à temps, à l'exception de la livraison et de l'installation du logiciel CIDR. Le rapport indiquait que le RIPE NCC avait reçu un bloc régional et que le registre Internet avait commencé à faire des attributions selon le plan en blocs de classe C de taille appropriée le 15 avril.

La RFC 1467 est une preuve contemporaine significative provenant de l'intérieur du programme. Son récit étaye le constat attribué selon lequel les principaux jalons administratifs ont été atteints. Il reste un rapport institutionnel plutôt qu'une inspection des dossiers de demande, mais cette limite de source ne doit pas effacer les développements opérationnels qu'il enregistre.

Régularité administrative à la frontière de l'InterNIC

En mars 1993, laRFC 1400,Transition and Modernization of the Internet Registration Service, décrivait un type de procédure différent. Scott Williamson de Network Solutions a rédigé le document informatif lors du transfert des services d'enregistrement non DDN suite à l'attribution du contrat de services d'information de la National Science Foundation.

La frontière institutionnelle était spécifique. La RFC 1400 utilisait « InterNIC » pour désigner sa composante Services d'Enregistrement. Les utilisateurs DDN continuaient à recevoir un support d'enregistrement du DDN-NIC par une voie distincte et des formulaires approuvés. Pour les utilisateurs non DDN, les modèles existants du DDN-NIC pouvaient être soumis pendant le mois de mars 1993. Les nouveaux modèles InterNIC entraient en vigueur le 1er avril. Un ancien formulaire envoyé à la boîte aux lettres automatisée était renvoyé avec des messages d'erreur d'analyse et le nouveau modèle attaché, tandis que la voie humaine de l'Hostmaster acceptait temporairement les anciens formats jusqu'au 30 juin.

La séquence automatisée mettait en lumière plusieurs événements administratifs. Un demandeur envoyait un modèle rempli à la boîte aux lettres automatisée. Le serveur de messagerie l'analysait et effectuait des vérifications rapides des informations vérifiables, le conflit de nom de domaine étant donné comme exemple. Il renvoyait soit une vérification, soit un rejet accompagné d'un message d'erreur.

Le demandeur examinait ensuite comment les informations avaient été interprétées. Les données incorrectes pouvaient être corrigées avant le renvoi de la vérification. Suite à un rejet, le demandeur pouvait ajuster la demande d'enregistrement et la soumettre à nouveau. Une vérification corrigée était à nouveau contrôlée. Une fois que les Services d'Enregistrement recevaient une vérification satisfaisante, la demande passait au personnel pour le traitement final. Une vérification sans réponse expirait après sept jours, nécessitant une nouvelle soumission. Un numéro de ticket de support permettait de suivre l'état d'avancement.

Ces mécanismes contraignaient le traitement administratif de manière concrète. Ils révélaient quel formulaire le système acceptait, exposaient les problèmes d'analyse, invitaient à confirmer les informations interprétées et donnaient au demandeur une référence pour suivre l'état. Un formulaire obsolète ne pouvait pas disparaître silencieusement dans une file d'attente. Une erreur lisible par machine pouvait être réparée sans la présenter comme un jugement final sur la rareté.

La portée de l'automatisation était tout aussi concrète. L'analyseur traitait la représentation et les informations vérifiables; le personnel conservait le traitement final. La RFC 1400 n'attribuait pas à la machine la responsabilité d'évaluer une prévision sur deux ans, de choisir une taille de bloc ou de décider si une topologie justifiait une exception. Un décompte des « rejets » automatisés mélangerait donc des événements administratifs avec ce qu'un lecteur moderne pourrait appeler un refus, à moins que les transactions sous-jacentes ne soient classifiées.

En tant que description de processus de Network Solutions, la RFC 1400 enregistre la séquence conçue par le contractant plutôt qu'une mesure de performance échantillonnée indépendamment. Sa contribution à l'histoire procédurale est néanmoins substantielle. En 1993, des parties importantes du chemin d'enregistrement avaient été suffisamment standardisées pour être analysées, vérifiées, corrigées, chronométrées et suivies.

Plans d'ingénierie et déviation structurée

LaRFC 1466, publiée par Elise Gerich de Merit en mai 1993, a explicitement rendu obsolète la RFC 1366. Le successeur informatif conservait le cadre de registre distribué et rendait les preuves attendues des demandeurs plus spécifiques.

L'examen de la classe B exigeait toujours plus de 32 sous-réseaux et plus de 4 096 hôtes. De plus, un demandeur devait soumettre un plan d'ingénierie expliquant pourquoi il était déraisonnable de construire le réseau avec un bloc de réseaux de classe C. Le plan devait indiquer combien d'hôtes le réseau aurait au cours des 24 prochains mois et combien d'hôtes apparaîtraient sur chaque sous-réseau sur le même horizon.

Le plan d'ingénierie devait être tenu strictement confidentiel et utilisé uniquement pour juger si la demande était justifiée. Lorsque les preuves relatives aux hôtes et aux sous-réseaux ne justifiaient pas une classe B, le demandeur recevrait un bloc d'adresses de classe C. La règle décrivait donc une voie d'attribution alternative plutôt qu'un simple choix entre octroi et refus.

Le tableau de classe C s'est étendu vers le haut. Moins de 8 192 adresses correspondait à 32 réseaux de classe C, tandis que moins de 16 384 correspondait à 64. La même ambiguïté de frontière exacte subsistait parce que les lignes continuaient à utiliser « moins de ».

La RFC 1466 fournissait également un exemple de topologie. Six cents hôtes répartis également sur dix Ethernets pouvaient recevoir dix réseaux de classe C, un pour chaque Ethernet, si un plan d'ingénierie justifiait un écart par rapport au tableau par défaut. Un registre pouvait demander un plan où l'incapacité de découper en sous-réseaux créerait un gaspillage excessif. Les exceptions devaient être déterminées au cas par cas.

Cette combinaison constitue une architecture reconnaissable de discrétion structurée. Le tableau indiquait la relation ordinaire entre la demande acceptée et la quantité. L'exemple identifiait la topologie comme un motif pertinent d'écart. Le plan d'ingénierie donnait aux responsables des preuves pour tester ce motif. La confidentialité protégeait la conception interne du demandeur.

Le langage d'audit opérait à l'intérieur d'une hiérarchie définie. Le registre Internet pouvait attribuer de petits blocs de classe B aux registres régionaux, exiger une comptabilité des attributions faites à partir de ces blocs, recevoir les plans d'ingénierie des demandeurs et vérifier que ces plans étaient conformes aux directives. Le texte établit l'autorité et une voie probatoire; il n'identifie pas un audit qui aurait modifié une attribution nommée.

Prises ensemble, les directives de 1992 et 1993 rendaient plusieurs choix de fond plus contestables. Un demandeur pouvait invoquer une ligne par défaut, expliquer pourquoi la topologie la déplaçait et savoir qu'une demande de classe B exigeait plus qu'une échelle organisationnelle. Les preuves les plus sensibles, cependant, étaient conçues pour rester en dehors de la comparaison publique.

Un formulaire en vigueur pendant quatorze jours

Leformulaire de demande de numéro de réseau IP européen RIPE-095 et notes de supporta converti une grande partie de cette politique en champs qu'un demandeur pouvait remplir. Anne Lord et Daniel Karrenberg sont les auteurs du document, publié le 1er octobre 1993 en tant que mise à jour de RIPE-088.

Le formulaire portait une date d'expiration au 30 décembre 1993. Cette date ne déterminait pas combien de temps il resterait la version la plus récente. Uneannonce de document du 15 octobre pour RIPE-098indiquait que le formulaire révisé rendait obsolète RIPE-095 et ajoutait une recommandation selon laquelle les registres locaux devaient consulter le RIPE NCC pour les demandes de 32 réseaux de classe C ou plus. RIPE-095 a donc été le formulaire publié le plus récent pendant quatorze jours.

Sa structure en quatre parties séparait différents types de preuves.

La partie A recueillait le nom du réseau, une description de l'organisation, le pays, les contacts administratifs et techniques, les informations de modification et les enregistrements de personnes. Ces données, ainsi que les numéros de réseau attribués, étaient destinées à un registre accessible au public.

La partie B rassemblait des informations techniques confidentielles: le type de demande; le nombre de machines actuel, à un an et à deux ans; le nombre de sous-réseaux actuel, à un an et à deux ans; le plan de connexion Internet; les avoirs en réseaux IP existants; et les pays dans lesquels le réseau fonctionnerait.

La partie C exigeait une description du réseau pour les demandeurs sollicitant plus de deux réseaux de classe C. Le demandeur devait décrire la configuration actuelle et les plans pour les deux années suivantes, y compris les tailles de sous-réseaux et les composants réseau pertinents. Des demandes plus importantes invitaient à plus de détails.

La partie D identifiait un représentant agissant pour le compte d'une autre organisation. Cela importait parce que la personne qui remplissait le formulaire, le fournisseur de services, l'organisation demandeuse et l'utilisateur final des adresses pouvaient jouer des rôles différents.

Les exemples numériques du formulaire utilisaient des quantités d'hôtes utilisables conventionnelles. Une classe C était associée à un maximum de 254 hôtes, deux à 508, quatre à 1 016, huit à 2 032, seize à 4 064 et trente-deux à 8 128. Ces chiffres diffèrent des seuils de la RFC 1366 exprimés en 256, 512, 1 024 et quantités connexes d'adresses brutes. « Machines », « hôtes utilisables » et « adresses » doivent rester distincts lors de la reconstitution d'une demande par rapport à la version pertinente.

RIPE-095 distinguait également une demande initiale d'une demande d'espace supplémentaire. Une organisation cherchant un espace d'adressage supplémentaire était invitée à décrire les réseaux précédemment attribués, les numéros utilisés et inutilisés, les sous-réseaux installés, les hôtes connectés et les détails structurels. Les objectifs énoncés comprenaient une meilleure utilisation du pool d'adresses disponible et la préservation de blocs contigus lorsque cela était possible pour l'agrégation.

Le routage institutionnel apparaissait sur le formulaire lui-même. Les demandeurs s'adressaient normalement d'abord à un registre local. Les adresses de classe B étaient attribuées au niveau régional, de sorte qu'un registre local qui estimait une demande de classe B justifiée la transmettait au RIPE NCC pour examen. Les informations techniques restaient confidentielles et n'entraient pas dans le registre public de gestion du réseau.

Pour un demandeur, cela représentait un gain considérable en termes de prévisibilité. Les preuves attendues pouvaient être rassemblées avant la soumission. Les demandes plus exigeantes déclenchaient visiblement des descriptions plus exigeantes. Le changement rapide de RIPE-095 à RIPE-098 démontre également une maintenance active et l'importance d'identifier la version en vigueur à une date donnée.

Un formulaire vierge rempli diffère encore d'un dossier de décision. Le formulaire nomme les entrées et les voies; il ne révèle pas quelle prévision un examinateur a acceptée, comment les considérations concurrentes ont été pondérées ou quelle quantité a été finalement attribuée. Ces faits devraient être joints au formulaire par le biais du dossier de transaction.

BCP 12 et une voie de recours publiée

En novembre 1996, le cadre public était devenu sans classe et plus élaboré. LaRFC 2050,Internet Registry IP Allocation Guidelines, a été publiée en tant que Best Current Practice 12 et remplaçait la RFC 1466. Ses auteurs étaient Kim Hubbard, Mark Kosters, David Conrad, Daniel Karrenberg et Jon Postel, avec des affiliations couvrant InterNIC Registration Services, APNIC, RIPE NCC et USC/ISI.

La note de l'IESG délimitait soigneusement le statut du document. L'approbation en tant que Best Current Practice exprimait la conviction de l'IESG que la politique représentait fidèlement la pratique des registres de l'époque. Elle refusait expressément toute approbation ou recommandation. La RFC 2050 est donc plus solide qu'un calendrier proposé en tant que compte rendu institutionnel de la pratique opérationnelle, tout en restant différente d'un audit de cas.

Le document décrivait une hiérarchie de l'IANA, des registres régionaux et des registres locaux. Il nommait InterNIC pour l'Amérique du Nord, RIPE NCC pour l'Europe et APNIC pour la région Asie-Pacifique. Il distinguait également les attributions aux fournisseurs des assignations aux entreprises finales. Cette distinction régissait à la fois les horizons temporels et les dénominateurs utilisés dans les règles ultérieures.

Pour les fournisseurs d'accès Internet, le « démarrage lent » signifiait une attribution initiale minimale basée sur un besoin immédiat démontré. Les attributions ultérieures pouvaient augmenter après vérification de l'utilisation. Une attribution supplémentaire était destinée à fournir environ trois mois de capacité d'assignation avant que le fournisseur ne revienne à son registre parent. Une simple projection de la clientèle avait peu de poids.

La période de trois mois concernait le réapprovisionnement des fournisseurs. Ce n'était pas la projection sur 24 mois de la RFC 1366 et ne régissait pas la même population. L'une concernait la capacité qu'un fournisseur recevait d'un registre parent; l'autre faisait correspondre le besoin projeté d'un demandeur à des blocs classful.

Les informations de réassignation constituaient un autre contrôle au niveau du fournisseur. Les sous-registres devaient enregistrer les assignations rapidement afin que les contacts opérationnels puissent être trouvés, que l'utilisation puisse être vérifiée et que des études sur les adresses puissent être menées. Un registre régional ou un fournisseur amont ne devait pas faire une autre attribution CIDR avant qu'environ 80 % de toutes les informations de réassignation aient été soumises. Le pourcentage mesurait la couverture documentaire sur l'ensemble des assignations concernées, pas l'utilisation des hôtes.

Les assignations aux sites finaux utilisaient des directives différentes. Les seuils de base étaient de 25 % d'utilisation immédiate et de 50 % dans un délai d'un an. La RFC 2050 définissait l'utilisation prévue comme le nombre d'hôtes connectés au réseau divisé par le nombre total d'hôtes possibles sur ce réseau. Les hôtes connectés fournissaient le numérateur; le total des hôtes possibles fournissait le dénominateur. Les employés, les clients et les enregistrements de réassignation ne faisaient pas partie de ce calcul.

Les plans d'ingénierie devaient inclure les masques de sous-réseau, le nombre d'hôtes sur chaque sous-réseau, la topologie et les dispositions de routage. Les avoirs précédents pouvaient être pris en compte pour les divisions ou filiales sous un même parent. Les plans de déploiement et la confiance dans les projections comptaient également. Les organisations de moins de 128 hôtes ne recevaient normalement pas d'espace directement d'un registre régional, bien que des préfixes plus longs puissent être émis dans des circonstances spécifiées.

L'adressage basé sur le fournisseur comportait une attente de renumérotation. Les adresses étaient traitées comme des prêts pour la durée de la connectivité. Lorsqu'un client changeait de fournisseur, la recommandation était de rendre les adresses existantes et de renuméroter dans l'espace du nouveau fournisseur, avec un délai suffisant avant que les anciennes adresses ne soient réutilisées. L'objectif était l'agrégation, pas la reconnaissance d'un droit permanent et portable.

La RFC 2050 reconnaissait ouvertement les tensions entre la conservation, la routabilité et l'enregistrement. Un jugement prudent était nécessaire dans les cas individuels. Les registres régionaux pouvaient auditer et vérifier les demandes par les moyens qu'ils jugeaient appropriés, et les assignations basées sur de fausses informations pouvaient être invalidées. Les fournisseurs de transit pouvaient filtrer les routes même lorsqu'un registre avait attribué les adresses sous-jacentes. Une assignation de registre ne garantissait donc pas la routabilité mondiale.

La confidentialité a acquis un chemin défini vers le registre parent. Un registre attributaire devait protéger les informations que le demandeur identifiait spécifiquement comme sensibles. Si le demandeur n'avait pas l'assurance que le registre local pouvait fournir une confidentialité adéquate, le parent pouvait traiter l'évaluation et communiquer la quantité appropriée vers le bas.

Le titre de la section du document était explicite:Droit de recours. Une organisation qui estimait qu'un registre attributaire n'avait pas rempli sa tâche de la manière requise pouvait faire appel au registre parent. Le registre attributaire devait fournir la documentation pertinente. Un appel supplémentaire pouvait remonter la hiérarchie, l'IANA étant disponible pour une décision finale après l'épuisement des autres voies. Chaque registre devait indiquer comment une décision d'attribution pouvait faire l'objet d'un appel.

Ce langage séparait la correction de la révision plus clairement que les instruments antérieurs. Une correction d'analyse réparait les informations avant le traitement final. Un appel contestait une décision d'attribution. La révision était l'examen de cette contestation par le parent. Le recours serait la décision qui en résulterait – confirmation, modification, renvoi ou remplacement de la décision initiale.

Les documents de pratique examinés ne contiennent aucun dossier d'appel identifié. La RFC 2050 a néanmoins placé une voie de révision, un devoir de transfert de documents et un chemin d'escalade dans le domaine public. À la fin de la période, un demandeur pouvait invoquer plus qu'une opportunité informelle de demander à un responsable supérieur de réexaminer la question.

Quatre artefacts de pratique

Le dossier opérationnel examiné ici est restreint mais varié. Sa valeur dépend de la classification de chaque élément en fonction de ce qu'il enregistre réellement.

La correspondance PIPEX est la seule discussion partielle de demande. Elle commence par un « couple » non spécifié de demandes et montre une vérification technique des faits avant la décision. Elle ne conserve ni une quantité exacte demandée, ni une réponse du demandeur, ni une décision.

Le deuxième artefact est l'avis de Marten Terpstra du19 mars 1993, « Typos in assignments ». Terpstra écrivait que les erreurs typographiques dans les assignations et les mises à jour du registre étaient « en augmentation », en particulier la confusion entre les numéros commençant par 192 et 193. Il décrivait également les assignations et mises à jour ordinaires envoyées aux mauvaises boîtes aux lettres.

Le RIPE NCC a introduit des contrôles plus stricts sur le matériel envoyé à l'adresse d'assignation. Si un réseau apparaissait déjà dans les enregistrements pertinents, l'élément était d'abord rejeté et une erreur était envoyée au personnel du NCC. Le personnel déterminait si le problème était probablement une erreur typographique ou l'utilisation du mauvais canal de soumission. Une mise à jour envoyée à la mauvaise boîte aux lettres pouvait être transférée pour traitement; un numéro soupçonné d'être mal saisi pouvait entraîner un contact avec l'expéditeur.

Il s'agit d'un contrôle opérationnel pour les avis d'assignation et les mises à jour. Il montre une division annoncée entre les erreurs de canal et les erreurs de données probables. « En augmentation » n'a pas de base de référence, de période d'observation ou de décompte, et le message ne contient aucune correction complète liée à une demande d'adresse originale. Il appartient à l'histoire des garde-fous administratifs plutôt qu'à un dénominateur des résultats des demandeurs.

Le troisième artefact est le message de Daniel Karrenberg du14 mai 1993 sur « Supernet block sizes ». Karrenberg décrivait une approche conservatrice pour une demande importante et faiblement étayée de classe C. Le registre pouvait attribuer moins que le montant demandé tout en réservant un espace contigu pour un besoin ultérieur. Le demandeur pouvait revenir avec des preuves montrant l'utilisation de l'attribution initiale. L'espace réservé devait être recyclé après 12 à 18 mois.

Cet intervalle faisait référence à la conservation d'un espace contigu réservé avant recyclage. Ce n'était ni un délai de décision ni un horizon de projection général. L'illustration numérique de Karrenberg impliquait une demande de 64 réseaux de classe C qui manquait de justification solide, suivie dans l'exemple d'une attribution de 16 ou 32 et d'une réservation du même montant.

Le passage est la description par un responsable d'une pratique recommandée, pas une réduction observée. Il ne nomme aucun demandeur, formulaire soumis, dossier d'attribution ou résultat final. Karrenberg a également écrit qu'après environ un an, seule une « petite partie » revenait pour plus d'espace. « Petite partie » reste non quantifiée: le message ne fournit ni numérateur ni dénominateur.

La logique politique est néanmoins instructive. Attribuer une portion initiale réduisait le coût d'une prévision faible. Réserver un espace adjacent protégeait une option d'agrégation de routes si la demande ultérieure se matérialisait. Recycler après un intervalle déterminé limitait le coût de conserver cette option ouverte indéfiniment. La communication révèle comment un responsable de registre décrivait l'équilibre entre conservation et agrégation en situation d'incertitude.

Le quatrième artefact est lecompte rendu de RIPE-18. Les entités ont rapporté des incidents dans lesquels des demandes rejetées en Europe étaient acceptées après une nouvelle demande auprès d'autres registres régionaux. Le groupe a exprimé son inquiétude quant à la disparité entre les critères de RIPE et d'InterNIC et a chargé Daniel Karrenberg de transmettre cette inquiétude à InterNIC.

Les entités ont également convenu qu'un formulaire révisé devrait poser des questions sur les organisations mères, les avoirs d'adresses existants, les demandes antérieures et les demandes précédemment refusées. La réponse institutionnelle a donc été concrète: un problème signalé a produit un point d'action et des modifications proposées aux informations recueillies auprès des futurs demandeurs.

Le compte rendu ne fournit pas les demandes sous-jacentes à ces rapports. Il n'identifie aucun demandeur, date, quantité, avis de décision, fait modifié, attribution ultérieure ou réviseur. « Incidents » ne porte pas de décompte. Le document établit ce que les entités ont rapporté et comment le groupe a réagi, tout en laissant l'équivalence entre la première demande et les demandes ultérieures non testée.

Pris ensemble, les artefacts montrent une consultation technique ouverte, un contrôle des mises à jour d'assignation, un compte rendu officiel d'attribution conservatrice et une réponse de gouvernance à la disparité régionale signalée. Aucun ne fournit un taux de succès, de refus, de correction, de réduction, d'exception ou d'annulation.

Confidentialité et forme de la survie

La moitié privée d'une demande d'adresse pouvait contenir les faits les plus pertinents pour son résultat. Les plans d'ingénierie exposaient la topologie interne, l'expansion projetée, les limitations d'équipement, la segmentation du réseau, la distribution des hôtes et parfois les intentions commerciales. Les publier automatiquement pouvait décourager les prévisions franches.

Les instruments ont répondu en séparant les données d'identité publiques des preuves techniques sensibles. RIPE-095 plaçait les contacts administratifs et les numéros attribués dans le registre public tout en réservant les détails techniques à un usage interne. La RFC 1466 exigeait une stricte confidentialité pour les plans d'ingénierie de classe B. La RFC 2050 protégeait les informations spécifiquement désignées comme sensibles et offrait un traitement par le registre parent lorsque le registre attributaire ne pouvait pas fournir une assurance adéquate.

La confidentialité pouvait améliorer la qualité des décisions. Un responsable essayant de distinguer un besoin opérationnel d'une accumulation spéculative avait besoin de détails qu'une organisation pouvait raisonnablement vouloir cacher à ses concurrents ou au grand public. Une soumission protégée créait un espace pour un compte rendu plus complet.

Elle a également façonné ce que les observateurs ultérieurs peuvent mesurer. Une entrée d'attribution peut identifier une organisation, une date et un bloc d'adresses tout en retenant la prévision ou la topologie qui justifiait la quantité. Inversement, un formulaire vierge conservé montre les entrées attendues sans rien dire sur la manière dont un examinateur les a traitées.

La conservation est susceptible de favoriser les résultats visibles. Les attributions réussies ont généré des registres publics et des dépendances opérationnelles ultérieures. Une demande abandonnée ou infructueuse peut se terminer par une correspondance privée, un appel téléphonique ou aucune entrée durable. Les modifications peuvent avoir remplacé les versions antérieures plutôt que de rester à côté d'elles. Les dossiers d'ingénierie restreints peuvent subsister dans des conditions d'accès qui empêchent la comparaison publique.

Ces forces expliquent pourquoi un registre d'attribution ne peut pas servir d'échantillon représentatif des demandes originales. Elles n'établissent pas la taille ou la direction des résultats manquants. La confidentialité est compatible avec un examen minutieux et cohérent et avec des variations inexpliquées; les preuves publiques seules ne peuvent pas choisir entre ces possibilités.

Là où l'automatisation s'est arrêtée

Le contraste entre la RFC 1400 et les directives substantielles sur les adresses clarifie ce que la procédure écrite pouvait facilement contrôler.

Le choix du modèle, l'analyse automatique, la vérification, la nouvelle soumission, l'expiration et l'état du ticket étaient relativement déterminés. Le processus pouvait identifier un formulaire obsolète, renvoyer une erreur, inviter à une correction et enregistrer si la vérification arrivait dans les sept jours. L'avis d'assignation de Terpstra spécifiait de même comment le personnel devait distinguer une mauvaise boîte aux lettres d'un numéro probablement mal saisi.

Les jugements substantiels de rareté impliquaient des variables moins observables. Les prévisions dépendaient des achats prévus, de la croissance organisationnelle et des applications non encore déployées. Une topologie pouvait rendre la quantité par défaut inefficace. Les limitations d'équipement pouvaient être authentiques, spécifiques à une version, temporaires ou mal comprises. Les coûts d'agrégation incombaient en partie à d'autres opérateurs de réseau plutôt qu'au demandeur.

Les règles écrites structuraient néanmoins ces décisions. La RFC 1366 fournissait une base de référence liant la demande au bloc. La RFC 1466 identifiait le contenu d'un plan d'ingénierie de classe B et publiait un écart fondé sur la topologie. RIPE-095 indiquait aux demandeurs quels comptes de machines, sous-réseaux, avoirs et plans importaient. La RFC 2050 définissait l'utilisation des sites finaux et exposait le conflit entre conservation et routabilité.

Ce qui restait difficile à voir était le pont entre les preuves acceptées et la quantité finale. La confidentialité cachait de nombreuses données décisives. Les clauses d'exception publiées révélaient des catégories pertinentes sans créer de registre public de leur utilisation. Une voie de révision spécifiait un chemin d'escalade sans montrer le recours qui en résultait.

Les preuves sont donc les plus solides à la frontière administrative. Les formulaires et l'automatisation ont de manière démontrable structuré la manière dont les informations entraient dans le système. Les tableaux et les exigences de plans d'ingénierie rendaient certaines parties du jugement substantiel contestables. Mesurer leur influence sur les décisions finales nécessite des dossiers au niveau du demandeur reliés à travers ces étapes.

L'autorité a évolué avec le système de registre

La période ne peut pas être décrite comme un bureau adoptant progressivement plus de paperasse. Différentes organisations remplissaient différentes fonctions, et ces fonctions ont changé.

En 1990, la RFC 1174 décrivait l'IANA comme une fonction remplie par USC/ISI et le registre Internet pour les identificateurs de réseau et de système autonome comme une fonction exploitée par SRI International au DDN-NIC. L'Internet Activities Board recommandait la politique. Il ne traitait pas lui-même chaque demande de numéro.

Le DDN-NIC desservait également un environnement de réseau de défense. La RFC 1400 préservait une voie distincte pour les utilisateurs DDN tout en transférant les services d'enregistrement non DDN au Service d'Enregistrement InterNIC exploité par Network Solutions. « InterNIC » était une étiquette plus large, mais les affirmations procédurales de la RFC concernaient spécifiquement les Services d'Enregistrement.

Les RFC 1366 et RFC 1466 proposaient et décrivaient une délégation régionale sous l'autorité de l'IANA et du registre Internet. Le RIPE NCC recevait des blocs pour l'Europe et coordonnait les registres locaux. Un fournisseur de services local pouvait être simultanément le fournisseur de connectivité du demandeur, son conseiller et son premier examinateur. Le RIPE NCC conservait les fonctions régionales, y compris l'examen des questions de classe B selon la structure publiée.

En 1996, la RFC 2050 présentait la hiérarchie comme IANA, registres régionaux et registres locaux, nommant InterNIC, RIPE NCC et APNIC. Le compte rendu provenait d'auteurs affiliés à ces institutions et décrivait les pratiques de registre qu'ils disaient être en vigueur.

L'autorité était stratifiée plutôt que singulière. L'unicité mondiale dépendait de la coordination technique. Les blocs délégués donnaient aux bureaux régionaux et locaux un contrôle opérationnel. Les contrats et subventions gouvernementaux soutenaient des arrangements de service particuliers. La reconnaissance régionale et la participation communautaire contribuaient à la légitimité institutionnelle. Les relations avec les fournisseurs affectaient le routage et la renumérotation. Les documents publics fournissaient un préavis et un vocabulaire technique partagé.

Projeter le modèle ultérieur de registre régional en arrière obscurcirait ces transitions. Traiter la coordination technique comme un mandat légal illimité créerait une distorsion différente. À chaque date, l'enquête pertinente est de savoir quel bureau remplissait la fonction, comment ce rôle est apparu et quelle procédure s'appliquait à la demande en question.

Pourquoi le jugement restait opérationnellement défendable

Un système d'attribution entièrement mécanique aurait mal performé face à l'incertitude de la croissance initiale de l'Internet.

Les machines actuelles pouvaient être comptées, mais les prévisions sur deux ans dépendaient des achats, de l'expansion organisationnelle, de l'architecture du réseau et des services encore en planification. Les demandeurs étaient incités à éviter les demandes répétées et les renumérotations perturbatrices. Les registres étaient incités à résister à l'accumulation. Aucune des deux parties ne possédait d'informations complètes.

La topologie affaiblissait toute règle simple de comptage d'hôtes. Six cents hôtes sur un campus pouvaient présenter un problème d'ingénierie différent de 600 hôtes répartis sur dix réseaux physiques. L'exemple des dix Ethernets de la RFC 1466 reconnaissait qu'un total identique pouvait justifier une quantité différente de numéros de réseau.

Le routage ajoutait une externalité. Un demandeur supportait l'inconvénient local du sous-réseautage ou de la renumérotation. D'autres opérateurs de réseau supportaient la charge de mémoire, de traitement et de coordination associée aux routes supplémentaires. Attribuer un bloc initial plus petit tout en réservant un espace adjacent pouvait préserver l'agrégation, mais la réservation elle-même consommait une option sur un espace d'adressage rare.

La qualité des preuves variait également. Une limitation de fournisseur pouvait refléter une contrainte installée réelle, une version obsolète, une documentation incomplète ou une mauvaise compréhension. L'échange PIPEX montre la valeur de comparer la prémisse d'un demandeur avec plusieurs types d'expertise. Il met également en garde contre l'hypothèse qu'une capacité générale d'un produit résout les coûts d'un déploiement particulier.

Pendant ce temps, les technologies disponibles évoluaient. Les hypothèses d'adressage par classes, le CIDR, l'agrégation par fournisseur, l'espace d'adressage privé et les masques de sous-réseau de longueur variable ont modifié les conceptions de réseau possibles. Le mandat de quatorze jours de RIPE-095 en tant que formulaire le plus récent illustre la pression de maintenance autour d'un instrument procédural même relativement modeste.

La discrétion n'était donc pas simplement un résidu institutionnel en attente d'élimination. C'était une réponse aux prévisions, aux topologies et aux coûts externes qui ne correspondaient pas à un seul tableau. La question de gouvernance est de savoir si les responsables ont utilisé ce jugement dans le cadre de motifs publiés, documenté les écarts importants et exposé les décisions finales à un examen significatif.

Ce qu'un demandeur pouvait savoir en 1996

Tout au long de la période, la vision du processus par un demandeur est devenue nettement plus claire.

Des points de référence numériques publics sont apparus dans la RFC 1366 et se sont élargis dans la RFC 1466. Le demandeur pouvait voir les seuils conjonctifs de la classe B, le calendrier de classe C sur 24 mois et un exemple de topologie pouvant justifier un écart.

Les formulaires RIPE ont ensuite traduit ces principes en questions. Une organisation savait que les machines, les sous-réseaux, les avoirs existants, les plans de connexion, la configuration du réseau et la croissance future entreraient dans l'évaluation. Elle savait quelles informations deviendraient publiques et quel matériel technique resterait confidentiel. La distinction entre une demande directe et le passage par un registre local était décrite sur le formulaire.

La RFC 1400 a exposé un chemin de correction pour les soumissions traitées par machine. Le demandeur pouvait inspecter les informations analysées, corriger les erreurs, répondre à une erreur, soumettre à nouveau et utiliser un numéro de ticket pour vérifier l'état. L'avis de Terpstra a également rendu visible une partie du traitement des mises à jour d'assignation pour les registres locaux.

Les exceptions étaient également divulguées. La RFC 1366 permettait un traitement au cas par cas lorsque les blocs de classe C n'étaient pas pratiques. La RFC 1466 identifiait la topologie comme un motif reconnu et exigeait un plan d'ingénierie. La RFC 2050 continuait à reconnaître les exceptions tout en s'attendant à des VLSM et à une justification détaillée pour les demandes basées sur l'équipement.

En novembre 1996, le demandeur pouvait invoquer unDroit de recoursnommé, un transfert de documents vers un registre parent et une escalade possible vers l'IANA. Cette architecture textuelle était plus spécifique que de demander au même bureau de reconsidérer de manière informelle.

L'élément le moins visible était le pont probatoire final: quel fait contrôlait la quantité attribuée dans une transaction particulière. Les instruments publics produisaient rarement un récit de décision public qui reliait les entrées acceptées, les écarts et le résultat. Les plans d'ingénierie protégés limitaient davantage la comparaison entre les demandeurs. L'architecture de la révision est devenue connaissable avant que sa force de modification des résultats ne devienne mesurable dans le dossier trouvé.

L'audit de transaction encore nécessaire

Un test convaincant de la contrainte substantielle doit utiliser la transaction comme unité.

Chaque observation commencerait par la demande originale et la version exacte du formulaire et des directives en vigueur à la date de soumission. Elle enregistrerait la ressource et la quantité demandées, les hôtes actuels et projetés, le plan de sous-réseau, la topologie, les avoirs existants, la relation avec le fournisseur et les circonstances de routage.

Le côté administratif identifierait le registre responsable, l'examinateur, les demandes d'informations supplémentaires, les corrections, la prévision acceptée, le motif de chaque changement substantiel, la décision finale et toute exception invoquée. Lorsqu'une révision avait lieu, le dossier ajouterait les motifs de la contestation, les documents transférés, le réviseur, la décision et le recours.

Les cas proches d'un seuil publié seraient particulièrement informatifs. Des demandes comparables sous la même version pourraient montrer si les prévisions acceptées du même côté d'une frontière produisaient des résultats comparables. Les écarts de topologie documentés pourraient révéler si la discrétion suivait l'exception énoncée plutôt qu'une préférence non déclarée.

Un changement de version offre un autre test. Des demandes similaires avant et après le tableau d'octobre 1992, ou autour d'une révision documentée du formulaire, pourraient révéler si les résultats ont changé avec l'instrument. Les changements dans les conditions de routage, la responsabilité institutionnelle et la technologie disponible devraient être pris en compte plutôt que traités comme un bruit de fond.

La performance administrative devrait être mesurée séparément. Une étude du traitement de style RFC 1400 pourrait compter les réponses d'analyse, les vérifications corrigées, les expirations, les nouvelles soumissions et les abandons sans étiqueter chaque rejet automatique comme une demande d'adresse refusée. Cela testerait si le traitement de l'information est devenu plus régulier même si le jugement d'attribution restait largement discrétionnaire.

L'appel nécessite sa propre chaîne. Une observation valide relierait la décision initiale, les motifs, le dossier transféré, la révision du registre parent et la décision qui en résulte. Une décision confirmée démontrerait quand même une révision. Un recours ayant une force de modification du résultat nécessiterait une attribution modifiée, un renvoi ou un résultat substitué attribuable à l'appel. Une nouvelle demande avec de nouveaux faits appartient à une catégorie différente.

L'échantillonnage devrait commencer par les frontières des bureaux, les dates et les séries de documents plutôt que par une liste de détenteurs d'adresses réussis. Les registres d'attribution publics exposent de manière disproportionnée les assignations finalisées. Les dossiers restreints, manquants et détruits devraient être enregistrés selon une méthode déclarée. Le matériel confidentiel pourrait être analysé dans des conditions protégées tout en ne publiant que les variables nécessaires à l'évaluation de la décision.

Une telle étude pourrait estimer les réductions, les retards, les corrections, les exceptions, les appels et les recours. Elle pourrait également examiner les erreurs de prévision, les retours ultérieurs pour plus d'espace et les différences entre les registres. Les documents d'orientation et les quatre artefacts de pratique examinés ici sont suffisants pour concevoir cet audit, mais pas pour en calculer les résultats.

Procédure plus connaissable, contrainte finale encore non mesurée

Entre 1988 et 1996, l'administration des adresses a acquis une structure plus publique et intelligible. Les demandeurs ont obtenu des voies plus claires pour entrer dans le système, un préavis des preuves requises, des points de référence quantitatifs, des mécanismes de correction, des motifs énoncés de déviation, une protection pour les plans sensibles et finalement une voie de recours publiée. La RFC 1400 a imposé une réelle discipline dans le traitement administratif. Les RFC 1366 et 1466 ont rendu certains écarts substantiels reconnaissables. RIPE a maintenu et révisé ses formulaires. La RFC 1467 a enregistré un compte rendu institutionnel de la mise en œuvre administrative, et la RFC 2050 a décrit une hiérarchie mature avec des devoirs de transfert de documents et de révision.

Ces changements ont éloigné le système d'une dépendance à un échange entièrement non structuré avec un Hostmaster. Ils ont également aidé les registres à comparer les prévisions, la topologie et les avoirs existants à travers un réseau en expansion rapide. Le cas opérationnel pour conserver le jugement restait solide parce que la conservation des adresses, l'agrégation des routes, les coûts pour les demandeurs et la croissance incertaine pouvaient pointer dans des directions différentes.

Les preuves de transaction ouvertes ont une portée plus étroite. Elles consistent en une discussion partielle de demande et trois observations opérationnelles ou institutionnelles. La correspondance PIPEX montre un test par les pairs d'une affirmation logicielle mais s'arrête avant la décision. L'avis de Terpstra concerne les contrôles d'assignation et de mise à jour. L'exemple numérique de Karrenberg décrit une pratique conservatrice sans identifier le résultat d'un demandeur. RIPE-18 enregistre les rapports des entités et une réponse institutionnelle sans les demandes sous-jacentes.

Aucune chaîne complète identifiée dans l'ensemble examiné ne relie la demande originale, la version applicable, la correction, le motif contemporain, l'attribution finale, la révision et le recours. Par conséquent, la cohérence des décisions substantielles et les taux de succès ou de refus restent non mesurés. Les formulaires d'adresses antérieurs peuvent également réviser la chronologie des premiers critères écrits une fois qu'ils auront été recherchés directement.

Le résultat historique est donc limité mais conséquent. Les formulaires et les tableaux publics ont rendu les données des demandeurs, le traitement administratif et certains écarts plus connaissables. Ils ont créé les conditions de l'examen. Le registre public survivant n'a pas encore fourni l'échantillon de transactions nécessaire pour déterminer avec quelle cohérence ces critères ont gouverné le jugement final.