Le jour du drapeau qui a changé l'autorité: gouvernance après la migration TCP/IP

Résumé

• La transition de janvier 1983 a été substantielle mais inégale: les mesures de février ont trouvé des centaines de points de terminaison de service TCP, mais les résultats différaient selon le service, la population d'adresses, la date du test et le chemin réseau, et ils ne décrivaient pas une population universelle basculant à minuit.
• Le levier du sponsor et de l'opérateur a été exercé par le rejet au niveau IMP du trafic NCP, les décisions d'exception du DDN-PMO et l'activation d'hôtes ou de ports; la dépendance envers les enregistrements du SRI-NIC et la coordination des numéros par l'USC/ISI s'est accrue opérationnellement sans preuve que la migration ait accordé à l'un ou l'autre bureau une nouvelle autorité discrétionnaire.
• Le processus d'exception était réel mais partiel plutôt qu'indépendant: les administrateurs pouvaient soumettre des réclamations, une liste publique enregistrait l'activation temporaire du NCP et les dates d'expiration, et les relais TAC et UDEL préservaient une accessibilité limitée, mais les raisons publiées, les dossiers de décision complets et l'examen en dehors du DDN-PMO étaient absents.

Le 1er février 1983, un mois après l'objectif de l'ARPANET de conversion du NCP vers TCP/IP, un test depuis ISI-VAXA a tenté de se connecter à chaque adresse d'une table d'hôtes récente du Network Information Center. Le résultat n'était pas un réseau proprement divisé entre un passé et un futur. C'était un rapport à largeur fixe rempli de connexions acceptées, de refus, d'adresses inaccessibles, de systèmes morts et de champs de résultats vides.

La liste d'hôtes avait été extraite de la table NIC datée du 28 janvier. Les tests ont été exécutés depuis ISI-VAXA les 1er et 2 février, les entrées mortes, inaccessibles et refusantes étant réessayées le 3 février. L'enquête a tenté trois services TCP: Telnet, FTP et SMTP. Elle n'a pas inspecté les logiciels, n'a pas testé toutes les fonctions TCP ou IP, n'a pas prouvé qu'un hôte était disponible en continu et n'a pas énuméré tous les ordinateurs connectés aux réseaux entités. Elle a enregistré ce qui se passait lorsqu'une origine essayait des ports de service particuliers pendant des périodes particulières.

Le dénominateur dansRFC 842, « Who Talks TCP? »était de 328 lignes d'adresse. Parmi celles-ci, 200 commençaient par le numéro de réseau 10, l'espace d'adressage de l'ARPANET, et 128 appartenaient à d'autres réseaux. Une ligne n'était pas nécessairement un ordinateur physique, une institution, un abonné DDN ou une organisation unique. Un système nommé pouvait apparaître à plus d'une adresse; les passerelles et autres entrées opérationnelles pouvaient également figurer dans la table. Inversement, un système non enregistré, déconnecté, classifié ou omis était en dehors de la population mesurée.

Un recomptage direct des lignes de résultat de la RFC 842 produit l'audit suivant. Le résultataccepted+de FTP est inclus dans accepté. Une indication mort ou inaccessible couvrant les colonnes de service est comptée dans cet état pour chaque service.

Ces catégories décrivent des observations, non des explications. Une entrée morte aurait pu avoir un logiciel TCP pleinement fonctionnel sur une machine qui était hors tension. Une adresse inaccessible pourrait indiquer un problème de passerelle, de routage, d'adressage ou de mesure. Un refus pourrait signifier que les paquets atteignaient un point de terminaison TCP mais que l'application n'acceptait pas la session demandée. Un résultat vide ne révèle pas si l'échec provenait de l'hôte, du chemin, du service ou de la table. L'acceptation sur un port ne prouve pas une conformité totale avec TCP, IP, ICMP, le routage, la gestion des noms et les applications principales.

La table d'hôtes n'était pas non plus un recensement de la conformité à l'objectif de janvier du sponsor. Ses 128 lignes non-réseau-10 incluaient des systèmes sur des réseaux exploités indépendamment, de recherche, locaux, étrangers, par radio-paquets, par satellite et autres. Leur apparition démontrait une participation à un environnement internet grandissant. Elle ne montrait pas que la Defense Communications Agency pouvait ordonner à tous leurs opérateurs de migrer.

Le « jour du drapeau » du titre est donc une étiquette rétrospective, non le langage ordinaire des archives opérationnelles. Les avis contemporains parlaient d'un basculement, d'une conversion ou d'une expérience TCP uniquement. En 1997, une histoire de l'Internet Society écrite par plusieurs entités de premier plan a décrit l'événement comme unetransition de type « jour du drapeau ». Ce récit ultérieur a saisi la force coordinatrice de l'échéance, mais a compressé la mise en œuvre inégale que les tables de février ont préservée.

La conversion était néanmoins conséquente. C'était une décision soutenue par le sponsor de cesser de considérer la coexistence NCP/TCP comme l'avenir normal de l'ARPANET. Son importance ne réside pas dans une transformation mythique à minuit, mais dans les mécanismes qui ont rendu l'objectif crédible: des tests qui désactivaient le NCP dans le réseau de commutation, un processus d'exception administré par l'opérateur, un support temporaire par relais et terminaux, l'approbation des hôtes et des ports, et une dépendance croissante envers des enregistrements partagés précis.

1er–18 février 1983: des observations changeantes n'étaient pas une courbe d'adoption

Une deuxième enquête illustre pourquoi les totaux agrégés ne peuvent pas être convertis à la légère en un récit d'adoption régulière.

RFC 843a utilisé la table d'hôtes NIC datée du 3 février et a testé depuis ISI-VAXA les 8 et 9 février. Sa population était passée de 328 à 329 lignes. Les nombres totaux acceptés étaient de 187 pour Telnet, 174 pour FTP et 170 pour SMTP, contre 183, 170 et 169 dans le rapport précédent. Mais les groupes réseau-10 et non-réseau-10 ont évolué dans des directions opposées.

Les comptes réseau-10 acceptés ont augmenté pour les trois services. Les comptes des autres réseaux ont baissé pour les trois. La table sous-jacente a également changé d'une ligne, et des machines individuelles pouvaient être en marche pendant un test et indisponibles pendant un autre. Sans une analyse par entrées appariées contrôlant les ajouts, les suppressions, les défaillances temporaires et les chemins modifiés, les deux enquêtes montrent des observations changeantes plutôt qu'un taux d'adoption mesuré.

