La table d'hôte avant le marché: qui a autorisé le premier registre Internet?

Résumé

• La première table d'hôte a acquis une autorité pratique grâce à une chaîne délimitée: l'ARPA a financé le Network Information Center pour ARPANET, le SRI a tenu à jour le registre commun, les sites entités ont fourni et consommé les informations sur les hôtes, et la DCA a par la suite intégré le service dans un environnement opérationnel du DoD.
• La RFC 810 a publié une condition préalable d'enregistrement pour les noms et adresses utilisés en relation avec le trafic acheminé par les hôtes du DoD, mais la spécification conservée ne démontre pas de surveillance, de rejet de paquets, de sanctions, de taux de conformité ni de communication bloquée particulière.
• Le dossier public ne fournit pas les premiers contrats complets, les fichiers de demande de table d'hôte, les décisions contestées, les résultats de corrections, les enregistrements de dérogation, les rapports d'application ou les recours nécessaires pour établir soit un pouvoir discrétionnaire illimité du NIC, soit un mandat public s'étendant à tous les réseaux extérieurs.

Le 8 mars 1974, le Network Information Center a demandé à chaque site ARPANET de modifier une table d'hôte locale. L'instruction est apparue dans laRFC 620, « Demande de mises à jour de la table d'hôte du moniteur », publiée par Bill Ferguson du Centre de Recherche en Augmentation du SRI. Les services du NIC avaient été déplacés versOFFICE-1, au site réseau 53 en notation octale. Le site 2 restaitSRI-ARC, mais son surnom devait devenirARC; le surnom familierNICdevait désormais pointer vers le site 53. L'avis fournissait les entrées exactes pour les tables de moniteur TENEX et demandait aux sites utilisant d'autres systèmes d'exploitation d'effectuer des modifications équivalentes.

La RFC 620 consigne une instruction, et non un cas de conformité observé. Elle n'identifie aucun opérateur individuel ayant effectué le travail, aucun site ne l'ayant pas fait et aucune panne en résultant. L'opérateur est néanmoins un rôle nécessaire impliqué par le document: quelqu'un sur chaque site devait modifier la correspondance utilisée localement de la manière appropriée à ce système d'exploitation. Si une table restait obsolète, elle continuerait d'associerNICau site 2 et pourrait détourner une tentative basée sur le nom du service NIC prévu. Cette conséquence découle du changement de correspondance, mais la RFC ne rapporte pas d'échec de recherche ou de connexion mal dirigée réel.

L'avis expose la structure administrative derrière un nom apparemment simple. Le SRI pouvait annoncer la nouvelle association, mais l'annonce ne réécrivait pas chaque machine distante. Un site devait recevoir l'instruction, l'interpréter et modifier son propre système. La dénomination partagée fonctionnait lorsque le registre tenu à jour, le canal de distribution et la mise en œuvre locale convergeaient.

Le 25 mars 1974, laRFC 627a annoncé un mécanisme de distribution plus régulier. Le fichier ASCII en ligne des noms d'hôtes officiels était disponible surOFFICE-1, dont l'adresse apparaissait en 43 en notation décimale, équivalente au 53 octal utilisé dans la RFC 620. Le NIC maintenait le fichier et y incorporait les ajouts ou modifications chaque semaine. Chaque hôte du réseau était responsable de récupérer les nouvelles informations via le File Transfer Protocol. Les modifications, ajouts, corrections et commentaires pouvaient être adressés à Elizabeth « Jake » Feinler par courrier réseau, téléphone ou via le système d'identification du NIC.

Ces deux documents de mars ne conservent pas une transaction complète de demande à décision. Ils peuvent toutefois être combinés avec des enregistrements antérieurs et ultérieurs pour établir une reconstitution composite minimale, à condition que leurs dates restent distinctes.

En 1971, un hôte sélectionnait un nom formel préféré par l'intermédiaire de son agent de liaison selon la procédure proposée dans laRFC 273. L'agent de liaison transmettait le choix; le document n'établit pas qu'un agent de liaison technique possédait personnellement l'autorité de prendre toutes les décisions organisationnelles pour le site. Le schéma de nommage proposé s'attendait à ce que les surnoms soient uniques au sein de la communauté du réseau et envisageait une discussion si des noms en double ou excessivement longs étaient sélectionnés. Il ne spécifiait pas un veto du NIC, un test de rejet, une règle de décision finale, une dérogation ou un appel.

En janvier 1974, laRFC 608décrivait le nom d'hôte officiel comme une chaîne obtenue par négociation entre l'hôte et le NIC. Elle établissait des contraintes de caractères et de format, identifiait le fichier source NLS de Feinler, et proposait la génération périodique d'une édition ASCII lisible par machine. Elle n'expliquait pas comment les négociations contestées se terminaient ni qui prévalait en cas d'échec de la discussion.

En mars 1974, la RFC 627 établissait le fichier disponible, l'incorporation hebdomadaire des mises à jour, un canal de correction et la responsabilité de chaque hôte de récupérer les nouvelles informations. Ce n'est qu'en 1982 que laRFC 810a explicitement déclaré que l'utilisateur de la table d'hôte du DoD était responsable de la traduire dans le format local requis. Il serait inexact de compresser ces déclarations de 1971, 1974 et 1982 en une seule routine observée ou d'attribuer chaque étape au même responsable.

Le composite défendable est donc modeste. Un hôte communiquait son nom préféré par l'intermédiaire d'un agent de liaison. Des conventions publiées régissaient la forme de ce nom, l'unicité des surnoms était attendue, et les choix en double ou longs pouvaient susciter une discussion. Le SRI maintenait une source à partir de laquelle il générait un fichier commun. Les sites récupéraient le fichier et incorporaient son contenu dans les systèmes locaux. En 1982, la responsabilité de l'utilisateur pour la traduction locale était énoncée expressément. Ce qui se passait lorsqu'un nom proposé restait contesté, lorsqu'une correction était contestée ou lorsqu'un site rejetait une instruction ne peut être reconstitué à partir des seules RFC procédurales.

