Le bureau d’appel manquant des débuts d’Internet

Résumé

• Les instructions publiées de 1983 à 1992 décrivaient les formulaires, les exigences techniques, les administrateurs responsables, les voies de correction et les canaux de contact. Dans l'échantillon documentaire examiné ici, elles n'établissaient pas de bureau d'appel général et indépendant pour une demande infructueuse de domaine ou d'identifiant numérique.
• Les listes d'utilisateurs enregistrés, de domaines et de numéros de réseau attribués conservent des enregistrements terminés ou actuels. Elles ne révèlent pas la population totale des demandes soumises, incomplètes, retardées, retirées, refusées, corrigées, reconsidérées, escaladées, annulées ou autrement clôturées.
• La correspondance du NIC, l'assistance téléphonique, l'administration du domaine parent, le parrainage gouvernemental, l'autorité de l'IANA et la supervision fédérale auraient pu aider à résoudre des problèmes particuliers. L'échantillon ne contient aucune preuve au niveau de la demande démontrant que l'une de ces voies a fonctionné comme un appel de demandeur avec un résultat motivé et enregistré.
• La carte des autorités est donc inégale: le personnel du NIC pouvait traiter et corriger les enregistrements; les administrateurs d'hôtes et de domaines pouvaient autoriser ou réviser les soumissions locales; les sponsors pouvaient affecter la connectivité; l'IAB pouvait recommander des politiques; et l'IANA détenait et déléguait l'autorité d'attribution numérique. La compétence d'appel individuelle et les devoirs d'annulation restent non établis.
• Un faible niveau de conflit enregistré est compatible avec des récits à la fois bienveillants et sceptiques. Les problèmes pouvaient généralement être résolus avec précision grâce à des relations de confiance, ou les demandeurs infructueux pouvaient avoir disparu de dossiers optimisés pour conserver les attributions plutôt que les historiques procéduraux. Le dénominateur disponible ne permet pas de distinguer les deux.

Le dénominateur caché derrière chaque liste de succès

Une table publiée de numéros de réseau est un enregistrement des arrivées. Elle montre les identifiants qui sont entrés dans le registre officiel et, occasionnellement, les entrées qui ont changé au cours d'une transition. Une table de domaines montre de même les noms qui ont terminé l'enregistrement. Aucune des deux tables n'enregistre chaque tentative qui a précédé le résultat.

C'est le problème du dénominateur. Une histoire institutionnelle de l'administration des débuts d'Internet doit compter les demandes plutôt que les attributions. La population pertinente inclurait les premières soumissions, les doublons, les formulaires techniquement défectueux, les demandes renvoyées pour plus d'informations, les retraits, les corrections, les retards, les refus substantiels, les demandes renouvelées, les interventions de sponsors, les reconsidérations, les escalades, les annulations et les cas qui se sont terminés sans disposition documentée. Un registre construit pour préserver des identifiants uniques ne fournit qu'un sous-ensemble de cette population.

La voie normale est beaucoup plus facile à reconstruire.

Comme référence de base immédiate pour la période précédente,RFC 810, datée du 1^ermars 1982, exigeait que les noms et adresses des réseaux, passerelles et hôtes du Department of Defense soient négociés et enregistrés auprès du Network Information Center avant utilisation et avant qu'un hôte du DoD ne transmette du trafic. Elle identifiait des voies de contact électroniques et téléphoniques. Pour une période intermédiaire, le NIC essaierait également de maintenir des informations comparables fournies par des réseaux et hôtes non-DoD. L'instruction établissait où l'enregistrement avait lieu. Elle ne décrivait pas un registre des demandes ni une voie pour contester une conclusion défavorable.

RFC 920, publiée en octobre 1984, spécifiait les exigences pour établir un domaine. Un domaine était une entité administrative, pas simplement une étiquette. Il nécessitait une personne responsable avec une compétence technique et une autorité organisationnelle, un service de nom fiable et un enregistrement via la hiérarchie appropriée. Un domaine de niveau inférieur devait satisfaire l'administrateur immédiatement supérieur. Le document comprenait un questionnaire pour le domaine proposé, les contacts, la disposition du serveur, la taille prévue et la structure administrative.

RFC 1032, le guide des administrateurs de domaines de novembre 1987, rendait la procédure de travail plus explicite. Un administrateur obtenait un questionnaire, le remplissait et l'envoyait au Hostmaster du NIC. Le personnel du Hostmaster examinait l'information pour s'assurer de sa complétude. Le guide s'attendait à plusieurs échanges de correspondance électronique avant l'autorisation. Des corrections pouvaient être soumises plus tard, et les demandeurs pouvaient poser des questions par courriel ou via une ligne d'assistance gratuite.

Ces documents prouvent qu'il y avait une procédure, un bureau administratif et un canal d'aide. Ils ne montrent pas combien de demandes se sont arrêtées à chaque étape. Un enregistrement de domaine final pouvait avoir suivi une première soumission complète, une clarification de routine, une correction technique répétée, une intervention d'un administrateur de domaine parent ou le remplacement d'une proposition antérieure. Une fois que le domaine apparaissait dans le registre, ces historiques convergeaient vers le même résultat visible.

Le même problème affecte les publications de numéros de réseau.RFC 1062, émise en août 1988, listait les numéros de réseau attribués et différenciait les utilisateurs de recherche, de défense, gouvernementaux non-défense et commerciaux. Elle marquait également certains numéros modifiés pour une utilisation transitoire. Ces informations documentent les attributions et la renumérotation. Elles n'identifient pas toutes les demandes, encore moins toutes les demandes infructueuses.

Un numéro vide dans la table n'est pas une preuve d'un demandeur refusé. Un numéro enregistré n'est pas une preuve que la demande originale était complète. Un marqueur de changement ne révèle pas si le changement a été demandé, imposé, contesté ou simplement technique. La table préserve l'état opérationnel, pas le chemin par lequel l'état a été atteint.

Un faible conflit visible peut donc soutenir deux récits. Le récit bienveillant est que les administrateurs et les demandeurs techniquement sophistiqués se comprenaient généralement, corrigeaient les erreurs par correspondance et produisaient rarement des différends sérieux. Le récit sceptique est qu'un système organisé autour des attributions actuelles avait peu de raisons opérationnelles de conserver les tentatives échouées, les explications non écrites ou les demandeurs déçus. Les deux récits prédisent une liste propre d'enregistrements réussis.

Les listes survivantes ne peuvent pas choisir entre eux.

Une machine d'états, pas un binaire approuvé-rejeté

La séquence analytique minimale est:

soumis -> incomplet -> demande d'informations complémentaires -> retardé -> refusé -> corrigé -> reconsidéré -> escaladé -> annulé ou définitif

Cette notation n'a pas pour but de laisser entendre que chaque demande passait par tous les états. Les parcours réels se seraient ramifiés. Une demande incomplète pouvait être corrigée et continuer. Une demande complète pouvait être retirée. Un refus pouvait devenir définitif sans reconsidération. Une escalade pouvait concerner le parrainage ou la connectivité plutôt que la décision sur l'identifiant. La valeur de la séquence est qu'elle empêche que différents événements procéduraux soient réduits au mot « rejeté ».