Dix jours plus tard, laRFC 844a posé une question différente. Elle a sélectionné les 187 entrées qui avaient accepté Telnet dans la RFC 843 et a essayé de les atteindre depuis un concentrateur de terminaux sur le réseau de classe C 192.1.2 chez BBN. Le succès nécessitait plus qu'un service Telnet acceptant le long du chemin précédent: les paquets et les réponses devaient fonctionner à travers le routage de passerelle, l'adressage de classe C et le comportement ICMP pertinent.

Les connexions étaient saisies manuellement par adresse en pointillés, et seulement trois passes ont été effectuées. Un hôte indisponible pendant ces passes pouvait être manqué. Les résultats ont néanmoins exposé à quel point un succès TCP apparent dépendait de l'origine du test et du chemin réseau.

L'agrégat 127 sur 187 ne peut pas étayer une simple affirmation selon laquelle les réseaux externes étaient à la traîne par rapport à l'ARPANET. Le groupe non classe A avait le taux observé le plus élevé, 30 sur 32. Le test n'établit pas non plus que chaque entrée non réussie manquait de support de classe C ou ICMP; la disponibilité temporaire et les conditions de chemin restaient non résolues.

Ensemble, les trois rapports établissent un fait plus restreint mais précieux. Un mois après l'objectif, des centaines de lignes de table acceptaient les principaux services TCP, tandis que la capacité enregistrée, la disponibilité des applications et l'accessibilité depuis différentes origines restaient inégales. La conversion avait produit une opération substantielle, pas une uniformité instantanée.

C'est la première frontière de gouvernance. La mesure rendait la mise en œuvre visible, mais la mesure ne décidait pas pourquoi un hôte échouait ni quel remède devait suivre. Ces décisions appartenaient aux administrateurs d'hôtes, aux implémenteurs, aux opérateurs de passerelles et de commutation, au NIC, au DDN Program Management Office, aux sponsors de recherche et, en dehors de la population contrôlée par le sponsor, aux opérateurs de réseaux autonomes.

Novembre 1981: le plan était conçu pour mettre fin à la médiation

L'objectif opérationnel a débuté comme un plan par étapes, non comme une affirmation que des centaines de machines pouvaient changer en une fois.

RFC 801, publiée en novembre 1981, a fixé le 1er janvier 1983 comme objectif pour un changement complet de l'ARPANET du NCP vers IP et TCP. Elle demandait à chaque organisation hôte de commencer à implémenter IP/TCP avant le 1er janvier 1982 et attribuait la même responsabilité locale pour Telnet, le transfert de fichiers et le courrier. Les nouveaux hôtes ARPANET devaient démarrer avec TCP/IP plutôt que d'entrer via NCP.

Les jalons du plan révèlent sa conception réelle. Des hôtes capables de TCP et TCP uniquement existaient déjà. On s'attendait à ce que les services de relais fassent le pont entre les hôtes incompatibles. La dernière conversion de NCP uniquement devait commencer en janvier 1982; la plupart des hôtes devaient être capables de TCP d'ici juillet; la conversion finale devait s'achever en novembre. Ce n'est qu'alors que janvier 1983 apporterait un service complet basé sur TCP, la suppression du NCP et la fin du support normal des relais.

La mise en œuvre restait distribuée. Les organisations hôtes de l'ARPANET contrôlaient des machines avec différents processeurs, systèmes d'exploitation, personnels, sources logicielles et exigences de service locales. Le sponsor pouvait annoncer une échéance et financer des implémentations, mais il ne pouvait pas rendre correcte une routine de somme de contrôle défectueuse par décret. Un hôte pouvait avoir IP et TCP tout en manquant de SMTP. Un système qui fonctionnait à travers une passerelle pouvait mal gérer une autre route, des options, la fragmentation ou ICMP. La RFC 801 elle-même mettait en garde contre les implémentations qui sautaient les sommes de contrôle, ne parvenaient pas à réassembler les fragments, s'appuyaient sur des données de routage limitées, ignoraient les options, réordonnaient incorrectement les données TCP ou maintenaient des tables de noms statiques.

Ce que l'objectif pouvait faire, c'était changer le coût du retard. Une organisation hôte pouvait conserver le logiciel NCP sur son propre ordinateur, mais elle ne pouvait pas obliger l'opérateur de l'ARPANET à acheminer indéfiniment le trafic NCP. Une fois que le réseau de commutation rejetait l'ancien trafic et que les relais ordinaires prenaient fin, une mise en œuvre locale inachevée devenait un problème d'accessibilité pour l'hôte et ses utilisateurs.

La RFC 801 modélisait pourquoi une coexistence prolongée n'était pas attrayante. Les terminaux NCP uniquement et TCP uniquement ne pouvaient pas communiquer directement, de sorte que les hôtes relais à double protocole devaient assurer la médiation de Telnet, FTP et du courrier. Telnet impliquait un compte intermédiaire et une seconde connexion. FTP pouvait nécessiter de déplacer un fichier sur le stockage du relais, puis de le transférer à nouveau. Le courrier nécessitait une logique de transfert et un adressage tenant compte du protocole. Chaque relais ajoutait une autre machine qui devait être disponible et un autre service qui nécessitait de la capacité, du contrôle d'accès, de la documentation et du support.

Le modèle numérique de charge de relais du document était explicitement spéculatif, mais son argument institutionnel était solide. La coexistence indéfinie n'était pas une préservation neutre du choix. Quelqu'un devait financer et exploiter la couture entre les deux environnements. Une échéance transférait ce fardeau loin des opérateurs de relais et vers les organisations hôtes qui n'avaient pas achevé leurs conversions.

Le plan seul ne prouve pas que ce transfert a eu lieu. Le dossier d'exécution apparaît dans une source différente: les bulletins d'information opérationnels distribués par le NIC pour le compte de la DCA et de son DDN Program Management Office.

Octobre–décembre 1982: l'application est passée dans les IMP

Le 1er octobre 1982, de midi à 16 heures, heure de l'Est, l'ARPANET a mené une expérience TCP uniquement. Pendant ces quatre heures, il a été demandé aux Interface Message Processors de rejeter les messages d'hôtes utilisant la liaison 0, la liaison associée au trafic hôte-à-hôte NCP. L'IMP renvoyait un statut de type 7, sous-type 3 indiquant que la communication avec la destination était « administrativement interdite ».