Ceci est la première limite de l'autorité de la table d'hôte. Le registre commun pouvait déterminer quel nom un système entité reconnaissait sans décider si l'ordinateur sous-jacent existait, si une ligne physique avait été installée ou si une organisation avait été admise sur le réseau. Ses effets étaient opérationnels et parfois graves pour une utilisation basée sur le nom, mais ils n'étaient pas identiques au contrôle de toute la connectivité.

Quatre tables divergentes et la nécessité d'un fichier commun

Le fichier d'hôtes en ligne répondait à un problème de coordination observé. En décembre 1973, laRFC 606décrivait quatre systèmes TENEX accessibles —SRI-ARC,BBN-TENEX,USC-ISIetPARC-MAXC— dont les correspondances entre noms d'hôtes et adresses différaient. Aucune n'était complète, et l'auteur pensait que chacune divergeait à certains égards de la liste officielle.

Cette preuve ne doit pas être gonflée pour affirmer que chaque site ARPANET avait une table inexacte. Elle établit une divergence sur quatre systèmes nommés. Même cette constatation limitée suffisait à démontrer le coût d'une maintenance séparée. Une personne passant d'une machine à l'autre pouvait rencontrer des réponses différentes. Un programme écrit pour un ensemble local pouvait échouer lorsqu'il était déplacé vers un autre. Un hôte nouvellement ajouté ou renommé pouvait être reconnu sur un site tout en restant inconnu sur un autre.

La RFC 606 proposait un fichier lisible par machine généré centralement et maintenu par le NIC. Elle distinguait les deux faits principaux d'une entrée — le nom d'hôte et l'adresse de l'hôte — des attributs facultatifs tels que le statut de l'hôte, le comportement du protocole et les surnoms. Son auteur avertissait que les attributs ne devaient pas nécessairement être complets et ne devaient pas remplacer la négociation de protocole, le bouche-à-oreille ou d'autres moyens de découvrir les propriétés d'un hôte. La proposition était délibérément spécifique: elle cherchait à résoudre les listes locales incompatibles, et non à établir une constitution globale pour la participation au réseau.

La RFC 608 a accepté l'idée du fichier central et a rapporté qu'elle avait le soutien du bureau des Techniques de Traitement de l'Information de l'ARPA. Feinler maintenait la source au format NLS du SRI, tandis qu'un programme devait générer périodiquement le fichier de distribution ASCII. Initialement, les entrées générées contiendraient le nom officiel, l'adresse décimale de l'hôte et le statut. D'autres informations pourraient être ajoutées à mesure que les données deviendraient disponibles. Le document autorisait également un préfixe réseau pour les hôtes extérieurs à ARPANET, montrant que les auteurs envisageaient déjà un ensemble de comparaison plus large que la population des hôtes ARPANET. Il n'identifie pas tous les hôtes extérieurs effectivement inclus.

La distinction entre source et distribution importait. NLS était un système du SRI utilisé pour maintenir des informations structurées. L'édition ASCII était conçue pour la récupération et le traitement par des hôtes hétérogènes. SRI-ARC était le contexte organisationnel et informatique d'où plusieurs de ces avis ont été émis, tandis queOFFICE-1est devenu la machine servant les utilisateurs du NIC et le fichier hôte publié en mars 1974. Les documents ultérieurs utilisaientSRI-NICpour l'hôte fournissant la table du DoD et le service de noms. Ces étiquettes marquent des changements techniques et organisationnels; elles ne doivent pas être traitées comme des noms interchangeables pour une machine inchangée.

La RFC 627 a converti la proposition en un service annoncé. Elle encourageait les hôtes à utiliser les noms officiels dans leurs moniteurs et rendait chaque hôte responsable de la récupération du fichier. Les surnoms étaient facultatifs, et les systèmes fournissant une traduction nom-adresse étaient encouragés plutôt que tenus de les utiliser. Le document fournissait des canaux pour les ajouts et les corrections, mais l'existence d'un canal ne prouve pas le temps nécessaire, les preuves exigées ou le recours disponible lorsqu'une demande était refusée.

L'architecture restait distribuée au point d'utilisation. Le SRI maintenait le fichier de référence, mais les sites distants décidaient quand le récupérer et comment l'installer. Un maître récemment corrigé pouvait coexister avec des copies locales obsolètes. Un opérateur pouvait compléter un fichier officiel par un alias local. Une personne connaissant une adresse numérique pouvait contourner un nom manquant. La table réduisait l'incohérence sans devenir le sous-réseau de commutation de paquets lui-même.

Une entrée erronée pouvait néanmoins avoir des effets matériels. Un programme basé sur le nom pouvait diriger le trafic vers l'adresse enregistrée plutôt que vers la machine prévue. Une entrée absente pouvait laisser le logiciel incapable de traduire le nom demandé. Une mise à jour locale retardée pouvait conserver un résultat obsolète. Le comportement exact dépendait du système d'exploitation et de l'application locaux. Les RFC ne justifient pas une affirmation universelle selon laquelle chaque omission produisait une déconnexion ou que chaque entrée inexacte produisait la même erreur.

Le déplacement de mars illustre la proposition plus étroite. Après queNICa été déplacé versOFFICE-1, un site qui mettait en œuvre le changement de la RFC 620 associerait le surnom au site 53. Un site obsolète pourrait continuer de l'associer au site 2. Le déplacement du service du SRI se produisait indépendamment de la table distante, tandis que l'utilité du surnom partagé dépendait de l'adoption à distance. Le registre était conséquent parce que d'autres machines agissaient en fonction de lui.

Les noms ont commencé avec les hôtes, pas avec un veto illimité du NIC

Le fichier commun n'est pas issu d'une règle établie qui permettait au NIC d'attribuer n'importe quel nom qu'il souhaitait. La discussion de la RFC de 1971 enregistre un désaccord substantiel sur le nommage.

LaRFC 226a diffusé un ensemble proposé de mnémoniques et a invité à des objections. Des suggestions concurrentes ont suivi. Certains entités favorisaient des indicatifs courts; d'autres voulaient des noms qui préservaient les identités institutionnelles et de projet. Le débat n'était pas simplement cosmétique. Les noms apparaissaient dans les commandes, les documents et les habitudes des utilisateurs. Une règle de nommage distribuait donc des inconvénients et de la reconnaissance ainsi que des caractères.