Soumissignifie qu'une autorité identifiable a reçu une demande. La preuve devrait inclure le formulaire, le message ou la lettre entrants, de préférence avec une date de réception et suffisamment de contexte pour déterminer quel service était demandé. Un enregistrement ultérieur prouve qu'un certain processus a réussi; il n'établit pas la date ou le contenu de la première soumission.

Incompletdécrit une condition de traitement. Des champs requis, des contacts responsables, des dispositions de serveur ou une autorisation pouvaient manquer. La RFC 1032 exigeait un questionnaire complété avant que le NIC n'autorise un domaine. Cette règle documente la catégorie, mais l'échantillon ne contient aucun dossier de demande lié montrant une demande nommée classée comme incomplète.

Demande d'informations complémentairesest un acte administratif affirmatif. L'attente de plusieurs échanges de correspondance dans la RFC 1032 démontre que la clarification faisait partie du traitement normal. Un cas particulier nécessiterait encore la question sortante, la demande à laquelle elle se rapporte et toute réponse. Une deuxième soumission seule ne peut pas révéler si la première a suscité une question.

Retardénécessite des dates et une demande continue non résolue. L'intervalle doit être divisé entre le temps de traitement du personnel, le temps de réponse du demandeur, l'examen du sponsor, la préparation technique et toute question de politique. Un domaine enregistré des mois après qu'un plan initial a été discuté n'est pas automatiquement une demande retardée. Sans un début documenté, des pauses et un événement terminal, le retard reste non prouvé.

Retirésignifie que le demandeur a mis fin à la demande. Cet état nécessite une déclaration ou un comportement qui peut être attribué de manière fiable au demandeur. Le silence est ambigu: le demandeur peut avoir abandonné le plan, changé d'intermédiaire, résolu le problème par téléphone ou n'avoir jamais reçu de réponse.

Refuséest une décision défavorable substantielle, pas l'absence d'attribution. Le dossier direct devrait identifier l'autorité décisionnelle, l'exigence applicable, la raison et la communication du résultat. Un modèle mal formé, une question sans réponse, une demande de connexion inéligible et un litige de domaine renvoyé aux parties locales sont des événements différents.

Corrigésignifie que les données, la configuration demandée ou les informations de soutien ont changé. La correction ne doit pas nécessairement impliquer un désaccord. Elle peut être un contrôle de qualité ordinaire. Les documents de l'époque établissent directement les procédures de correction, bien qu'ils ne convertissent pas ces procédures en appels.

Reconsidérésignifie que le fonctionnaire ou l'unité administrative d'origine a revisité une conclusion déjà atteinte. La poursuite du traitement après que le demandeur a fourni des données manquantes peut sembler similaire, mais ce n'est pas nécessairement une reconsidération d'une décision défavorable. Un dossier de cas doit montrer la position antérieure et le réexamen ultérieur.

Escaladésignifie qu'un problème a été déplacé vers une autre autorité ou un autre niveau institutionnel. Un Hostmaster pouvait demander à un collègue senior; un demandeur pouvait s'adresser à un sponsor; le personnel du programme DDN pouvait s'impliquer; ou une question de politique pouvait atteindre l'IANA ou un organisme fédéral de réseau. Le simple fait de copier un fonctionnaire senior sur la correspondance ne prouve pas une escalade, et une escalade ne prouve pas un examen.

Annulénécessite deux décisions incompatibles: un résultat antérieur identifiable et un résultat ultérieur qui l'a modifié. Une orthographe corrigée, une nouvelle adresse de serveur, une renumérotation ou une demande révisée n'est pas une annulation à moins que le dossier n'établisse également la décision qui a été renversée.

Définitifest l'étiquette la plus dangereuse. Une procédure publiée peut déclarer une décision définitive, ou un dossier de cas complet peut montrer que l'examen disponible est terminé. Le dernier message survivant ne prouve pas la finalité. Il peut être le dernier élément conservé plutôt que le dernier événement survenu.

Le statut des preuves dans cet échantillon est par conséquent asymétrique:

Ce tableau n'estime pas la fréquence. Il enregistre la position probante de chaque état dans un échantillon de procédures publiées. Aucun refus, retard, escalade, annulation ou disposition définitive n'est fourni comme cas historique car les dossiers directs nécessaires n'ont pas été établis.

L'échantillon documentaire et ce qu'il exclut

La période d'intérêt est 1983-1992. La RFC 810 est utilisée uniquement comme référence de mars 1982 pour la règle héritée d'enregistrement d'hôte. La RFC 1400, publiée en 1993, n'apparaît que comme une brève comparaison montrant comment la visibilité explicite de l'état de la demande est entrée plus tard dans une procédure publique.

L'échantillon est unéchantillon de procédures publiées et d'autorité institutionnelle, pas un corpus de demandes individuelles. Son unité est un document ou un artefact documentaire public. Il se compose de:

• RFC 920, RFC 1032, RFC 1062, RFC 1174 et RFC 1359;
• le document du NIC du 20 octobre 1983 « Instructions for Network User Registration Drive », conservé aux pages 67-73 du lot numérisé de la Computer History Museum,Defense Communication Agency Materials; 6 of 13;
• « How to Reach the NIC »,NIC KNACKS, numéro 2, daté du 17 mai 1985, conservé à la page 94 du lot numérisé deDefense Communications Agency Materials; 3 of 13;
• le guide 2011 de la Computer History Museum,Guide to the SRI ARC/NIC Records, collection X3578.2006;
• l'entretien de James Pelkey avec Jon Postel, enregistré le 18 février 1988;
• et l'histoire juridique ultérieure du Government Accountability Office des États-Unis concernant les contrats fédéraux relatifs au DNS et aux fonctions IANA.

Les documents ont été inclus lorsqu'ils décrivaient une exigence de demande, un canal administratif, un processus de correction, une autorité d'attribution, une distinction de parrainage, une recommandation politique ou une relation de supervision pertinente pour 1983-1992. La RFC 1062 est incluse en tant qu'artefact de résultat publié plutôt que comme manuel de demande. L'instrument de recherche est utilisé pour définir le paysage archivistique, pas comme substitut aux dossiers à l'intérieur de la collection. L'entretien avec Postel fournit un contexte limité sur la culture documentaire, pas de preuves de cas d'identifiant. L'avis du GAO est une histoire juridique ultérieure et est confiné aux chaînes de contrats qu'il a réellement examinées.

Plusieurs corpus de preuves sont en dehors de cet échantillon. Il ne s'agit pas d'un examen boîte par boîte de la collection SRI ARC/NIC de 281 boîtes. Il ne prétend pas avoir examiné chaque demande de domaine, mise à jour de table d'hôte, demande de numéro, journal de hotline, rapport mensuel, lettre de sponsor ou message interne. Il ne traite pas les descriptions de l'instrument de recherche comme preuve du résultat d'une demande quelconque. Il ne contient pas de dossiers de demande statistiquement échantillonnés.

L'échantillon exclut également l'inférence à partir des données de registre actuelles. Un enregistrement WHOIS ultérieur ou une délégation survivante ne peut pas reconstruire une demande précoce sans correspondance contemporaine. Les souvenirs oraux ne sont pas comptés comme une demande à moins d'être mis en correspondance avec des dossiers directs. Les lignes d'attribution sont des résultats, pas des unités de demande.