Ce mécanisme, décrit dansARPANET News n° 14, est la preuve la plus claire de la contrainte opérationnelle dans la conversion. Le NCP n'était pas simplement déprécié dans un document. L'infrastructure de commutation par paquets refusait le trafic concerné. Les hôtes NCP uniquement ne pouvaient pas utiliser l'ARPANET pendant le test. Les systèmes à double protocole avec un état d'hôte distant partagé pouvaient également rencontrer des problèmes à moins que les administrateurs ne désactivent leur implémentation NCP pendant la période.

Le point d'application importe. Ce n'était pas le SRI-NIC qui supprimait un nom, ni l'USC/ISI qui refusait un numéro. Les IMP effectuaient le rejet sous les instructions de gestion de réseau, avec le Network Operations Center et la direction liée à la DCA responsables de l'environnement d'exploitation. Le statut renvoyé était conçu pour rendre visible la nature administrative du rejet à l'hôte émetteur.

News n° 16 a rappelé aux administrateurs le test du 1er octobre et a demandé aux entités de signaler leurs observations à Jon Postel, au NOC et au NIC. Il a également pressé les sites d'implémenter SMTP et l'adressage Internet à quatre octets d'ici janvier. Ici, la coordination combinait plusieurs fonctions: le réseau de commutation créait la condition de test; les implémenteurs et les administrateurs d'hôtes observaient les défaillances; l'ISI recevait les rapports techniques; le NOC surveillait les opérations; et le NIC diffusait les instructions et collectait les informations de mise en œuvre.

L'expérience de quatre heures a été suivie de répétitions plus longues.News n° 17a annoncé des périodes TCP uniquement de 24 heures le 15 novembre et les 13 et 14 décembre. La même méthode de rejet au niveau IMP serait utilisée. L'avis avertissait explicitement que c'était aussi le mécanisme prévu après l'objectif du 1er janvier.

Ces tests fournissaient des informations qu'aucune affirmation de table d'hôtes ne pouvait fournir. Un site pouvait déclarer qu'il disposait de TCP, tout en découvrant lors d'une journée sans NCP qu'un service de production, un logiciel de courrier, un chemin de terminal, une passerelle ou une procédure d'exploitation locale dépendait encore du NCP. Un hôte pouvait réussir un test de laboratoire mais échouer sous le trafic et le comportement des utilisateurs d'une période opérationnelle complète. Répéter l'expérience augmentait la probabilité que la dépendance soit découverte avant que la politique continue du réseau ne change.

Les tests créaient également un levier. Un hôte contrôlé par le sponsor qui n'avait pas migré ne pouvait pas simplement continuer à utiliser l'ancien protocole pendant le test. Ses utilisateurs subissaient la conséquence de la non-migration, et ses administrateurs recevaient un statut spécifique du réseau. C'était matériellement différent de la persuasion via une RFC.

Pourtant, le levier était limité. Il s'appliquait directement au trafic NCP soumis via les IMP de l'ARPANET. Il n'atteignait pas un réseau local indépendant exploitant NCP en interne, un réseau externe qui n'avait pas rejoint l'Internet ARPA, ou chaque adresse non-réseau-10 listée plus tard dans la RFC 842. Les partenaires de recherche financés par la DARPA pouvaient faire face à des attentes contractuelles ou à de fortes incitations à l'interopérabilité, mais ces relations n'étaient pas identiques au contrôle de la DCA sur les opérations de l'ARPANET.

La même distinction limite les affirmations concernant l'enregistrement. Les tests prouvent que l'opérateur pouvait désactiver un protocole au niveau de la commutation. Ils ne prouvent pas que la migration a donné au NIC un nouveau pouvoir discrétionnaire sur les noms ou à l'USC/ISI un nouveau pouvoir sur l'attribution des numéros. Ces fonctions administratives importaient pour l'interopérabilité, mais l'acte de contrainte observé s'est produit ailleurs.

Janvier 1983: les exceptions étaient publiques, mais seulement en partie

La politique opérationnelle ne consistait pas en une échéance sans possibilité de report.

Daté du 22 décembre 1982,ARPANET News n° 19indiquait qu'après 00h01, heure de l'Est, le 1er janvier, l'utilisation du NCP ne serait pas autorisée sans une exception spécifique du DDN Program Management Office. Il donnait un nom à la demande d'exception—reclama—et précisait comment la soumettre.

Avant janvier, une demande pouvait voyager par courrier réseau vers les adresses DDN-PMO, avec des copies au NIC. Après l'échéance, un administrateur incapable d'utiliser le réseau pouvait envoyer la demande par courrier postal américain au siège de la DCA. Cette voie hors ligne était opérationnellement significative: la politique ne supposait pas que quelqu'un cherchant à rétablir l'accès NCP posséderait encore un accès réseau fonctionnel.

Le demandeur devait fournir une justification détaillée, un calendrier de conversion, la source de l'implémentation TCP/IP prévue si connue, et une liste des hôtes avec lesquels l'interopérabilité était requise. Des contacts nommés du DDN-PMO étaient fournis pour plus d'informations. Il s'agissait d'un processus de demande documenté avec une autorité décisionnelle identifiée et des exigences informationnelles énoncées.

News n° 20, distribué le 13 janvier, a ensuite publié une table des adresses activées NCP et des dates de conversion prévues. Un comptage direct donne 44 lignes d'adresse ou de port. Il ne s'agissait pas de 44 organisations indépendantes. Plusieurs institutions avaient plusieurs adresses d'hôte physiques ou logiques; deux lignes étaient étiquetées ports de test; une autre identifiait la passerelle S1. Une ligne avait une date de basculement inconnue. Les lignes datées allaient du 16 janvier au 1er mai, bien que 25 aient été assignées au 1er février.

L'ancienne notation abrégée réseau-10 renforce ce que la table représentait: des entrées d'adresse ou de port opérationnelles dans l'environnement ARPANET. Ce n'était pas une liste d'entités juridiques, de contrats, de sites ou de décideurs humains uniques. Ce n'était pas non plus un inventaire complet de chaque ordinateur utilisant du NCP résiduel quelque part dans le DDN ou le DoD plus large.

News n° 20 disait que des exemptions avaient été accordées aux sites confrontés à de graves perturbations de service et soulignait que chaque administrateur d'hôte devait demander individuellement l'activation du NCP. Il disait également que les échéances étaient fermes. La table reliait donc une décision administrative à une condition réseau concrète: le maintien de l'activation du NCP pour une adresse spécifiée jusqu'à une date spécifiée.

C'est une preuve plus forte qu'une absence de gouvernance inférée. Il existait un registre public partiel des exceptions. La communauté pouvait voir quelles adresses listées conservaient le NCP et quand la plupart devaient migrer. L'avis de demande divulguait le décideur et le matériel qu'un demandeur devait soumettre. La publication des lignes aidait également les utilisateurs de courrier à déterminer quand un relais pouvait être nécessaire.