Dans laRFC 237, le NIC soutenait qu'il était un organe logique pour maintenir la norme de nommage et proposait d'attribuer des noms aux nouveaux hôtes une fois que le Groupe de Travail du Réseau aurait réglé la syntaxe et la liste actuelle. C'était une proposition institutionnelle de l'opérateur du service. Cela prouve ce que le NIC souhaitait que son rôle soit, et non que chaque organisation connectée ou une autorité publique supérieure acceptait l'ensemble de la revendication.

La RFC 273 a répondu à l'échec des propositions précédentes à être acceptées. Elle disait que les hôtes, par l'intermédiaire de leurs agents de liaison, devaient choisir leurs propres noms formels, éventuellement sujets à discussion s'ils sélectionnaient des noms en double ou extra-longs. Les hôtes d'une même institution devaient utiliser le même mnémonique institutionnel. Un surnom devait être unique au sein de la communauté du réseau.

Le langage établit le choix local et la possibilité d'une discussion centrale. Il ne définit pas qui pouvait émettre un refus final. Un double rendrait vain l'objectif d'un surnom partagé, mais l'incompatibilité technique seule ne révèle pas le recours administratif. Le NIC a peut-être persuadé un site de choisir un autre nom; un sponsor a peut-être intervenu; les sites ont peut-être accepté une convention informelle; ou un désaccord a peut-être subsisté sans résolution. Un dossier complet serait nécessaire pour distinguer ces possibilités.

LaRFC 289, publiée en décembre 1971, rapportait que presque tous les sites avaient répondu avec les noms souhaités. Son titre, « Ce que nous espérons être une liste officielle des noms d'hôtes », préserve le caractère provisoire de l'exercice. La liste émergente reflétait une sollicitation et une réponse des sites au sein d'une communauté ARPANET délimitée. Elle n'était ni une invention privée unilatérale ni le résultat d'une délégation publique mondiale.

Le rôle de l'agent de liaison requiert également de la prudence. La RFC 273 utilisait les agents de liaison comme canal par lequel les hôtes choisissaient et communiquaient les noms. Unguide du Computer History Museum sur les archives SRI ARC/NICindique que les agents de liaison techniques n'avaient généralement pas l'autorité de parler au nom de l'administration du site. Le guide d'archives décrit la création ultérieure d'un rôle d'administrateur d'hôte dont le titulaire pouvait autoriser l'action du site. Parce que le guide couvre une période plus longue, il ne peut pas simplement être projeté en arrière dans chaque échange de 1971. Il met cependant en garde contre le fait de traiter « agent de liaison » comme synonyme de cadre dirigeant institutionnel.

Le plus que l'on puisse dire en toute sécurité est que l'hôte était le choisisseur d'origine dans la procédure publiée de 1971, l'agent de liaison était le canal de communication, et le NIC maintenait le résultat partagé. La syntaxe et l'unicité attendue limitaient ce qui pouvait fonctionner dans l'espace de noms commun. Les documents ne révèlent pas un système d'arbitrage complet.

Ce pouvoir discrétionnaire limité était néanmoins significatif. Une fois qu'un nom apparaissait dans les documents et les fichiers lisibles par machine, les utilisateurs ailleurs pouvaient s'y fier. Un hôte pouvait changer de nom, mais cela imposait des coûts aux logiciels, à la documentation et aux connaissances locales. La stabilité est devenue une source d'autorité pratique. Le centre n'avait pas besoin d'un large pouvoir légal pour rendre sa réponse maintenue difficile à ignorer.

Le contrat de service de l'ARPA et le transfert à la DCA

La chaîne institutionnelle a commencé avec un programme de recherche fédéral, et non avec l'Internet plus large.

ARPANET était un réseau à commutation de paquets particulier établi par l'Advanced Research Projects Agency au sein du Département de la Défense des États-Unis. L'ARPA a financé le programme de recherche, sélectionné les contractants et soutenu les centres de recherche entités. L'agence est devenue la Defense Advanced Research Projects Agency en 1972. « ARPA » est donc approprié pour l'établissement du réseau et le débat de nommage précoce, tandis que « DARPA » apparaît dans les enregistrements de la période ultérieure.

LeRapport d'Achèvement d'ARPANET, préparé en 1978, indique que le Stanford Research Institute a reçu un contrat pour développer et exploiter un Network Information Center pour ARPANET. Le travail a commencé parallèlement à la mise en œuvre du réseau en 1969. Le rapport décrit un service qui maintenait des listes de entités et de distribution, archivait les documents techniques, fournissait des informations sur les ressources des hôtes, donnait accès au système NLS du SRI et maintenait les spécifications des protocoles ARPANET.

Cela établit une relation sponsor-contractant. L'ARPA a acheté un service d'information pour le réseau et la communauté de recherche qu'elle soutenait. Le SRI avait l'obligation d'exécuter tout ce que le contrat exigeait, et l'ARPA avait le droit correspondant à la performance contractuelle. Le rapport public ne reproduit pas l'énoncé des travaux initial, les avenants, les normes d'acceptation, les sanctions, les clauses de données ou les règles de décision sur les noms d'hôtes. Il ne peut donc pas établir le contenu juridique complet de cette obligation.

Les sites connectés à ARPANET étaient institutionnellement divers. Ils comprenaient des universités, des instituts de recherche, des laboratoires gouvernementaux, des installations militaires et des entreprises privées. La diversité des formes juridiques ne faisait pas de chaque site un opérateur public non affilié. Beaucoup participaient par le biais de parrainages fédéraux, de contrats ou de relations de mission approuvées. En même temps, l'absence des instruments contractuels sous-jacents empêche d'affirmer que chaque organisation connectée avait une clause contractuelle identique exigeant la conformité à la table d'hôte.

Le récit direct le plus solide du transfert de l'ARPA à la Defense Communications Agency est échelonné et daté. Le Rapport d'Achèvement décrit un mémorandum ARPA-DCA en vertu duquel la gestion d'ARPANET a été transférée à la DCA le 1er juillet 1975. Il enregistre également une phase de transition de six mois, jusqu'au 31 décembre 1975, pendant laquelle l'ARPA a continué d'assister la DCA tandis que la DCA prenait le rôle de gestionnaire. Un plan de transition détaillé avait été achevé en juin.