L'instrument de rechercheSRI ARC/NICdécrit 351 pieds linéaires dans 281 boîtes, la majeure partie du matériel datant de 1968-1990. Les séries pertinentes comprennent les propositions et contrats du NIC, les rapports mensuels formels, les livrables contractuels, les opérations de référence et de hotline, la dénomination et l'adressage, l'enregistrement d'accès utilisateur TAC, l'administration des contacts réseau et divers courriels et correspondances.

Le guide dit que la collection contient un ensemble complet de rapports mensuels formels du NIC. Il ne dit pas que ces rapports contiennent un dénominateur de demande unique. Les totaux mensuels pour les appels, les messages, les mises à jour ou les enregistrements devraient encore être liés aux demandes individuelles. Dix messages pourraient représenter dix demandeurs ou dix échanges concernant un demandeur. Un appel à la hotline pourrait concerner l'accès à un document, un problème de connexion, une mise à jour d'hôte ou une demande d'identifiant. L'activité agrégée n'est pas une série de dispositions.

Le guide cartographie également une correspondance diverse jusqu'en 1989. Parce que la correspondance a été recueillie à partir de différents endroits et couvre de nombreux sujets, son existence ne peut pas établir la complétude. Une demande pourrait être séparée de sa réponse. Les conversations téléphoniques pourraient n'avoir aucune note survivante. Les dossiers pourraient être organisés par employé, date ou service plutôt que par demandeur. Un examen des archives physiques pourrait récupérer des cas exceptionnels, mais cet article ne fait aucune revendication d'incidence avant que ce travail ne soit fait.

Une étude valide au niveau de la demande nécessiterait une règle d'inclusion explicite: par exemple, toutes les demandes de domaine de deuxième niveau reçues pour la première fois pendant un trimestre fixe, qu'elles aient réussi ou non. La demande unique, plutôt que le message, serait l'unité de comptage. Les doublons, les propositions renommées, les soumissions multiples, les cas transférés et les demandes via des registres intermédiaires nécessiteraient un traitement prédéfini. Chaque état nécessiterait une date et un critère documentaire. Les messages manquants et les contacts téléphoniques nécessiteraient un code de conservation. Rien dans l'échantillon actuel ne soutient de tels comptes.

Le dénominateur est donc indéfini. Il n'y a pas de taux d'approbation, de taux de refus, de taux d'annulation ou de délai moyen rapporté. Il n'y a pas non plus de numérateur pour les appels individuels. Cette limite est méthodologique plutôt que rhétorique: aucune quantité de certitude dans la prose ne peut fabriquer des dossiers de demande qui n'ont pas été examinés.

Trois populations administratives qui ne doivent pas être fusionnées

Les documents survivants décrivent des services liés mais distincts. Les combiner créerait un système d'appel commun imaginaire.

La première population estl'enregistrement des utilisateurs du réseau et l'accès TAC. Les « Instructions for Network User Registration Drive » du NIC, datées du 20 octobre 1983, concernaient les individus utilisant les hôtes MILNET et ARPANET et, pour un sous-ensemble, l'accès via les contrôleurs d'accès terminal MILNET. Les administrateurs d'hôtes ont reçu des modèles pour les utilisateurs associés à leurs hôtes, ont corrigé les données existantes, ajouté des utilisateurs éligibles, marqué les suppressions, examiné les résultats et retourné le matériel au NIC. Les demandes d'accès TAC exigeaient une autorisation via la boîte aux lettres de l'administrateur d'hôte.

C'était un système d'autorisation du côté du sponsor et de l'hôte. Le Bureau de gestion du programme DDN a déclaré que les hôtes locaux devaient se gérer eux-mêmes de manière responsable dans le cadre des directives gouvernementales et qu'il travaillerait avec les administrateurs d'hôtes si des problèmes survenaient. Ce langage établit un canal de problème entre le DDN-PMO et les administrateurs. Il n'établit pas un droit appartenant à un individu dont l'administrateur d'hôte a refusé l'autorisation.

La deuxième population estl'enregistrement de domaine. La RFC 920 et la RFC 1032 attribuaient des responsabilités entre le demandeur, l'administrateur de domaine responsable, l'autorité immédiatement supérieure et le NIC. La préparation technique, les serveurs fiables, les contacts compétents, la classification organisationnelle et la responsabilité administrative importaient. Le NIC pouvait vérifier la complétude et répondre aux questions techniques. Les autorités de domaine parent exerçaient un jugement hiérarchique sur l'admission.

La RFC 1032 a tracé une frontière juridictionnelle significative. Elle disait que le NIC n'agirait pas comme arbitre dans les litiges sur qui avait le droit d'enregistrer un domaine de premier ou deuxième niveau particulier pour une organisation. Ces conflits étaient traités comme des questions locales privées à régler avant le début de l'enregistrement. Le personnel du NIC pouvait fournir des conseils techniques, mais pas d'arbitrage.

Cette frontière n'est pas une preuve qu'aucun remède n'existait. Elle situait le litige ailleurs: à l'intérieur d'une organisation, dans la hiérarchie du domaine parent, via des relations contractuelles, ou potentiellement via un forum juridique avec une compétence indépendante. Pourtant, la RFC 1032 n'a pas désigné de tribunal de remplacement ni dit qui décidait si un désaccord avait été véritablement résolu.

La troisième population estl'attribution d'identifiants numériques. La RFC 1062 publiait les numéros de réseau attribués.RFC 1174, émise en août 1990, décrivait l'IANA comme l'organisation ayant l'autorité principale pour allouer et attribuer les identifiants numériques, cette fonction étant exécutée par l'Information Sciences Institute de l'USC. Elle décrivait le registre Internet au SRI comme rassemblant et enregistrant des informations sur les réseaux et effectuant des travaux d'attribution délégués.

L'attribution numérique doit également être séparée de laconnectivité. La RFC 1062 indiquait que les réseaux indépendants utilisant des protocoles Internet pouvaient recevoir des numéros tout en restant en dehors de l'Internet connecté, et qu'ils devaient demander séparément l'autorisation de s'interconnecter. La RFC 1174 décrivait plus tard le statut « connecté » comme une sanction d'une organisation de parrainage du gouvernement américain pour se lier au système fédéralement sponsorisé.

Une organisation pouvait donc obtenir un numéro unique tout en manquant la connexion qu'elle souhaitait. Le refus d'un sponsor de sanctionner l'interconnexion n'était pas nécessairement un refus du registre Internet d'attribuer un numéro. Les examinateurs possibles différaient également. L'IANA et le registre Internet occupaient la chaîne d'attribution numérique; une agence de parrainage ou un opérateur backbone occupait la chaîne de connectivité.

RFC 1359, publiée en août 1992, ajoutait une autre couche institutionnelle pour les campus. Elle conseillait aux organisations de travailler avec un fournisseur de services IP et décrivait ce fournisseur comme une source de conseils sur les classes d'adresses et la procédure de demande. Un fournisseur pouvait empêcher une soumission incomplète en aidant un demandeur à la préparer. Le document ne montre pas le fournisseur faisant appel d'une décision du registre.