Le registre était incomplet à d'autres égards. Il ne donnait pas de raison à côté de chaque adresse. Il ne reproduisait pas les demandes, les preuves à l'appui, les conditions, les refus ou l'analyse derrière les échéances individuelles. Les avis examinés n'identifient pas d'organe d'examen indépendant ni d'appel d'une décision du DDN-PMO. Ils ne révèlent pas si des cas similaires étaient traités de manière cohérente ou si chaque activation temporaire figurait dans la table.

La conclusion institutionnelle précise est donc limitée. La transition ne manquait pas d'une procédure d'exception ni de tout rapport d'état public. Elle avait un décideur opérationnel central, des demandes individuelles, une activation temporaire, des lignes d'adresse publiées et des dates d'expiration. Ce qui manquait dans le dossier public était un dossier de décision complet, un raisonnement par cas et un examen indépendant de l'autorité administrant la politique réseau.

Cette combinaison convenait davantage à un réseau de défense géré qu'à un système constitutionnel public. Le DDN-PMO décidait combien de temps un protocole obsolète pouvait rester actif dans un environnement dont il portait la responsabilité opérationnelle. Les demandeurs étaient des administrateurs d'hôtes cherchant à maintenir le service, non des citoyens revendiquant un droit général d'utiliser n'importe quel protocole. L'importance ultérieure pour la gouvernance découle du fait que l'environnement technique et ses enregistrements partagés se sont étendus au-delà de la population régie par ces relations d'origine.

Janvier–février 1983: les TAC et UDEL ont maintenu la couture en vie

La migration n'a pas éliminé toute médiation le 1er janvier. Elle l'a concentrée dans des installations spécifiques et temporaires.

News n° 20 a annoncé que les ARPANET Terminal Access Controllers continueraient à supporter le NCP pendant le mois de janvier. Un utilisateur de terminal pouvait se connecter via un TAC et entrer une commande supplémentaire pour atteindre un hôte NCP. Le 1er février, les TAC devaient devenir exclusivement TCP/IP.

Cette continuation importait parce que l'accès par terminal était une voie courante vers les hôtes de service. Le terminal propre d'un utilisateur n'implémentait pas une pile de protocoles hôte complète de la même manière qu'un ordinateur connecté. Le TAC assurait la médiation de l'accès du terminal aux hôtes. Maintenir le double support préservait un chemin opérationnel pour les personnes dont les destinations ou les systèmes de support n'avaient pas achevé la conversion.

L'Université du Delaware a fourni un autre pont réel. UDEL a accepté d'exploiter un relais de transfert de courrier entre les utilisateurs TCP et NCP. Un expéditeur TCP s'adressant à une destination NCP utilisait une forme UDEL-RELAY contenant le compte du destinataire et le nom d'hôte NCP. Un expéditeur NCP s'adressant à un destinataire TCP utilisait UDEL-TCP. Le relais pouvait également effectuer une transaction au sein du même protocole lorsque le statut actuel de la destination était incertain.

Il ne s'agissait pas d'une traduction invisible. Les utilisateurs devaient connaître le protocole de l'expéditeur et construire l'adresse en conséquence. Un adressage incorrect pouvait entraîner le retour d'un message. Le relais nécessitait un logiciel de courrier fonctionnel, un hôte joignable, des contacts personnels, de la capacité de file d'attente et de disque, et une connaissance actualisée du statut du protocole de destination. La liste d'exemptions publiée était censée rendre cette dernière dépendance plus facile à gérer.

Ces accommodements révèlent la texture réelle de la conversion. L'application et l'assistance n'étaient pas opposées. L'opérateur pouvait rejeter le trafic NCP ordinaire tout en préservant certaines adresses NCP, en étendant le support TAC et en organisant un relais de courrier. La compatibilité temporaire réduisait les perturbations sans renoncer à l'échéance.

L'arrangement montre aussi pourquoi des enregistrements précis devenaient plus lourds de conséquences opérationnelles. Une entrée de capacité périmée pouvait diriger le courrier vers la mauvaise procédure. Un hôte incorrectement indiqué comme migré pouvait ne plus être joignable par les chemins NCP ordinaires, tandis qu'un hôte migré traité comme NCP uniquement pouvait attirer une utilisation inutile du relais. Les instructions UDEL rendaient le protocole source décisif; la table d'exceptions aidait à identifier les destinations résiduelles; le calendrier TAC indiquait aux utilisateurs quand un chemin de terminal disparaîtrait.

Cette dépendance ne faisait pas du NIC la source de chaque décision. Le DDN-PMO accordait les exceptions NCP. Les opérateurs réseau implémentaient l'activation dans l'environnement de commutation. UDEL gérait le relais de courrier. Les opérateurs TAC fournissaient la compatibilité terminal. Le NIC distribuait le bulletin et la table. Chaque institution contrôlait un maillon différent.

Les relais imposent également une discipline aux affirmations contrefactuelles. Une conversion plus lente était technologiquement possible parce que le service TAC à double protocole et le transfert UDEL existaient en fonctionnement, pas seulement sur le papier. Mais les maintenir nécessitait du personnel, de la capacité hôte, des instructions utilisateur, des contrôles d'accès, du stockage, une connaissance des adresses, du dépannage et des tests continus. Prolonger la coexistence aurait prolongé ces coûts.

Il n'est pas nécessaire d'inventer un incident de sécurité pour établir le fardeau. Les comptes intermédiaires, les fichiers ou messages stockés et les machines de service supplémentaires nécessitaient une administration, qu'une brèche se soit produite ou non. Les sources survivantes n'établissent pas qu'un relais de transition ait causé un tel incident. Elles établissent que la fiabilité des relais, la charge, le contrôle des comptes et le stockage temporaire étaient des préoccupations opérationnelles reconnues.

Les enregistrements sont entrés dans le chemin opérationnel sans devenir une autorité unique

La conversion des protocoles, l'enregistrement des hôtes, l'approbation des ports, l'attribution des numéros et la distribution des informations étaient liés, mais ils ne constituaient pas un pouvoir unique exercé par une seule institution.

La couche de la table d'hôtes était antérieure à la conversion de janvier.RFC 810, publiée en mars 1982, a remplacé l'ancien format de table orienté ARPANET par un format conçu pour l'interconnexion des réseaux du DoD. Le nouveau format décrivait les réseaux, les passerelles, les hôtes, les adresses Internet, les systèmes d'exploitation et les capacités protocolaires. Une ligne pouvait distinguer TCP/Telnet de NCP/Telnet ou enregistrer si SMTP était disponible.