Le rapport indique que le réseau transféré devait fonctionner comme une installation du DoD utilisée pour les activités gouvernementales. La DCA financerait l'exploitation et la maintenance par un accord de répartition des coûts impliquant les sponsors d'ARPANET. La DCA devait initialement contracter avec BBN et le SRI pour l'exploitation du réseau, la maintenance et les fonctions du NIC. Le rapport dit qu'il était clairement sous-entendu que la DCA pourrait retenir d'autres contractants par la suite, certainement après la première année.

C'est une preuve de la possibilité de remplacement institutionnel au niveau de la sélection des contractants. Cela ne prouve pas que la DCA possédait une copie portable complète de chaque enregistrement du NIC, des droits illimités sur les données créées par le contractant, un ensemble de transition testé ou un recours exécutoire pour chaque défaillance de service. Un client peut en principe pouvoir sélectionner un autre fournisseur tout en faisant face à des obstacles pratiques formidables pour transférer les connaissances du personnel, les logiciels, les archives, les enregistrements actuels et les relations avec les sites.

Une publication de la DCA de 1978 indexée comme laBrochure d'Information ARPANETdonne également le 1er juillet 1975 comme date de transfert de gestion. L'instrument de recherche du Computer History Museum présente un compte rendu rétrospectif contradictoire: il indique que l'exploitation d'ARPANET a été transférée à la DCA en 1973 et que le financement contractuel de la DCA a soutenu le NIC du SRI après 1974.

Le conflit doit rester visible. La chronologie formelle du mémorandum dans le Rapport d'Achèvement fournit une date de transfert précise et une phase de transition. L'instrument de recherche fournit des dates sommaires différentes mais pas l'instrument sous-jacent qui les réconcilierait. Il indique également que le NIC est devenu un projet distinct en 1973, ce qui est un changement institutionnel différent du transfert de la gestion d'ARPANET. Sans les contrats et les dossiers administratifs pertinents, la déclaration opérationnelle de 1973 et la déclaration de financement postérieure à 1974 ne peuvent pas être converties en une chronologie unique et sans faille.

Après le transfert formel, la DARPA pouvait continuer à parrainer des recherches utilisant ARPANET tandis que la DCA gérait le réseau opérationnel. Le DoD était l'environnement gouvernemental parent; la DARPA et la DCA y avaient des fonctions différentes. Le SRI restait un contractant exécutant les services du NIC plutôt que de devenir le gouvernement lui-même. Les sites entités exploitaient des hôtes. Les agents de liaison des hôtes et les rôles de contact ultérieurs transmettaient des informations et des instructions. Garder ces rôles distincts empêche de confondre le pouvoir de passation de marchés avec un pouvoir universel.

L'admission à ARPANET n'était pas une décision de la table d'hôte

La table d'hôte enregistrait les machines dans un environnement opérationnel, mais la maintenance du registre par le SRI ne faisait pas du SRI la seule autorité décidant qui pouvait rejoindre ARPANET.

LeRépertoire ARPANET de décembre 1978décrivait les catégories d'abonnés et le processus d'obtention du service. Son cadre plaçait l'admission et le parrainage dans la structure de gestion de réseau de la DCA. Un abonné potentiel devait avoir un objectif gouvernemental acceptable, un parrainage et des installations disponibles. Ces décisions concernaient l'accès à un réseau géré spécifique.

La distinction est fondamentale. La DCA pouvait administrer l'éligibilité des abonnés à ARPANET. Le SRI pouvait maintenir le répertoire et les informations sur les hôtes utilisés après ou autour de l'admission. Une entrée dans la table d'hôte pouvait être nécessaire pour une utilisation partagée pratique, mais l'enregistrement de l'hôte n'était pas le même acte institutionnel que l'approbation de la connexion de l'organisation, l'installation d'un processeur de message d'interface, la fourniture d'un circuit ou l'autorisation d'une mission.

La population d'ARPANET ne doit pas non plus être assimilée à l'Internet du DoD. ARPANET était un réseau. L'Internet du DoD était un environnement d'interconnexion dans lequel ARPANET, les systèmes de radiocommunication par paquets, les systèmes satellites et d'autres réseaux pouvaient utiliser les protocoles Internet et des informations de coordination communes. L'Internet émergent plus large était plus vaste encore: un ensemble changeant de réseaux, d'expériences et d'opérateurs dont les relations juridiques, contractuelles et techniques n'étaient pas uniformes.

En septembre 1981, laRFC 790listait les numéros de réseau Internet attribués pour de nombreux réseaux nommés, y compris ARPANET, UCLNET, CYCLADES, TELENET, l'EPSS de la Poste britannique, DATAPAC, TRANSPAC, LCSNET, TYMNET et un assortiment de systèmes radio par paquets, satellites, locaux et expérimentaux. Elle identifiait Jon Postel à l'Information Sciences Institute de l'Université de Californie du Sud comme le contact pour l'attribution des numéros de réseau.

La liste prouve que l'environnement des numéros attribués s'étendait au-delà d'une liste d'hôtes ARPANET. Elle n'établit pas, par elle-même, que chaque réseau nommé était interconnecté opérationnellement à ce moment-là, indépendant du parrainage gouvernemental, commercial, non-DoD ou régi par le processus de la table d'hôte du SRI. Un numéro apparaissant dans un document d'attribution n'est pas un compte rendu complet du statut contractuel du réseau ou du trafic réel.

Elle sépare également des fonctions que les histoires ultérieures mélangent parfois. Le rôle de Postel dans l'attribution des numéros à l'USC-ISI concernait les paramètres de réseau et de protocole. Le SRI maintenait la table d'hôte et le service de noms. La DCA gérait ARPANET et commandait le service du NIC. La DARPA continuait le parrainage de la recherche. Aucun de ces faits ne fait d'un acteur l'auteur unique de l'Internet émergent tout entier.

L'expression « premier registre Internet » nécessite donc une comparaison définie. La table d'hôte n'était pas le premier répertoire jamais maintenu par une organisation informatique, et le fichier de 1974 n'était pas un registre pour un Internet public mondial. C'était une référence précoce partagée et lisible par machine des noms et adresses dans la lignée ARPANET-Internet. En 1982, son format successeur incorporait les réseaux, les passerelles et les adresses Internet et était décrit par ses opérateurs comme une base de données globale des noms et adresses d'hôtes. Sa signification historique réside dans la portée croissante et la dépendance interorganisationnelle de cette référence, et non dans un mandat prouvé sur chaque réseau.