L'enregistrement des utilisateurs, l'accès TAC, l'admission de domaine, l'attribution numérique et la connexion au réseau avaient donc des demandeurs, des règles, des autorités et des remèdes possibles différents. Une correction documentée dans une population ne peut pas prouver un examen dans une autre.

L'enregistrement direct des exceptions: correction et traitement continu

La preuve d'exception la plus forte dans l'échantillon concerne la correction.

Les « Instructions for Network User Registration Drive » du 20 octobre 1983 énonçaient une séquence concrète. Le NIC préparait des modèles pour les personnes déjà dans sa base de données d'identification. Les administrateurs d'hôtes récupéraient ces modèles, remplaçaient les données incorrectes, ajoutaient les utilisateurs manquants, marquaient les suppressions, examinaient et autorisaient les listes résultantes, et les retournaient au registraire. Le NIC modifiait les soumissions et les entrait dans la base de données d'identification WHOIS.

Le document était strict sur le format. Les données devaient être retournées dans le modèle spécifié afin de pouvoir être traitées avec moins d'édition manuelle. Le matériel sous une autre forme ne serait pas accepté. C'est une condition de non-acceptation directement documentée, mais elle s'applique à la forme des données d'enregistrement d'utilisateur. Ce n'est pas un refus substantiel d'une demande d'adresse IP ou de domaine.

Les instructions géraient également les doublons. Si plus d'un administrateur d'hôte soumettait un modèle pour la même personne, le NIC disait qu'il était prêt à résoudre la duplication. Là encore, l'action est un contrôle de qualité administratif. La source ne décrit pas une audience entre sponsors concurrents ou un appel de demandeur.

L'accès TAC ajoutait une couche d'autorisation distincte. Le NIC traitait une demande comme autorisée lorsque le modèle pertinent arrivait de la boîte aux lettres de l'administrateur d'hôte responsable. Ce mécanisme utilisait la relation institutionnelle et l'environnement en ligne comme méthode d'authentification pratique. Il évitait le délai d'obtention d'un formulaire papier signé. Il ne disait pas à un utilisateur comment contester l'administrateur d'hôte.

La séquence documentée est donc:

données existantes -> examen de l'administrateur -> correction ou ajout -> autorisation -> soumission structurée -> traitement par le NIC

Chaque flèche a une fonction administrative déclarée. Aucune n'est un examen indépendant d'un refus substantiel antérieur.

Les demandes de domaine avaient un chemin similairement itératif mais différemment gouverné. La RFC 1032 exigeait des informations complètes et anticipait plusieurs échanges de correspondance avant l'autorisation. Une question du Hostmaster maintenait la demande en traitement. La réponse d'un demandeur pouvait corriger un défaut technique ou administratif. Des mises à jour ultérieures pouvaient maintenir les informations enregistrées à jour.

Le guide ne définissait pas le moment où le traitement continu infructueux devenait un refus. Il n'exigeait pas de lettre de clôture après que le demandeur n'avait pas satisfait le Hostmaster. Il ne fournissait aucune fenêtre de reconsidération et aucun examinateur séparé. Ces omissions ne prouvent pas que le personnel n'a jamais expliqué ou revisité une conclusion. Elles signifient que la procédure publiée ne permet pas à un historien de classer un résultat individuel sans la correspondance.

La RFC 1062 fournit un troisième type de correction: les numéros de réseau modifiés. Les anciens numéros pouvaient rester visibles temporairement avec des marqueurs de transition. La publication démontre que l'état du registre a été révisé tout en préservant les informations de continuité. Elle n'identifie pas la raison, le demandeur, le décideur ou le degré de désaccord derrière un changement.

Ces enregistrements soutiennent trois constatations étroites. L'administration précoce reconnaissait que les données pouvaient être erronées. Elle fournissait des mécanismes pour que des informations corrigées remplacent ou complètent les enregistrements existants. Elle préservait parfois les résultats transitoires après un changement de numéro.

Ils ne fournissent pas de demandeur refusé, d'appel ou d'annulation.

La carte des annulations

Une enquête sur les appels devient plus claire lorsque chaque acteur se voit attribuer uniquement le verbe soutenu par le dossier. Certains acteurs pouvaient recevoir ou corriger des informations. Certains pouvaient autoriser une soumission locale. Certains pouvaient recommander une politique. Détenir l'autorité sur une fonction d'identifiant ne créait pas automatiquement une compétence d'appel.

Cette carte contient de nombreuses façons de demander et moins de façons de contraindre. Le personnel du NIC pouvait corriger un enregistrement qu'il maintenait. Un administrateur d'hôte pouvait autoriser un utilisateur. Un administrateur de domaine parent pouvait réviser un jugement local. Un sponsor pouvait changer la décision de parrainage qui affectait la connexion. Un client gouvernemental pouvait aborder la performance du contractant. L'IAB pouvait recommander un changement de politique.

Aucune de ces capacités, sur la base des preuves ici, ne créait un droit général du demandeur à ce qu'une personne distincte examine une demande d'enregistrement infructueuse et rende une décision finale enregistrée.

Personnel du NIC: autorité de traitement sans deuxième instance publiée

Le personnel du NIC et du Hostmaster occupait le premier point de décision visible pour plusieurs services. Leurs fonctions comprenaient la réception des formulaires, la vérification des informations requises, la réponse aux questions, la maintenance des bases de données et l'installation des corrections. Dans l'administration des domaines, ils agissaient au sein d'une hiérarchie dans laquelle le NIC pouvait être registraire ou agent tandis que les autorités de domaine supérieures conservaient la responsabilité substantielle.

Les instructions publiques soutiennent une discrétion considérable du personnel dans le traitement. La complétude est rarement un concept purement mécanique. Un questionnaire pouvait contenir tous les champs tout en ne parvenant pas à démontrer un fonctionnement fiable du serveur ou une autorité organisationnelle. Le personnel pouvait décider que plus d'explications étaient nécessaires. Les directives publiées ne montrent pas si les cas difficiles étaient attribués à un Hostmaster senior, discutés collectivement ou renvoyés vers le haut.

Une reconsidération par le même personnel pouvait être efficace. Si un demandeur fournissait de meilleures preuves et que le Hostmaster changeait de position, le problème pratique était résolu. La classification historique dépend toujours du dossier antérieur. Sans une conclusion défavorable déclarée, la séquence est un traitement continu. Sans la justification ultérieure, il est impossible de savoir ce qui a changé le résultat.

Le numéro du 17 mai 1985 deNIC KNACKS, intitulé « How to Reach the NIC », affichait des canaux différenciés pour l'assistance aux utilisateurs, les opérations informatiques, les mises à jour WHOIS et l'enregistrement des utilisateurs, les changements d'hôtes, le matériel de newsletter et les questions contractuelles ou de gestion. Il décrivait également une hotline soutenue par le personnel de référence et d'opérations. C'est une preuve de routage de service. Une personne qui pensait qu'un dossier était incorrect avait un endroit pour envoyer la correction; quelqu'un avec un problème d'hôte pouvait atteindre la fonction Hostmaster; une préoccupation plus large pouvait être adressée à la direction.