La table pouvait être téléchargée sous le nomHOSTS.TXTdepuis SRI-NIC ou obtenue via le serveur de noms d'hôtes. Des copies locales réduisaient la dépendance à une requête en direct pour chaque connexion, mais elles créaient un problème de cohérence familier: une ancienne copie pouvait conserver une adresse disparue ou une revendication de protocole obsolète. La conversion a augmenté la fréquence à laquelle ces différences importaient parce que les utilisateurs et les applications avaient besoin de connaître non seulement un nom et une adresse, mais aussi l'environnement de communication qu'une destination supportait.

La RFC 810 imposait également une règle formelle dans ses limites énoncées. Les noms et adresses des réseaux, passerelles et hôtes du DoD devaient être négociés et enregistrés auprès du NIC avant utilisation et avant qu'un hôte du DoD n'achemine leur trafic. Pendant une période intérimaire, le NIC essaierait de conserver des informations comparables pour les réseaux non-DoD lorsque les opérateurs les fournissaient.

Ce texte établit une exigence d'enregistrement. Il n'établit pas un cas documenté dans lequel le NIC aurait rejeté un nom contesté, exclu un réseau externe par ailleurs fonctionnel ou acquis un nouveau pouvoir discrétionnaire en raison de l'échéance TCP/IP. L'exigence faisait déjà partie de la spécification de la table d'hôtes de 1982. La conversion a rendu l'exactitude et la portée de l'enregistrement plus importantes; les preuves ne montrent pas qu'elle a créé la règle.

RFC 811décrivait le serveur de noms d'hôtes du NIC comme un service accessible en NCP et TCP exploité au SRI pour le compte de la DCA. Les programmes pouvaient demander un enregistrement par nom, par adresse ou récupérer la table entière. Le protocole définissait les réponses possibles pour un nom ou une adresse introuvable, une commande illégale ou une défaillance temporaire du système.

Ces codes de réponse montrent à quoi les logiciels consommateurs devaient être préparés. Ils ne montrent pas à quelle fréquence ces défaillances se produisaient ni n'identifient un utilisateur qui aurait effectivement perdu le service à cause de l'une d'elles. Un enregistrement manquant pouvait faire échouer une recherche par nom tandis que la communication numérique directe restait possible. Une défaillance temporaire du serveur pouvait être atténuée par une table locale, bien que cette copie puisse être périmée. La RFC présentait la base de données globale unique comme un arrangement intérimaire sur la voie d'un service distribué de correspondance nom-adresse.

Une porte administrative plus directe est apparue dans les avis opérationnels entourant la séparation prévue ARPANET/MILNET. News n° 18, daté du 17 décembre 1982, indiquait qu'un enregistrement précis des hôtes et des ports IMP était nécessaire pour éviter de refuser le service au mauvais utilisateur pendant la scission. BBN avait pour instruction de désactiver les ports inutilisés et de ne les activer qu'après approbation du DDN-PMO. Les nouveaux hôtes et les changements de port devaient être coordonnés à l'avance.

News n° 21 a ensuite révisé la procédure. Les demandes d'approbation de nouvel hôte, d'activation de port ou de changement d'hôte sur un port actif étaient envoyées à une boîte aux lettres au SRI-NIC. Les informations requises comprenaient le nom et l'adresse de l'hôte, l'emplacement, le matériel, le système d'exploitation, le sponsor, les protocoles et les coordonnées de la liaison technique.

Ici, l'exactitude des données et l'activation opérationnelle étaient directement liées. Mais la raison invoquée dans News n° 18 était la scission du réseau et la gestion des ports, et non uniquement la conversion NCP/TCP. L'autorité décisionnelle était le DDN-PMO; BBN contrôlait l'état des ports sous instruction; le NIC recevait, maintenait et diffusait l'information. Traiter les trois comme « le registre » masquerait où résidait réellement le pouvoir.

Les numéros attribués formaient une autre couche distincte.RFC 820, publiée en janvier 1983, enregistrait les valeurs utilisées pour les numéros de réseau, les numéros de protocole, les ports, les sockets et d'autres champs d'implémentation. Elle orientait les demandeurs vers Jon Postel à l'USC/ISI et indiquait que les attributions étaient traitées dans le cadre d'un accord entre le bureau des techniques de traitement de l'information de la DARPA et le DDN-PMO.

Des numéros uniques étaient nécessaires pour éviter des implémentations conflictuelles et une interprétation ambiguë des paquets. Cette nécessité créait une dépendance envers des attributions coordonnées. Le matériel survivant examiné ici ne montre pas un refus lié à la migration, un appel d'une décision d'attribution ou un changement avant-après dans le pouvoir discrétionnaire formel de Postel. La RFC 820 documente une fonction de coordination et son cadre institutionnel; elle ne peut à elle seule prouver que l'événement de janvier a élargi l'autorité de cette fonction.

La distinction entre ces mécanismes est le centre causal de l'histoire:

• Le rejet par les IMP rendait le NCP inutilisable sur le réseau géré, sauf là où il était activé.
• Le DDN-PMO décidait des exceptions temporaires NCP et approuvait l'activation des hôtes ou des ports.
• Les organisations hôtes implémentaient et exploitaient leurs propres logiciels de protocole.
• Le SRI-NIC enregistrait et distribuait les noms, adresses, capacités, contacts et avis.
• L'USC/ISI coordonnait les numéros attribués des protocoles et des réseaux.
• Les opérateurs de passerelles et de relais déterminaient si le trafic pouvait franchir des frontières techniques particulières.
• Les opérateurs externes adoptaient TCP/IP dans le cadre d'accords de financement, de coopération en recherche, de règles d'approvisionnement ou d'incitations à l'interopérabilité qui n'étaient pas toutes des ordres de la DCA.

La migration a accru la dépendance tout au long de cette chaîne. Elle n'a pas fusionné la chaîne en un seul bureau.

1972–1985: la frontière institutionnelle s'est déplacée sous le réseau

Même la chronologie de base met en garde contre la description d'une autorité centrale continue.

Lachronologie officielle de la DARPAdate le changement de nom de l'ARPA en Defense Advanced Research Projects Agency en 1972, et non en 1973. La DARPA est restée le sponsor de recherche derrière les travaux clés sur les protocoles et l'implémentation, avec un levier substantiel sur ses contractants et partenaires financés.