La règle du DoD de 1982: une condition préalable publiée, pas une application prouvée

La RFC 810 marquait un changement de portée et de langage institutionnel. Publiée le 1er mars 1982 par Feinler, Ken Harrenstien, Zaw-Sing Su et Vic White du Network Information Center de SRI International, elle indiquait que l'ancienne table d'hôte ARPANET ne répondait plus aux besoins de la communauté du DoD ou de l'interconnexion. Le nouveau format comprenait des entrées de réseau, de passerelle et d'hôte, des adresses Internet, des systèmes d'exploitation et des informations de protocole.

La table était disponible sur l'hôteSRI-NICvia FTP et via le Serveur de Noms d'Hôtes. La RFC identifiait le serveur comme un service maintenu par le NIC ARPANET pour le compte de la DCA. Elle assignait également expressément la responsabilité de la traduction à l'utilisateur: quiconque consommait la table devait la convertir dans le format requis localement.

Sa septième hypothèse contenait le langage opérationnel le plus fort dans l'enregistrement de la table d'hôte. Les noms et adresses pour les réseaux, passerelles et hôtes du DoD devaient être négociés et enregistrés auprès du NIC avant d'être utilisés et avant que le trafic ne soit acheminé par un hôte du DoD. C'était une condition préalable publiée régissant le comportement de l'hôte du DoD. Elle reliait l'enregistrement au fonctionnement plus directement que l'encouragement de 1974 à utiliser les noms d'hôtes officiels.

La phrase ne documente pas l'application. La RFC 810 n'identifie pas un moniteur inspectant les enregistrements, une règle de routeur rejetant le trafic non enregistré, une sanction pour non-conformité, un taux de conformité ou une communication particulière qui a été bloquée. La différence est importante. Une spécification peut définir une conduite requise sans prouver avec quelle constance les opérateurs l'ont mise en œuvre.

Le document traitait les informations non-DoD différemment. Pour une période intérimaire, le NIC tenterait de maintenir des informations similaires pour les réseaux et hôtes non-DoD si ces informations étaient fournies et aussi longtemps que nécessaire, en attendant des serveurs de noms intercommunicants. Il n'identifiait ni chaque entrée non-DoD effectivement incluse ni n'imposait la même condition préalable expresse à tous les opérateurs extérieurs.

Le nouveau format avait également une introduction échelonnée. La RFC 810 spécifiait le 1er mai 1982 comme date de basculement. Pendant le mois de mai, le cheminHOSTS.TXTexistant contenait encore l'ancienne édition tandis qu'un fichier de test au nouveau format était disponible séparément. En juin et juillet, le chemin principal contenait le nouveau format, tandis que le matériel à l'ancien format restait accessible par un autre chemin. Après le 1er août, l'ancien formatHOSTS.TXTspécifié par la RFC 608 ne serait plus supporté.

Ce chevauchement distinguait une conception publiée d'une mise en œuvre universelle immédiate. Les programmes avaient le temps de s'adapter. Les systèmes locaux pouvaient rester sur des éditions différentes pendant la transition. Le calendrier montre une gestion active du risque de compatibilité, mais il ne prouve pas que chaque hôte a terminé la conversion à temps.

LaRFC 811, publiée le même jour, spécifiait le Serveur de Noms d'Hôtes en ligne. Un programme pouvait interroger pour un nom ou une adresse d'hôte ou demander la table entière. Le serveur pouvait retourner des enregistrements d'hôte, de passerelle ou de réseau. Si un nom demandé était absent, l'erreur définie prenait la formeERR: NAMNFD: Nom non trouvé:. D'autres erreurs étaient possibles, y comprisTMPSYS, signifiant une défaillance temporaire du système et une demande de réessayer plus tard.

Ces sémantiques appartiennent au protocole du serveur SRI-NIC. Elles ne doivent pas être projetées sur chaque résolveur local utilisant une copie téléchargée. Une recherche locale dans une table dépourvue d'une entrée pouvait échouer, utiliser une correspondance supplémentaire, inviter l'utilisateur ou se comporter d'une autre manière dépendante du système. L'absence d'un nom d'une copie locale et une réponseNAMNFDdu serveur étaient des conditions liées, pas nécessairement des événements identiques.

La RFC 811 décrivait sa base de données comme une extension de l'ancien fichierHOSTS.TXTd'ARPANET et qualifiait l'administration centrale de solution provisoire sur la voie d'un service de traduction nom-adresse décentralisé et distribué. Cette affirmation institutionnelle est importante pour deux raisons. Elle montre que le SRI comprenait le service comme un mécanisme de transition plutôt que comme une architecture permanente, et elle confirme que la population et le but de la table s'étaient étendus au-delà de la liste ARPANET d'origine. Elle ne prouve pas indépendamment une couverture universelle.

Au début des années 1980, le NIC était de plus en plus associé à l'environnement du Réseau de Données de la Défense, et les collections historiques utilisent plus tard le nom DDN-NIC pour le service. Cette étiquette ultérieure ne doit pas être reportée en arrière dans le contrat de 1969 ou le débat sur les noms d'hôte de 1971. SRI-ARC, le SRI NIC, SRI-NIC et DDN-NIC décrivent des contextes organisationnels et d'hôtes connectés mais temporellement distincts.

Ce que les archives peuvent montrer — et ce qui reste manquant

La série des RFC est exceptionnellement riche en propositions, spécifications et annonces. Elle est beaucoup plus faible en tant qu'enregistrement de cas administratifs individuels.

L'instrument de recherche du Computer History Museum identifie des collections pertinentes: propositions et contrats du NIC, rapports d'avancement, enregistrements de nommage et d'adressage, tables d'hôtes, documentation de service de référence, correspondance et enregistrements concernant les contacts officiels du réseau. Il indique que le premier contrat du NIC n'était pas décomposé en tâches et que les contrats ultérieurs sont devenus plus élaborés. Il décrit également les agents de liaison techniques, les administrateurs d'hôtes, les coordinateurs de site de nœud et d'autres contacts par lesquels les messages d'information ou d'action transitaient.