Une boîte aux lettres de direction est un canal de plainte, pas automatiquement un bureau d'appel. La source ne dit pas que la direction devait rouvrir une décision d'enregistrement, appliquer une norme de preuve distincte, donner des raisons ou préserver le résultat. Le canal peut avoir produit une excellente révision informelle. Sa performance reste non mesurée.

Postel, l'IANA et l'autorité numérique déléguée

La RFC 1174 fournit la déclaration la plus claire de l'époque sur l'autorité numérique. Elle décrivait l'IANA comme détenant l'autorité principale pour les identifiants numériques nécessaires au fonctionnement de l'Internet, la fonction étant exécutée à l'Information Sciences Institute de l'USC. Elle décrivait le registre Internet au SRI comme maintenant les informations d'enregistrement et effectuant le travail d'attribution sous responsabilité déléguée.

La délégation crée une relation verticale, mais ses conséquences réparatrices exactes dépendent des termes et de la pratique de la délégation. L'IANA pouvait définir la portée du travail délégué, coordonner la politique d'allocation et répondre aux questions sur qui détenait l'autorité d'attribution. Ces capacités n'établissent pas qu'un demandeur pouvait faire appel d'une décision du registre SRI à Jon Postel personnellement.

Aucune instruction examinée ne dit: déposez un recours auprès de l'IANA, soumettez-le dans un délai spécifié et recevez une décision sur le fond. Aucun cas de demandeur dans l'échantillon ne montre Postel recevant le refus d'un demandeur, examinant le dossier original et ordonnant une attribution différente. Il serait tout aussi dangereux de déduire le contraire. La position de Postel et la petite communauté professionnelle rendaient possibles des consultations informelles, mais la possibilité n'est pas une procédure enregistrée.

L'entretien de James Pelkey avec Postel du18 février 1988fournit un contexte sur la préservation de la délibération technique. Postel a discuté du fait que les discussions complètes entourant les idées techniques qui étaient débattues mais non adoptées n'étaient pas toujours capturées dans la documentation publiée. Cette observation concerne les idées techniques et l'histoire des RFC. Elle ne peut pas être transférée comme preuve que les refus d'identifiants, les appels ou les annulations ont été traités de la même manière.

L'entretien est donc un avertissement sur la culture documentaire, pas une source de résultats de demande. Il renforce le besoin de correspondance avant de reconstruire un cas exceptionnel, tout en ne prouvant rien sur la fréquence ou l'équité de tels cas.

L'IAB et les organes fédéraux de réseau: les recommandations ne sont pas des jugements

La RFC 1174 était adressée du président de l'Internet Activities Board au président du Federal Networking Council. Elle contenait des recommandations sur la distribution de l'attribution des identifiants et le changement de l'ancienne politique de statut connecté.

Le mémo recommandait de conserver les fonctions centralisées de l'IANA et du registre Internet tout en déléguant des blocs de numéros de réseau et de systèmes autonomes à des organisations approuvées. Il recommandait également de séparer l'enregistrement des identifiants de la restriction de statut connecté. Le registre Internet recueillerait des informations politiques, et l'inclusion dans le DNS ne serait plus liée à la même approbation de connexion fédérale.

C'est une preuve authentique de reconsidération institutionnelle au niveau politique. Elle montre l'IAB reconnaissant qu'un arrangement administratif conçu pour un environnement militaire, gouvernemental et de recherche sponsorisée ne convenait plus à un Internet commercial et international en pleine croissance. Elle montre également l'IAB transmettant une réponse proposée au FNC.

Les verbes comptent. L'IAB arecommandé. Le FNC areçula recommandation. Le document proposait que le registre Internetdevrait être chargéd'apporter des modifications. La RFC 1174 seule n'établit pas la date d'adoption par le FNC, la directive de mise en œuvre ou l'achèvement de chaque changement proposé.

Plus important encore, le mémo n'a pas jugé un cas de demandeur. Il n'a pas examiné la raison d'un Hostmaster, restauré un identifiant ou ordonné la reconsidération d'un refus antérieur. La réforme politique peut répondre à des problèmes accumulés sans préserver les noms ou les dossiers des personnes touchées. Elle peut opérer de manière prospective tout en laissant les résultats antérieurs intacts.

Cette distinction empêche une erreur analytique courante. L'existence d'un organe capable de recommander une politique système ne prouve pas que le même organe a entendu des appels individuels. Inversement, l'absence d'un dossier de demandeur dans une RFC ne prouve pas que les fonctionnaires fédéraux n'ont jamais intervenu informellement. La recommandation établit une voix institutionnelle, pas une compétence sur les cas.

DCA, sponsors et la différence entre enregistrement et connexion

Les instructions d'enregistrement des utilisateurs de 1983 placent le DDN-PMO derrière la campagne d'enregistrement. Les administrateurs d'hôtes étaient responsables des utilisateurs autorisés, et le DDN-PMO a dit qu'il travaillerait avec eux si des problèmes survenaient. C'était une déclaration directe de résolution de problèmes, mais la relation passait par les administrateurs.

Un individu en désaccord avec un administrateur d'hôte occupait une position difficile. Le DDN-PMO pouvait clarifier les directives applicables ou aborder un problème systémique. Le document ne promettait pas que l'individu pouvait contourner l'administrateur et obtenir un examen indépendant. L'autorisateur était aussi le représentant institutionnel local.

Le parrainage gouvernemental importait différemment pour la connectivité. L'historique du statut connecté dans la RFC 1174 décrit une sanction par une organisation de parrainage du gouvernement américain. Un sponsor pouvait confirmer qu'un réseau était qualifié pour la connexion, retirer son soutien ou clarifier la portée d'une activité financée. Une telle action pouvait déterminer l'accès pratique même si le registre Internet avait déjà attribué un numéro.

L'escalade de sponsor nécessite donc un étiquetage précis. Demander à un sponsor de confirmer l'éligibilité n'est pas un appel d'une attribution numérique. Persuader un sponsor de changer sa propre décision est une reconsidération dans la chaîne de parrainage. Demander au sponsor de contacter le registre peut être un plaidoyer institutionnel. Seul un dossier de cas direct peut établir ce qui s'est produit.

La même précision s'applique aux contractants fédéraux et aux universités. Un contractant pouvait soulever un problème de réseau comme obstacle au travail gouvernemental. Un chercheur universitaire pouvait demander de l'aide à un agent de programme. Un hôte militaire avait des administrateurs et des relations de gestion de programme. Ces structures créaient des voies possibles pour l'enquête. L'échantillon ne contient aucune donnée comparative de demande montrant à quelle fréquence elles ont changé les résultats.

Deux chaînes de contrats, aucune n'est un remède automatique pour le demandeur

Le financement fédéral crée une supervision, mais il ne crée pas en soi un droit d'appel.

La première chaîne pertinente estDCA-SRI/NIC. L'instrument de recherche SRI ARC/NIC identifie le travail du NIC financé par la DCA, les propositions de contrat, les livrables, les rapports mensuels et les examens en cours. Les matériels de la DCA de 1987 incluent une réunion d'examen de contrat et décrivent les tâches du NIC et les canaux de service. Ces enregistrements établissent que le client gouvernemental surveillait l'activité du contractant.