La date à laquelle la DCA a assumé la responsabilité opérationnelle de l'ARPANET est moins nette. Leguide des archives SRI ARC/NICde 2011 indique que l'exploitation a été transférée à la DCA en 1973. Une publication contemporaine de la DCA donne une date formelle ultérieure: labrochure d'information sur l'ARPANETde 1978 de l'agence indique que la responsabilité de gestion a été transférée le 1er juillet 1975.

Sans les dossiers sous-jacents du transfert progressif, ces déclarations ne doivent pas être forcées en une fausse certitude. L'instrument de recherche ultérieur décrit peut-être un transfert opérationnel antérieur, tandis que la propre brochure de la DCA identifie le transfert formel de la responsabilité de gestion. Pour la date formelle, le récit contemporain de la DCA est plus solide. En 1982, les avis en direct eux-mêmes ne laissent aucune ambiguïté sur la hiérarchie opérationnelle: ils étaient distribués par le NIC pour le DDN Program Management Office de la DCA, et les instructions de gestion de réseau émanaient de cette structure.

En janvier 1983, au moins cinq populations devaient être tenues séparées.

La population réseau-10 de l'ARPANET était le sujet direct du plan NCP/TCP de la RFC 801 et des tests TCP uniquement au niveau IMP. Le contrôle opérationnel de la DCA et les décisions d'exception du DDN-PMO y avaient leur force la plus claire.

MILNET et les autres abonnés du DDN appartenaient à un environnement de défense plus vaste encore en cours d'assemblage et de différenciation. Leurs obligations protocolaires n'étaient pas réductibles à chaque ligne du plan ARPANET. Le rapport du National Research Council de 1985 reproduit sous le nom deRFC 942indiquait que le backbone MILNET n'exigeait pas lui-même TCP, bien que les abonnés soient généralement tenus de l'utiliser.

D'autres réseaux du DoD suivaient des voies techniques et d'approvisionnement différentes. La RFC 942 décrivait des réseaux qui utilisaient déjà TCP, des réseaux planifiant des conversions ultérieures et des systèmes utilisant d'autres protocoles. « L'Internet du DoD » n'était donc pas une population unique ayant accompli un événement universel en janvier.

Les partenaires de recherche externes financés par la DARPA pouvaient être confrontés aux attentes du sponsor et pouvaient être profondément intégrés dans les travaux expérimentaux sur Internet. L'UCL, les entités aux réseaux satellitaires, les chercheurs en radio-paquets et les contractants appartenaient à des arrangements collaboratifs avec un contrôle opérationnel variable. Leur présence dans les documents protocolaires ou les tables d'hôtes ne faisait pas de chaque machine un abonné de la DCA.

Les adopteurs indépendants et externes ultérieurs étaient encore moins exposés au commandement de la DCA. Ils pouvaient choisir TCP/IP parce que des implémentations étaient disponibles, parce que des correspondants précieux l'utilisaient, ou parce que des protocoles incompatibles imposaient des coûts d'opportunité croissants. Cette pression d'effet de réseau pouvait être puissante sans créer de juridiction de la DCA sur leurs systèmes internes.

La RFC 942 est particulièrement utile car elle préserve ces distinctions tout en enregistrant les conséquences opérationnelles de la conversion. Le travail du National Research Council a été soutenu par un contrat de la DCA et publié en 1985, il s'agit donc d'une évaluation rétrospective façonnée en partie par un débat sur les normes de défense plutôt que par un recensement neutre de janvier.

Le rapport indiquait qu'environ 30 hôtes TCP uniquement avaient rejoint la population à double protocole existante au cours des six mois précédant la migration. Il attribuait aux tests approfondis le mérite d'avoir préservé la capacité opérationnelle et indiquait que des niveaux de service normaux avaient été atteints en quelques mois. Il notait également que le NIC n'avait pas été prêt à supporter les nouveaux protocoles, causant des problèmes de distribution de la table d'hôtes, et que les hôtes de service nécessitaient une analyse substantielle des performances et un réglage des paramètres car ils n'avaient pas supporté une pleine charge d'utilisateurs auparavant pendant une période prolongée.

Ce sont des conséquences documentées d'une dépendance concentrée. La distribution de la table était une dépendance opérationnelle, pas simplement un symbolisme administratif. Un logiciel de service qui fonctionnait lors de tests limités pouvait encore faiblir sous une demande soutenue. Une échéance capable d'aligner les implémentations concentrait également la charge sur les services communs.

Le même rapport complique un récit triomphal. Il indiquait que l'ARPANET utilisait généralement TCP tandis que certains utilisateurs continuaient à utiliser le NCP. Cette déclaration, deux ans après l'objectif, n'identifie pas les hôtes ou les chemins impliqués. Elle réfute toute affirmation littérale selon laquelle toute utilisation résiduelle aurait disparu universellement à minuit. La conversion de la politique, le service réseau normal, le logiciel hôte, l'utilisation locale et l'accessibilité temporaire ou exceptionnelle étaient des états différents.

Adoption externe: là où le commandement a pris fin et la compatibilité a commencé

Le succès plus large de TCP/IP dépendait de son extension au-delà de la population que la DCA pouvait gérer.

La RFC 801 décrivait un Internet ARPA connectant l'ARPANET aux réseaux de radio-paquets, satellitaires, locaux et autres. Les RFC 842 et RFC 843 incluaient des adresses en dehors du réseau 10. La RFC 844 a démontré qu'un chemin de test non classe A pouvait atteindre de nombreuses entrées avec succès. Ces sources montrent un environnement d'interconnexion de réseaux franchissant les frontières techniques et institutionnelles dès le début de 1983.

Ils n'établissent pas un régime juridique ou administratif unique à travers cet environnement.

Pour un hôte réseau-10, le rejet du NCP par un IMP était un fait opérationnel immédiat. Pour un réseau géré séparément, les facteurs décisifs pouvaient être l'accès à une implémentation TCP, une relation de passerelle, un contrat de recherche, le souhait d'atteindre les services ARPANET ou le nombre croissant de correspondants compatibles. Un réseau pouvait utiliser TCP/IP en interne et en externe sans accepter l'autorité du DDN-PMO sur chaque hôte ou port local.

Cette différence explique comment des enregistrements partagés pouvaient devenir plus importants que la juridiction du sponsor d'origine. Un réseau exploité indépendamment avait besoin d'un adressage et de valeurs de protocole uniques lorsqu'il communiquait avec l'Internet plus large. Ses utilisateurs bénéficiaient d'informations précises sur les noms et de passerelles joignables. La dépendance à une coordination commune pouvait s'étendre au-delà de l'autorité contractuelle qui avait initialement soutenu le service de coordination.