Un instrument de recherche établit l'existence, le sujet approximatif et le classement des enregistrements. Il ne divulgue pas le contenu de chaque contrat, lettre ou décision. Ses descriptions ne peuvent pas prouver qu'une demande de nom d'hôte a été accordée, refusée ou escaladée d'une manière particulière. Les documents sous-jacents devraient être ouverts et comparés.

Aucun dossier de demande complet n'a été produit ici montrant le nom proposé d'un hôte, les questions du NIC, la réponse du site et la décision finale. Aucun cas conservé ne démontre un refus du NIC sur la base d'un doublon, un appel réussi, une dérogation de sponsor ou un recours en correction. Aucun registre complet ne fournit les temps de traitement ou les taux d'erreur. Les coordonnées de la RFC 627 prouvent qu'un canal de correction existait; elles ne prouvent pas les résultats obtenus par son intermédiaire.

Les contrats manquants importent pour une raison distincte. Un contrat fédéral peut conférer un droit à la performance sans conférer la propriété de chaque enregistrement, le titre de propriété d'un système technique ou des droits illimités sur les données créées par le contractant. Il peut spécifier les livrables, les licences de données, l'assistance à la transition et les recours, mais ces conséquences dépendent de ses clauses réelles.

Uneanalyse du Government Accountability Office sur les arrangements des fonctions Internet fédéralesbeaucoup plus tardive a soigneusement distingué les droits de performance, les droits d'utilisation des données, le titre de propriété et la propriété. Cet avis de 2016 concernait les arrangements DNS et IANA ultérieurs et ne fournit pas les termes manquants des contrats du SRI des années 1970. Sa valeur ici est méthodologique. Le financement fédéral seul ne peut pas être utilisé pour inférer chaque propriété ou droit de transition.

Le Rapport d'Achèvement soutient une conclusion plus étroite: la DCA avait initialement l'intention de conserver le SRI pour la fonction du NIC et pouvait plus tard utiliser un autre contractant. Cela montre la possibilité de remplacement du fournisseur envisagée. Cela n'établit pas que le remplacement pouvait se produire sans délai, litiges sur les données, conversion de logiciels, perte de mémoire institutionnelle ou interruption de service.

Les enregistrements de mise en œuvre sont également absents pour la condition de trafic de la RFC 810. Pour passer d'une règle publiée à une application démontrée, on voudrait des directives de la DCA, des logiciels hôtes, des journaux d'audit, des rapports d'incident, des sanctions ou un flux bloqué documenté. Sans ce matériel, l'article peut identifier la portée déclarée de la règle mais pas sa force observée.

Le silence doit opérer dans les deux sens. L'absence de procédure d'appel publiée ne prouve pas qu'aucune escalade informelle n'existait. Les appels téléphoniques, le courrier réseau, les échanges NLS et l'intervention des sponsors peuvent avoir résolu des différends sans RFC. Inversement, l'absence de plaintes publiées ne prouve pas que chaque entité considérait le processus comme légitime ou que chaque mise à jour était opportune.

L'incertitude qui en résulte est institutionnelle plutôt que simplement antiquaire. Si les demandes étaient régulièrement corrigées par une confirmation transparente du site, le service paraîtrait plus clérical et coopératif. Si le NIC pouvait refuser des entrées sans explication et qu'aucune révision de sponsor n'existait, le même fichier porterait une signification de gouvernance différente. Les preuves publiques ne soutiennent ni l'un ni l'autre extrême en tant que compte rendu général.

L'alternative de la liste locale et ses coûts réels

Une alternative historiquement réalisable au fichier commun n'était pas le système de noms de domaine moderne. C'était la pratique déjà visible avant la RFC 606: chaque site maintenait ses propres correspondances, obtenait les changements par communication personnelle et traduisait les informations distantes dans son propre système d'exploitation.

À quatre sites, cela pouvait être gérable. Les administrateurs se connaissaient, les concepteurs de protocoles se réunissaient régulièrement, et une correction pouvait circuler par téléphone, document ou courrier réseau. Un site pouvait adopter un alias local sans attendre une publication centrale. Si deux organisations communiquaient fréquemment, elles pouvaient maintenir leurs informations partagées à jour même lorsqu'une machine centrale était indisponible.

La charge de maintenance augmentait rapidement. Avec dix sites, chacun maintenant des entrées pour les neuf autres, il pouvait y avoir jusqu'à 90 correspondances locales dirigées. Avec cent sites, il pouvait y en avoir jusqu'à 9 900. Ces chiffres décrivent des copies dirigées détenues sur les sites, et non 90 ou 9 900 relations bilatérales distinctes. Le nombre de correspondances effectivement nécessaires dépendrait des modèles de communication, mais chaque nouvelle destination créait plus d'endroits où les informations pouvaient devenir obsolètes.

Un ajout ou un changement d'adresse d'hôte devrait atteindre plusieurs administrateurs. Chacun l'appliquerait selon un calendrier distinct et dans un format local. Une correction pouvait être accusée réception par un site, manquée par un autre et transformée incorrectement par un troisième. Les opérateurs devraient identifier l'édition qu'ils avaient, comparer les rapports contradictoires et déterminer si une défaillance de service apparente provenait du réseau, de l'hôte distant ou d'une correspondance obsolète.

La RFC 606 fournit l'avertissement observé: les quatre systèmes TENEX nommés avaient déjà des tables incomplètes et divergentes. Elle ne quantifie pas les échecs causés par ces différences. La divergence elle-même démontre une maintenance dupliquée et des réponses incohérentes.

Une source commune réduisait cette charge. L'hôte affecté pouvait communiquer des informations par un canal reconnu. Le SRI pouvait générer une édition unique. Les sites pouvaient récupérer le même fichier et comparer leur état local avec une référence datée. Un opérateur de support enquêtant sur une anomalie avait un point focal à partir duquel commencer.

Le fichier commun ne supprimait pas tous les coûts de distribution. Chaque site nécessitait toujours du stockage, un logiciel de récupération, une conversion locale et une routine de mise à jour. La publication hebdomadaire introduisait un délai entre un changement signalé et son apparition dans l'édition suivante. La récupération pouvait échouer lorsque l'hôte servant ou un chemin réseau était indisponible. L'installation locale pouvait prendre du retard après une récupération réussie. L'architecture centralisait la compilation, pas toutes les tâches opérationnelles.