Cet article n'a pas examiné les clauses contractuelles opérationnelles du SRI régissant chaque service d'enregistrement. Il ne prétend donc pas que ces contrats imposaient un délai de demande, un devoir de conservation des dossiers, un processus de plainte du demandeur ou un pouvoir de l'agent contractuel d'annuler un jugement d'enregistrement particulier. La supervision gouvernementale des livrables et de la performance des services peut avoir été substantielle sans conférer des droits exécutoires à un demandeur.

La deuxième chaîne estDARPA-USC/ISI/IANA. La décisionGAO B-327398, émise bien plus tard, a rapporté que le GAO n'a pas pu obtenir de copies des contrats DARPA des années 1970-1990 dans le cadre desquels les fonctions IANA ont été développées et exécutées, bien qu'il ait récupéré des informations sur une tâche contractuelle ultérieure commençant en 1995. Cette constatation limite les conclusions sur les premiers termes DARPA-USC.

Elle n'établit pas que le dossier séparé du contrat DCA-SRI est manquant. Les deux contractants, les relations gouvernementales et les fonctions doivent rester distincts. La collection SRI cartographie des matériaux contractuels qui peuvent répondre à des questions sur la performance du NIC. Le manque de preuves du GAO concerne les contrats historiques DARPA-USC/IANA.

Un agent contractuel pouvait faire respecter les obligations qu'un contrat applicable contenait réellement. Ce pouvoir protégerait ordinairement l'intérêt contractuel du gouvernement. Un demandeur aurait encore besoin d'une voie par laquelle un problème d'enregistrement deviendrait un problème de performance contractuelle. Sans la clause, la plainte, l'action gouvernementale et le résultat, « l'examen de l'agent contractuel » reste un mécanisme de contrôle possible plutôt qu'un remède documenté.

Six choses différentes ultérieurement décrites comme un appel

Les histoires institutionnelles utilisent souvent « appel » pour tout événement où un problème initial est suivi d'un meilleur résultat. Ce vocabulaire obscurcit qui a agi et ce qui a changé.

Correctionrépare les données ou le formulaire. Les instructions d'enregistrement des utilisateurs de 1983 documentaient directement la correction, l'ajout, la suppression, le filtrage des doublons et la resoumission. La RFC 1032 documentait les mises à jour des données de domaine et la correspondance itérative. La correction peut se produire sans décision contestée.

Reconsidération informellese produit lorsque le membre du personnel ou le bureau d'origine revisite un point de vue antérieur. Une explication téléphonique, de nouvelles preuves techniques ou une clarification de l'autorité organisationnelle pouvait inciter à la reconsidération. L'infrastructure de contact dense de l'époque rend cela plausible, mais l'échantillon ne contient aucun cas complet de demandeur le démontrant.

Escalade de sponsordéplace le problème vers une organisation qui fournit l'autorisation, le financement ou la sanction de connexion. Le sponsor peut clarifier l'éligibilité, plaider auprès d'une autre institution ou changer sa propre position. Le résultat peut affecter l'accès sans annuler la décision du registre.

Plaintesignale un échec de service, un retard, une incohérence ou une conduite du personnel. La fiche de contact de 1985 séparait les problèmes de gestion des canaux de service de routine, montrant qu'une préoccupation plus large avait un endroit où aller. Elle ne disait pas qu'une plainte rouvrait une demande d'identifiant.

Appel publiéest un chemin basé sur des règles par lequel une partie affectée peut contester une décision devant un examinateur nommé. Il identifie normalement la décision qui peut être contestée, où la contestation va et qui émet la réponse. L'échantillon de procédures examiné ici n'identifie pas d'appel publié général de ce type pour les demandes infructueuses de domaine et d'identifiant numérique de 1983-1992.

Remède exécutoireprovient d'une autorité capable de contraindre à une action en vertu de la loi, d'un contrat ou de règles de programme contraignantes. Un tribunal, une agence ou un fonctionnaire contractant pouvait fournir un tel remède lorsque la compétence, un intérêt juridique et une obligation applicable existaient. Les manuels d'enregistrement ne le promettaient pas, et l'échantillon ne contient aucun jugement qualifié ou ordre d'agence annulant un résultat d'identifiant du NIC ou de l'IANA pendant la période.

Ces catégories peuvent se chevaucher dans une séquence factuelle. Un demandeur pouvait corriger un formulaire, demander au personnel du Hostmaster de reconsidérer, impliquer un sponsor, se plaindre à la direction et finalement poursuivre une revendication juridique externe. Les étiquettes devraient suivre les preuves à chaque étape plutôt que de traiter la séquence entière comme « un appel ».

Le téléphone comme remède pratique et point aveugle archivistique

L'alternative bienveillante la plus forte commence par l'accessibilité du NIC.

Le NIC publiait des canaux électroniques et exploitait une assistance téléphonique. La RFC 1032 anticipait une correspondance avant l'autorisation du domaine. La fiche « How to Reach the NIC » de 1985 dirigeait différents sujets vers différents rôles, y compris l'assistance, l'enregistrement, les changements d'hôte, les opérations et la gestion. L'instrument de recherche décrit une opération de référence et de hotline qui répondait aux requêtes téléphoniques et par courriel et rapportait des statistiques d'activité dans des rapports mensuels.

Une petite communauté techniquement connectée peut avoir résolu de nombreux problèmes de manière conversationnelle. Un demandeur pouvait appeler, apprendre qu'un serveur n'était pas prêt, corriger la configuration et soumettre à nouveau. Un administrateur d'hôte pouvait clarifier l'autorisation. Un fournisseur de services pouvait expliquer les exigences de classe d'adresse. Un sponsor pouvait confirmer qu'un réseau relevait d'une activité financée.

Du point de vue du entité, un tel appel pouvait être plus utile qu'une procédure formelle. La rapidité, le contexte et la confiance peuvent rendre l'administration informelle très efficace.

Du point de vue de l'historien, le même appel est une transition manquante. Le formulaire entrant peut survivre. L'attribution finale peut survivre. L'explication qui les reliait peut ne pas survivre. Si aucune note de cas n'a été faite, un chercheur ne peut pas déterminer si le résultat a suivi un conseil de routine, une reconsidération, un parrainage ou une nouvelle demande.

Les enregistrements téléphoniques, lorsqu'ils survivent, nécessitent une interprétation prudente. Un journal d'appels peut identifier la date, le sujet général, la classe de l'appelant et si un suivi était nécessaire. Il peut encore omettre la demande, le conseil, l'autorité et le résultat final. Les comptes d'appels ne peuvent pas devenir des comptes d'appels sans liaison de cas.

Le courriel offre plus de détails mais aucune garantie de complétude. Les messages peuvent être classés séparément de la demande. Les entités peuvent passer au téléphone. Une réponse peut survivre sans la question ou vice versa. Un fil de discussion peut documenter la négociation tout en laissant la décision finale non déclarée.