La dépendance seule, cependant, ne prouve pas un droit de gouverner. Un gardien d'enregistrements peut devenir important parce que les entités ont besoin d'informations compatibles, tout en manquant d'autorité sur leur financement, leurs systèmes internes ou leurs procédures de décision. Un sponsor peut posséder une autorité directe sur son propre réseau mais seulement influencer les adopteurs externes par des incitations à l'interopérabilité. L'expansion de TCP/IP a donc élargi le domaine de la coordination sans rendre ce domaine constitutionnellement uniforme.

C'est aussi pourquoi la migration ne peut pas être créditée de la création de tout le pouvoir d'enregistrement ultérieur. Les tables d'hôtes centrales, la coordination des numéros attribués et les règles d'enregistrement du DoD existaient déjà. Ce qui a changé, c'est l'exposition opérationnelle d'un environnement de compatibilité plus large aux erreurs, aux données de capacité périmées, aux conflits de numéros, aux défaillances de passerelles et aux faiblesses de distribution. Une conséquence accrue n'est pas identique à un pouvoir discrétionnaire nouvellement créé.

Une conversion plus lente était possible, mais elle n'était pas gratuite

Les arrangements réels de TAC et UDEL permettent de modéliser une alternative historiquement plausible sans des technologies ultérieures en 1983.

Supposons que la DCA ait conservé le NCP comme un service ARPANET ordinaire au-delà de janvier et ait permis aux organisations hôtes de migrer volontairement. Les TAC à double protocole auraient pu rester disponibles. UDEL ou d'autres hôtes auraient pu continuer le transfert de courrier. Les comptes relais Telnet et FTP auraient pu faire le pont entre les utilisateurs et les hôtes de service incompatibles. Les sites auraient pu télécharger des copies datées deHOSTS.TXTet utiliser les champs de capacité protocolaire pour sélectionner des chemins directs ou relayés.

Cela aurait réduit la pression immédiate sur les systèmes difficiles. Un hôte dépendant d'un port fournisseur inachevé aurait pu attendre. Les administrateurs auraient pu planifier la conversion en fonction du personnel et de la maintenance locaux. Les hôtes de service auraient pu subir des tests de charge plus longs avant l'arrivée de tous les utilisateurs. Le NIC aurait pu améliorer la distribution basée sur TCP pendant que les sites conservaient l'ancien chemin.

Le prix aurait été un service de transition permanent.

Les TAC à double protocole nécessitaient un support logiciel et des tests continus. Les relais nécessitaient des comptes, du stockage, des opérateurs, de la documentation et de la capacité. Un transfert de fichier en deux étapes consommait de l'espace disque et nécessitait de la maintenance. Le transfert de courrier nécessitait des files d'attente, une gestion d'adresse tenant compte du protocole, des informations actualisées sur la destination et du personnel capable de tracer les défaillances à travers deux environnements. Les utilisateurs de terminaux devaient comprendre des commandes supplémentaires et distinguer l'accès direct de l'accès médiatisé.

Le dépannage deviendrait moins local. Une session échouée pouvait impliquer l'un ou l'autre point terminal, l'une ou l'autre pile de protocoles, un compte relais, une passerelle, une copie périmée de la table d'hôtes ou un champ de capacité incorrect. Le personnel de support devrait conserver une expertise dans les deux environnements protocolaires. Les tests devraient continuer car un chemin NCP pouvait rester fonctionnel tandis que le service TCP correspondant se détériorait silencieusement, ou vice versa.

Le sponsor continuerait également à payer pour la non-convergence. Les organisations hôtes capables d'utiliser un relais pourraient reporter les travaux de conversion difficiles parce qu'une partie du coût avait été transférée à l'opérateur du relais. Plus le service de compatibilité devenait utile, plus il serait facile pour les îlots hérités de survivre. Les effets de réseau pourraient éventuellement rendre le NCP peu attrayant, mais le calendrier serait incertain et la couture opérationnelle pourrait persister pendant des années.

Une transition volontaire n'aurait pas nécessairement été plus décentralisée. Elle aurait réduit le drame d'une date imposée par l'opérateur tout en augmentant la dépendance envers les administrateurs des relais, des TAC, des enregistrements de capacité et des hôtes de service à double protocole. L'autorité deviendrait moins visible plutôt que de disparaître.

On ne peut pas non plus rejeter l'alternative en affirmant qu'elle aurait produit une défaillance de sécurité. Les sources ne documentent pas un tel incident. Elles soutiennent une observation plus modeste: chaque compte supplémentaire, hôte intermédiaire, message stocké, copie de fichier et implémentation héritée nécessitait un contrôle d'accès et des soins opérationnels. L'ampleur du risque résultant n'est pas mesurée.

La conversion réelle a choisi une allocation différente des coûts. La médiation temporaire est restée disponible, mais ses dates d'expiration ont forcé les organisations hôtes à absorber le travail de mise en œuvre. La DCA et le DDN-PMO ont utilisé le contrôle du service réseau pour rendre cette allocation crédible. Les réseaux externes, en dehors de ce contrôle, ont continué à adopter TCP/IP selon leur propre calendrier.

À quoi aurait pu ressembler une coordination plus responsable en 1983

Une conversion plus lisible ne nécessitait pas de systèmes d'authentification modernes, de réplication mondiale automatisée ou d'hypothèses sur des ressources informatiques abondantes.

La période disposait déjà des éléments de base nécessaires pour une amélioration modeste: des avis postaux, des contacts opérationnels nommés, des enquêtes sur l'état des hôtes, des copies locales deHOSTS.TXT, un processus de demande, une table d'exceptions publiée, des jours de test programmés, un support téléphonique, des relais et une comparaison manuelle des enregistrements.

News n° 19 aurait pu être étendu en un format de décision public complet pour les cas non sensibles. Chaque ligne d'exception aurait pu comporter une brève catégorie de raison, la date de la demande, la date de la décision, le bureau d'approbation, les conditions attachées à l'activation du NCP et si la date de conversion indiquée avait été respectée. Les détails sensibles pourraient rester cachés sans supprimer l'existence et le statut de la décision.

Une demande de réexamen aurait pu être adressée à un sponsor ou à un responsable des opérations qui n'avait pas pris la décision initiale. Une telle procédure n'aurait pas supprimé le contrôle du DDN-PMO sur le réseau. Elle aurait séparé l'administration de première ligne de l'examen et créé un enregistrement indiquant si des problèmes opérationnels similaires recevaient un traitement similaire.