Une source commune ne garantissait pas non plus la vérité. Le SRI dépendait des hôtes et des contacts pour fournir des informations exactes. Une adresse erronée fournie par un site pouvait entrer dans le maître. Une mise à jour centrale correcte pouvait être minée par un déploiement local obsolète. Un conflit pouvait persister si la procédure pour le trancher n'était pas claire. La référence rendait le désaccord visible et réduisait la duplication, mais elle n'abolissait pas le besoin de vérification.

L'alternative de la liste locale explique pourquoi les organisations s'en remettaient au fichier du NIC sans nécessiter une théorie de commandement illimité. Une réponse maintenue unique était moins coûteuse à consommer que de nombreuses réponses reconstruites indépendamment. Les logiciels et la documentation devenaient plus fiables lorsqu'ils utilisaient des noms communs. La dépendance qui en résultait donnait au registre maintenu une force opérationnelle.

Un registre commun avec plus d'un distributeur

Une deuxième alternative réalisable à l'époque aurait préservé un fichier canonique unique tout en distribuant le stockage et la récupération plus largement.

L'idée apparaissait dans des documents contemporains. LaRFC 623proposait que le NIC conserve le maître tandis qu'un autre hôte maintienne une copie secondaire fréquemment mise à jour. Son auteur s'est porté volontaire pour l'UCSB et a suggéré une synchronisation quotidienne. Le but était la disponibilité: si l'hôte du NIC ne pouvait pas servir le fichier, les utilisateurs pourraient essayer le secondaire.

LaRFC 625a accepté le principe que plus d'un hôte devait maintenir une copie et a accueilli l'UCSB comme secondaire potentiel. Elle était en désaccord avec le remplacement de FTP par un protocole de récupération dédié. La RFC 627, publiée plus tard en mars, invitait encore tout hôte souhaitant maintenir une copie secondaire à contacter le NIC.

Ces enregistrements établissent une conception de réplication proposée et acceptée. Ils ne prouvent pas que l'UCSB ou un autre hôte a exploité un miroir fonctionnel. La confirmation nécessiterait un avis opérationnel, un journal de serveur, un fichier secondaire archivé, un manuel d'hôte ou un rapport ultérieur. La proposition ne doit pas être réécrite comme un déploiement.

Si un tel secondaire avait fonctionné, il aurait nécessité des ressources appropriées à l'époque. Le site avait besoin de stockage pour le fichier, de personnel ou de procédures automatisées pour récupérer les mises à jour, et d'un calendrier assez fréquent pour garder son édition utile. Les utilisateurs devaient savoir quel hôte contacter et comment reconnaître la dernière version canonique. Le secondaire avait besoin d'une règle pour savoir quoi faire lorsque sa copie locale différait de celle du SRI.

Une panne pouvait rendre la réconciliation difficile. Supposons que le secondaire manque deux mises à jour alors que le SRI restait disponible, puis revienne avec une édition plus ancienne. Une convention d'horodatage ou de séquence serait nécessaire pour empêcher les utilisateurs de confondre disponibilité et actualité. Si le SRI était indisponible pendant qu'une correction contestée arrivait, le secondaire devrait savoir s'il pouvait publier le changement ou simplement continuer à servir le dernier maître confirmé.

La réplication laissait également l'autorité de modification non résolue. Un miroir pouvait distribuer le fichier canonique sans décider des entrées. Lui donner un pouvoir d'édition indépendant créerait la possibilité de maîtres concurrents. Éviter ce problème nécessitait une division claire entre l'organisation attestant de ses faits, le centre réconciliant l'espace de noms partagé, le distributeur servant des copies et tout examinateur traitant les litiges.

La confirmation du site aurait pu être renforcée sans infrastructure moderne. Avant la publication hebdomadaire, le NIC aurait pu envoyer un changement proposé à l'agent de liaison concerné ou au contact autorisé du site. Un avis de changement daté aurait pu accompagner le fichier généré. Les gardiens secondaires pourraient comparer les changements annoncés avec le fichier qu'ils recevaient. Les sites pourraient signaler les anomalies par rapport à une édition spécifique plutôt qu'à une copie locale non datée.

Ces procédures auraient imposé des coûts. Les contacts devaient répondre. Les corrections pouvaient attendre une confirmation. Le personnel devait tenir des journaux et réconcilier les demandes sans réponse. Un hôte qui changeait rapidement pourrait trouver un cycle hebdomadaire trop lent, tandis qu'une distribution plus fréquente augmentait le calcul, l'utilisation du réseau et la charge de travail de l'opérateur. Un examen formel pourrait améliorer la responsabilité tout en retardant les corrections urgentes.

Le changement de contractant présentait un problème plus important. La capacité de la DCA à sélectionner un autre fournisseur ne garantissait pas le remplacement sans heurts du SRI. Un successeur avait besoin du fichier canonique actuel, du logiciel qui le générait, de la documentation des formats et des calendriers de publication, des demandes en cours, de l'historique des corrections, des listes de contacts, des connaissances du personnel et de l'accès à l'environnement de service. Si le contrat ne spécifiait pas la livraison ou les droits d'utilisation des données, le transfert pouvait devenir juridiquement aussi bien qu'opérationnellement difficile.

Les documents publics survivants n'établissent pas si ces matériels de transition existaient en tant que livrables exécutoires. Ils montrent qu'un autre contractant était envisagé, pas qu'un mécanisme de transfert testé était en place. La possibilité de remplacement sur le papier et la continuité dans le fonctionnement étaient des réalisations distinctes.

Cette alternative clarifie le choix de gouvernance. Une réponse logique unique ne nécessitait pas un distributeur physique unique. Une édition canonique pouvait coexister avec des miroirs, une confirmation de site, des modifications conservées et un fournisseur de services de remplacement. Chaque ajout aurait déplacé les coûts et les responsabilités sans éliminer le besoin de coordination finale.

Une chaîne d'autorité datée, pas un mandat universel

Entre 1969 et 1983, l'autorité de la table d'hôte s'est accumulée à travers une série de relations différentes.