Ce problème de conservation coupe dans les deux sens. Il bloque une affirmation selon laquelle la révision n'a jamais eu lieu. Il bloque également une affirmation selon laquelle la révision informelle a fonctionné de manière cohérente. L'infrastructure de contact est observable; la qualité de la résolution ne l'est pas.

Qui avait accès à une reconsidération pratique?

La carte institutionnelle suggère une question distributionnelle, pas une constatation distributionnelle.

Un réseau militaire pouvait avoir un administrateur d'hôte, un agent de liaison, une relation de gestion de programme et un sponsor gouvernemental. Un contractant fédéral pouvait soulever un problème de réseau non résolu par l'intermédiaire d'un représentant technique ou d'une chaîne contractuelle. Une université financée pouvait compter sur les administrateurs du campus, un sponsor de recherche et, d'ici 1992, un réseau de niveau intermédiaire ou un fournisseur de services.

Un demandeur commercial ou international pouvait également avoir des intermédiaires experts et des relations professionnelles directes. La RFC 1174 reconnaissait explicitement que l'Internet s'était étendu au-delà de sa population originale fédérale et de recherche sponsorisée. Certains réseaux internationaux étaient profondément intégrés dans des collaborations de recherche. La catégorie institutionnelle seule ne peut pas déterminer l'accès.

L'hypothèse est que la reconsidération pratique pouvait dépendre en partie de relations: connaître le bon administrateur, avoir un sponsor capable de poser des questions ou travailler par l'intermédiaire d'un fournisseur familier avec la procédure du registre. Cette hypothèse est plausible parce que les canaux documentés étaient basés sur les rôles et hiérarchiques.

Elle n'est pas testée. L'échantillon ne contient aucun dénominateur de demande réparti entre les demandeurs militaires, gouvernementaux, universitaires, commerciaux et internationaux. Il n'y a pas de mesures comparables de la complétude, du temps écoulé, des questions posées, de l'implication du sponsor ou du résultat final.

Les intermédiaires de confiance peuvent avoir réduit les inégalités en aidant les demandeurs moins expérimentés à soumettre des demandes précises. Ils peuvent également avoir rendu le recours relationnel, bénéficiant aux institutions déjà connectées au réseau administratif. Les deux effets pouvaient opérer simultanément.

Une comparaison défendable nécessiterait des données au niveau de la demande et des contrôles pour la préparation technique, la ressource demandée, les exigences de parrainage et la complétude de la demande. Sans ces preuves, ni le traitement égal ni le traitement inégal ne devraient être rapportés comme un résultat.

Les tribunaux et les agences en dehors de la hiérarchie technique

Un tribunal n'est pas un bureau d'appel pour chaque inconvénient administratif. Il agit là où la loi fournit la compétence, où un demandeur a un intérêt reconnaissable et où un défendeur approprié peut être contraint de fournir une réparation.

Un litige de domaine précoce pouvait impliquer l'autorité organisationnelle, le contrat, la marque de commerce ou un autre intérêt juridique. Un contractant fédéral pouvait posséder des droits en vertu de son propre accord. L'action d'un sponsor gouvernemental pouvait être soumise à une loi ou une règle de programme distincte. Ces possibilités dépendaient de faits au-delà du formulaire d'identifiant.

Les guides techniques de l'époque ne déclaraient pas qu'un demandeur infructueux pouvait demander à un tribunal d'examiner le jugement technique du Hostmaster. Ils n'établissaient pas non plus que chaque action du NIC ou de l'IANA était une action finale de l'agence. Le statut de contractant, l'autorité technique déléguée, le parrainage fédéral et le financement gouvernemental ne s'effondrent pas en une seule catégorie de droit public.

Les canaux d'agence nécessitent le même soin. La DCA, la DARPA, le DDN-PMO ou un autre organisme fédéral pouvait recevoir des plaintes dans le cadre de ses responsabilités de programme ou contractuelles. La question de savoir s'il devait décider de la réclamation d'un demandeur, pouvait contraindre un contractant à modifier un enregistrement ou offrait un recours exécutoire dépendrait de l'autorité gouvernante.

Aucun enregistrement direct de 1983-1992 dans cet échantillon n'associe un refus d'identifiant à un jugement de tribunal, un ordre d'agence ou une décision contractuelle qui l'a annulé. Le recours externe reste juridiquement possible dans l'abstrait et historiquement non prouvé dans la population de cas pertinente.

Contrefactuel A: préserver les décisions, ajouter les raisons

Imaginez que chaque décision substantielle d'identifiant et de connexion de 1983-1992 reste inchangée. Les mêmes demandes complètes ont réussi. Les mêmes défauts techniques ont nécessité une correction. Les mêmes règles de sponsor régissaient l'accès à l'infrastructure soutenue par le gouvernement fédéral.

Changez seulement le dossier. Donnez à chaque demande unique une date de réception et un identifiant durable. Lorsque le traitement s'arrête, conservez une courte raison et le bureau responsable. Si le même bureau reconsidère, liez la deuxième décision à la première. Si l'affaire est transférée à un sponsor, à l'IANA, à la direction ou à une autre autorité, enregistrez le renvoi et le résultat final.

Ce dossier améliorerait la vérifiabilité même si les taux d'approbation ne bougeaient pas. Les chercheurs pourraient distinguer un champ manquant d'un refus substantiel. Les demandes répétées pourraient être identifiées comme des corrections, des remplacements ou des reconsidérations. Le temps écoulé pourrait être séparé en réponse du demandeur, traitement du personnel, examen du sponsor et intervalles non résolus. Les changements de politique pourraient être liés aux types de cas qui ont révélé un problème.

Le dossier supplémentaire pourrait améliorer la détection des erreurs. Des raisons comparables pourraient révéler des classifications incohérentes, ou elles pourraient montrer que des résultats apparemment différents reposaient sur des faits différents. C'est une possibilité, pas un effet historique mesuré.

Aucune affirmation n'est faite que des devoirs modernes de droit administratif régissaient déjà chaque enregistrement Internet précoce. Le contrefactuel pose une question institutionnelle plus étroite: quelle preuve aurait permis aux contemporains et aux historiens ultérieurs de tester la cohérence sans changer la structure d'autorité sous-jacente?

Un journal des raisons et des résultats datés ne créerait pas en soi l'indépendance. L'examinateur pourrait toujours appartenir au même bureau. Il ne garantirait pas non plus l'équité. Il rendrait le chemin suffisamment visible pour être évalué.

Contrefactuel B: conflit véritablement faible

Supposez maintenant que l'administration de première instance était généralement exacte. Les demandeurs étaient techniquement compétents, les exigences étaient largement comprises et la plupart des problèmes étaient résolus par une correspondance de confiance. Les refus substantiels et les différends sérieux étaient rares.

Quelles traces ce système bénin laisserait-il?

La plupart des demandes incomplètes seraient suivies de questions identifiables et de corrections rapides. Les soumissions répétées correspondraient ordinairement à des changements techniques ou administratifs visibles. Le temps écoulé après l'achèvement serait court ou expliqué par la préparation du serveur, le parrainage ou une autre dépendance externe. Les contacts avec les sponsors clarifieraient l'éligibilité plus souvent qu'ils ne remplaceraient des jugements antérieurs. Les traces de plaintes seraient rares par rapport à une population de demandes connue.