Les publications d'état auraient également pu séparer les populations. Une table de conformité réseau-10, une table des abonnés DDN et une liste informative des entrées Internet externes auraient évité qu'une table d'hôtes mixte ne soit confondue avec une communauté gouvernée unique. Les résultats pourraient distinguer la capacité enregistrée, une connexion d'application acceptée, un test routé réussi depuis une autre classe d'adresse, une exception NCP approuvée, une indisponibilité temporaire et un résultat inexpliqué.

Une résilience de distribution était possible sous une forme limitée. Plus d'un hôte en lecture seule aurait pu servir des copies datées de la table d'hôtes. Les opérateurs pouvaient comparer les dates de version et effectuer des contrôles de cohérence manuels par rapport à la copie du NIC. Cela réduirait la dépendance à une seule machine de distribution pendant une panne. Cela ne décentraliserait pas l'autorité de mise à jour: si chaque miroir reproduisait le même enregistrement maître erroné, l'erreur resterait faisant autorité.

De telles mesures auraient coûté du temps de personnel, du stockage, de la coordination téléphonique et un travail de rapprochement supplémentaire. Les enregistrements pourraient diverger. La publication pourrait prendre du retard par rapport aux changements opérationnels urgents. Certaines informations de défense ne pouvaient pas être divulguées. Un deuxième examen pourrait retarder une décision nécessaire rapidement pour rétablir ou protéger le service.

Ces coûts sont précisément la raison pour laquelle la responsabilisation ne peut pas être traitée comme un ajout gratuit à la coordination technique. La comparaison pertinente se situe entre le coût du maintien d'enregistrements plus clairs et le coût imposé lorsque les opérateurs ne peuvent pas déterminer si une défaillance est technique, administrative, temporaire ou intentionnelle.

Le dossier de la conversion suggère que cette distinction aurait été utile. La RFC 842 pouvait montrer qu'une adresse n'acceptait pas un service mais pas pourquoi. News n° 20 pouvait montrer qu'une adresse conservait le NCP mais pas la raison complète. Le NIC pouvait publier une revendication de protocole mais pas garantir le fonctionnement observé. Le DDN-PMO pouvait approuver un port, mais l'approbation ne pouvait pas réparer une implémentation défectueuse. Un meilleur enregistrement n'effondrerait pas ces états; il les maintiendrait séparés.

L'autorité qui a changé était limitée par le réseau

La conversion de janvier a réussi dans son principal objectif opérationnel. TCP/IP est devenu l'environnement de communication normal de l'ARPANET, les principaux services y ont migré et des réseaux hétérogènes ont pu participer via une couche inter-réseau commune. Les enquêtes de février montrent des centaines de points de terminaison de service acceptant, même si elles montrent également un fonctionnement incomplet et dépendant du chemin.

La force de la conversion provenait d'une structure institutionnelle spécifique. La DARPA finançait la recherche et influençait les contractants. La DCA gérait officiellement l'ARPANET depuis le milieu des années 1970. Le DDN-PMO fixait la politique d'exploitation, décidait des exceptions NCP et approuvait les hôtes ou les ports. Les IMP et les opérateurs réseau appliquaient la désactivation du protocole. Les organisations hôtes contrôlaient la mise en œuvre sur leurs ordinateurs. Le SRI-NIC enregistrait et distribuait les informations opérationnelles. L'USC/ISI coordonnait les numéros attribués. Les opérateurs de TAC et de relais préservaient une accessibilité temporaire.

Cette division empêche la version la plus forte de l'affirmation de centralisation. Les preuves ne montrent pas que la migration elle-même ait donné au SRI-NIC un nouveau pouvoir de décider qui méritait un nom, ou à l'USC/ISI un nouveau pouvoir d'exclure des réseaux externes par des attributions de numéros. Elles montrent que des noms, adresses, capacités protocolaires, valeurs numériques et services de distribution précis sont devenus plus importants opérationnellement à mesure que davantage de communications convergeaient vers TCP/IP.

Le levier exercé se trouvait ailleurs. Le rejet du NCP au niveau IMP rendait concrète l'autorité du sponsor et de l'opérateur. Les activations individuelles et les dates d'expiration rendaient le pouvoir discrétionnaire du DDN-PMO conséquent pour les adresses réseau-10 concernées. L'approbation des hôtes et des ports liait les données administratives à l'activation réseau lors de la séparation ARPANET/MILNET. Les problèmes ultérieurs de distribution de la table d'hôtes du NIC démontraient une dépendance à un service d'information partagé, non un refus de politique. La coordination des numéros attribués préservait l'unicité, mais le dossier examiné ne fournit aucun refus ou appel lié à la migration.

Au-delà de la population gérée, les incitations à la compatibilité ont remplacé le commandement direct. Les opérateurs externes ont adopté TCP/IP parce que l'interopérabilité avec une communauté croissante était utile, parce que des sponsors ou des programmes d'approvisionnement le soutenaient, ou parce que des implémentations devenaient disponibles. Leur dépendance technique envers des identifiants partagés ne faisait pas de leurs réseaux la propriété de la DCA, de la DARPA, du SRI ou de l'ISI.

La réalisation institutionnelle et le problème de légitimité sont donc différents. La réalisation était une interopérabilité coordonnée à travers des systèmes hétérogènes. Le problème de légitimité était que la dépendance opérationnelle croissante pouvait dépasser les dossiers de décision, les procédures d'examen et les arrangements de continuité d'institutions créées pour un environnement plus restreint contrôlé par un sponsor.

Le 1er janvier a compté parce qu'il a mis fin à la coexistence indéfinie comme politique par défaut de l'ARPANET. Les expériences d'octobre, novembre et décembre ont démontré comment cette politique serait appliquée. Le registre d'exceptions de janvier a montré que l'application était sélective et temporaire plutôt qu'absolue. Les TAC et UDEL ont préservé des coutures essentielles. Les enquêtes de février ont montré que la conversion formelle, la capacité enregistrée, la réponse de l'application et l'accessibilité routée étaient encore des faits différents.

La migration a changé l'autorité en rendant certains pouvoirs existants opérationnellement décisifs: le pouvoir de désactiver un protocole, d'approuver une continuation temporaire, d'activer un port, de distribuer un enregistrement partagé ou de maintenir un relais. Elle a également accru la dépendance à une coordination au-delà de la portée de ces pouvoirs. C'est plus précis que de dire qu'une autorité unique a basculé l'Internet – et plus conséquent que la légende d'un minuit parfait.