En 1969, l'ARPA a financé un Network Information Center pour ARPANET. Cela établissait un client fédéral, un contractant SRI et une population de service définie. Cela ne faisait pas du SRI le représentant de chaque réseau informatique.

En 1971, les hôtes ont été invités à choisir des noms par l'intermédiaire des agents de liaison dans le cadre de conventions publiées. Le débat et la réponse parmi les entités d'ARPANET ont fourni une acceptation par les pairs délimitée. Le rôle proposé du NIC a été restreint par le choix local, tandis que l'espace de noms partagé exigeait toujours des résultats compatibles.

En 1973 et au début de 1974, des tables locales divergentes ont conduit à un fichier commun lisible par machine. Les RFC 606 et 608 ont documenté la proposition et la conception de la source. Les RFC 620 et 627 ont documenté une instruction spécifique de changement à l'échelle du site, le fichier ASCII disponible, les mises à jour hebdomadaires, la responsabilité de récupération locale et les canaux de correction. Elles n'ont pas documenté un veto général du NIC ou un système de règlement des différends complet.

Le 1er juillet 1975, selon le mémorandum ARPA-DCA décrit dans le Rapport d'Achèvement, la gestion d'ARPANET a été transférée à la DCA, suivie d'une phase de transition jusqu'au 31 décembre. La DCA a initialement conservé le SRI pour les fonctions du NIC et pouvait envisager un autre contractant. La déclaration contradictoire de transfert opérationnel de 1973 de l'instrument de recherche et le compte rendu de financement postérieur à 1974 restent non résolus.

En 1978, le cadre des abonnés de la DCA plaçait l'admission à ARPANET dans la gestion du réseau gouvernemental plutôt que dans la maintenance de la table d'hôte du SRI. Cela séparait l'autorité d'admettre un abonné du service qui enregistrait et distribuait les informations sur les hôtes.

En 1981, l'environnement des numéros attribués énumérait de nombreux réseaux au-delà d'ARPANET, tandis que l'attribution des numéros de réseau était identifiée avec Postel à l'USC-ISI. L'apparition dans cette liste n'établissait pas que chaque réseau partageait une relation juridique ou opérationnelle unique avec la DCA ou le NIC.

En mars 1982, la RFC 810 spécifiait une table d'hôte plus large pour l'Internet du DoD et publiait l'enregistrement préalable comme condition pour les noms et adresses utilisés en relation avec le trafic acheminé par les hôtes du DoD. Son traitement intérimaire distinct des informations non-DoD marquait une frontière. La règle était explicite; son application reste non prouvée. Le basculement de mai à août a en outre montré que la spécification, la transition et la mise en œuvre locale achevée étaient des étapes différentes.

Le serveur de la RFC 811 rendait la réponse maintenue disponible par des requêtes en ligne et décrivait la base de données centrale comme un pont provisoire vers une dénomination distribuée. Ce service augmentait la dépendance à SRI-NIC tout en reconnaissant que l'architecture n'était pas destinée à rester centralisée en permanence.

La table d'hôte exerçait donc son autorité démontrée la plus forte en trois endroits. Le SRI devait la performance à son client fédéral dans le cadre d'un contrat dont les termes complets ne sont pas disponibles. La DCA pouvait émettre des exigences opérationnelles pour l'environnement du DoD qu'elle gérait. Les machines et utilisateurs entités dépendaient du registre commun pour une communication cohérente basée sur les noms.

En dehors de ces relations, la portée de la table résultait de l'interopérabilité et de l'adoption. Un réseau extérieur pouvait contribuer des informations ou utiliser le fichier commun parce que cela rendait la communication plus facile. Cette dépendance était conséquente, mais la RFC 810 ne la décrivait pas comme équivalente à la condition préalable du DoD. Aucun enregistrement examiné ne montre une circonscription mondiale déléguant une autorité générale au SRI.

La table n'a pas non plus créé tout ce qu'elle enregistrait. Le sponsor approuvait la participation au réseau; les contractants et les sites fournissaient les machines et les logiciels; les circuits et les commutateurs de paquets transportaient le trafic; d'autres autorités géraient les numéros de réseau; les systèmes locaux consommaient les correspondances publiées. L'enregistrement du NIC aidait à rendre un nom communément reconnaissable, mais il ne créait pas l'organisation sous-jacente, la connexion physique ou chaque attribution numérique.

Son autorité pratique était néanmoins substantielle. Un enregistrement partagé consommé par de nombreuses machines peut contraindre la conduite même si aucune législature ni organisme public n'en est membre. Un hôte souhaitant une reconnaissance prévisible avait intérêt à suivre les conventions de nommage. Un site souhaitant des réponses à jour avait intérêt à récupérer le fichier commun. Un hôte du DoD était visé par une condition préalable d'enregistrement publiée. Un opérateur non-DoD pouvait trouver la déviation coûteuse parce que d'autres systèmes attendaient la réponse maintenue.

Ce qui reste non prouvé est tout aussi important. Les preuves publiques survivantes ne montrent pas que le NIC possédait les adresses qu'il listait, pouvait exclure un réseau extérieur à volonté, imposait des sanctions à chaque site non conforme ou convertissait chaque entrée manquante en déconnexion physique. Elles ne révèlent pas une structure d'appel complète, un recours en correction ou une hiérarchie de dérogation. Elles n'établissent pas la propriété gouvernementale portable de toutes les données du NIC.

La première table d'hôte faisait autorité là où les achats, la gestion du réseau et la dépendance des machines se rencontraient. Elle résolvait un problème concret: des correspondances locales incompatibles rendaient les noms partagés peu fiables. La compilation centrale rendait une réponse plus facile à distribuer, comparer et utiliser. Cette réalisation explique pourquoi l'enregistrement a acquis de la force avant que les noms et adresses ne deviennent des actifs de marché.

Elle ne prouve pas que l'opérateur de l'enregistrement a reçu une autorité sur chaque réseau que l'enregistrement pouvait décrire. La chaîne historique soutient une conclusion plus étroite: le SRI maintenait une référence commandée par le gouvernement fédéral pour un réseau parrainé, cette référence est devenue intégrée aux opérations de l'Internet du DoD, et une dépendance plus large a étendu sa portée pratique. L'utilité du registre l'a rendu puissant. Son mandat public est resté non établi.