Les demandes retirées nécessiteraient des explications du côté du demandeur pour être séparées des refus silencieux. Les résolutions téléphoniques nécessiteraient des notes contemporaines liant l'appel à la demande. Un échantillon statistiquement défendable devrait montrer peu de désaccords non résolus après contrôle de la complétude et de la préparation technique.

Des parties de l'infrastructure bénigne sont visibles. La RFC 1032 attendait une correspondance. Le NIC maintenait des canaux d'assistance et de gestion. Les administrateurs d'hôtes pouvaient corriger les dossiers des utilisateurs. Le DDN-PMO a dit qu'il travaillerait avec les administrateurs si des problèmes survenaient. La RFC 1359 traitait les fournisseurs comme des sources de conseils sur les demandes. La RFC 1174 décrivait une politique visant à attribuer des numéros uniques largement tout en séparant la sanction de connexion.

Ce qui reste inobservé, c'est la performance de ces canaux. Le nombre de demandes uniques est inconnu. De même que le nombre de demandes renvoyées pour information, retirées, refusées, reconsidérées, escaladées et annulées. Il n'y a pas de comparaison des classes d'appelants ou des résultats finaux.

Un système dans lequel les demandeurs déçus disparaissaient pouvait produire la même liste d'attributions publiée qu'un système sans presque aucun conflit sérieux. La preuve distinctive réside dans la correspondance des demandes et les dossiers de disposition, pas dans la propreté du registre.

Une vue étroite au-delà de 1992

RFC 1400, publiée en mars 1993, offre une comparaison limitée post-période. Elle décrivait l'analyse et la vérification des modèles d'enregistrement, la correction par le demandeur d'origine, l'expiration après une fenêtre de réponse de sept jours, les numéros de ticket d'incident et les informations d'état public indiquant si un ticket restait en attente et qui le traitait.

Ces fonctionnalités rendaient les états de traitement plus observables. Elles n'ont pas créé un organe d'appel indépendant. L'erreur d'analyse, la vérification, la correction et le traitement final par le personnel restaient des parties de l'administration plutôt que des examens par une autorité distincte.

La comparaison ne soutient que cette conclusion: une procédure publique pouvait exposer un identifiant de demande et un état intermédiaire. Son apparition en 1993 ne prouve pas que le suivi interne antérieur était absent, et elle ne répond pas à la manière dont les différends substantiels étaient examinés.

Ce qui peut être conclu

Trois propositions doivent rester séparées.

Premièrement, les procédures publiées examinées ici n'identifiaient pas de bureau d'appel général et indépendant pour les demandes infructueuses de domaine ou d'identifiant numérique pendant 1983-1992. Elles spécifiaient les demandes, les administrateurs responsables, les exigences techniques, la correction, la correspondance, les frontières des litiges locaux et l'autorité institutionnelle. Elles n'établissaient pas de voie générale pour les demandeurs vers un examinateur de deuxième instance nommé et une décision finale enregistrée.

Deuxièmement, la résolution informelle était institutionnellement possible et, pour les problèmes ordinaires, plausible. Le NIC était joignable. Le personnel attendait une correspondance. Les administrateurs et les sponsors occupaient des rôles définis. Les fournisseurs pouvaient conseiller les demandeurs. La direction et les organismes gouvernementaux pouvaient recevoir des préoccupations dans le cadre de leurs responsabilités. Ces canaux ont pu résoudre de nombreux cas rapidement, mais l'échantillon ne mesure pas leur utilisation ou leurs résultats.

Troisièmement, le dénominateur reste inconnu. L'échantillon ne contient pas de corpus au niveau de la demande à partir duquel compter les cas incomplets, retardés, retirés, refusés, corrigés, reconsidérés, escaladés, annulés ou définitifs. Il ne contient aucun dossier de refus et d'annulation qualifié. L'absence de preuves empêche à la fois une accusation d'abus systématique et une affirmation de cohérence démontrée.

Les administrateurs des débuts d'Internet résolvaient un problème de coordination difficile à travers des frontières techniques et institutionnelles en évolution rapide. Un système pouvait être compétent, coopératif et laisser néanmoins des archives procédurales faibles. Il pouvait corriger des erreurs sans nommer l'acte reconsidération. Il pouvait changer de politique sans entendre d'appels individuels. Il pouvait fournir une aide efficace tout en distribuant cette aide par le biais de relations que les historiens ultérieurs ne peuvent pas évaluer.

Le bureau d'appel manquant n'est donc pas la preuve qu'un bureau particulier aurait dû exister mais n'existait pas. C'est la chaîne absente de raisons, d'examinateurs et de résultats nécessaires pour déterminer ce qui s'est passé après l'échec de la voie normale.

Un faible conflit visible peut refléter une bonne administration. Il peut refléter une résolution privée. Il peut refléter des demandeurs qui ont disparu du dossier survivant. Jusqu'à ce que des dossiers directs de demande fournissent le dénominateur, ces explications doivent rester séparées.

Sources

• RFC 810, « DoD Internet Host Table Specification », 1^ermars 1982:https://www.rfc-editor.org/rfc/rfc810.html
• RFC 920, « Domain Requirements », octobre 1984:https://www.rfc-editor.org/rfc/rfc920.html
• RFC 1032, « Domain Administrators Guide », novembre 1987:https://www.rfc-editor.org/rfc/rfc1032.html
• RFC 1062, « Internet Numbers », août 1988:https://www.rfc-editor.org/rfc/rfc1062.html
• RFC 1174, « IAB Recommended Policy on Distributing Internet Identifier Assignment and IAB Recommended Policy Change to Internet 'Connected' Status », août 1990:https://www.rfc-editor.org/rfc/rfc1174.html
• RFC 1359, « Connecting to the Internet », août 1992:https://www.rfc-editor.org/rfc/rfc1359.html
• RFC 1400, « Transition and Modernization of the Internet Registration Service », mars 1993:https://www.rfc-editor.org/rfc/rfc1400.html
• Network Information Center, « Instructions for Network User Registration Drive », 20 octobre 1983, pages internes 1-7, pages 67-73 du lot numérisé dansDefense Communication Agency Materials; 6 of 13:https://archive.computerhistory.org/resources/access/text/2023/07/102707743-05-06-acc.pdf
• DDN Network Information Center, « How to Reach the NIC »,NIC KNACKS, numéro 2, 17 mai 1985, page 94 du lot numérisé dansDefense Communications Agency Materials; 3 of 13:https://archive.computerhistory.org/resources/access/text/2023/07/102707743-05-03-acc.pdf
• Computer History Museum,Guide to the SRI ARC/NIC Records, collection X3578.2006, 2011:https://archive.computerhistory.org/resources/access/text/finding-aids/102706170-SRI/102706170-SRI.pdf
• James Pelkey, entretien avec Jonathan « Jon » Postel, enregistré le 18 février 1988:https://archive.computerhistory.org/resources/access/text/2016/05/102738139-05-01-acc.pdf
• US Government Accountability Office, B-327398, « Department of Commerce—Property Implications of Proposed Transition of U.S. Government Oversight of Key Internet Technical Functions »:https://www.gao.gov/products/b-327398