RFC 790 et la politique cachée dans une liste d'adresses

Résumé

• La RFC 790 établit directement que plusieurs séries de numéros étaient maintenues comme référence opérationnelle courante et que les développeurs étaient invités à contacter Jon Postel pour obtenir des attributions, mais elle ne publie aucune règle générale d'éligibilité des réseaux ni aucune répartition de l'autorité d'attribution.
• La RFC 820 ajoute des catégories recherche, défense et commerciales, une distribution recommandée de l'espace de numéros de réseau, une condition proposée de préparation de passerelle pour les candidats à la recherche et une division prospective des responsabilités entre les institutions.
• La RFC 820 indique également que sa recommandation n'avait pas été entièrement mise en œuvre et que Postel coordonnait toujours toutes les attributions, de sorte que l'accord, la politique proposée et la pratique de travail ne peuvent pas être traités comme un état institutionnel identique.
• Les tableaux publiés révèlent des attributions, des transitions et des incohérences internes, et non la population des demandeurs. Sans les enregistrements des demandes, refus, retraits, utilisations et correspondances contemporaines, ils ne peuvent pas établir le traitement des demandeurs, les motifs de distribution ou une intention de dissimuler la prise de décision.

Placez la première page de deux documents monospaces sous la même lampe de lecture. Sur la page 1 deRFC 790, datée de septembre 1981, le paragraphe d'introduction indique que les informations à jour peuvent être obtenues auprès de Jon Postel et ajoute ensuite: « L'attribution des numéros est également gérée par Jon. » Le paragraphe correspondant dans le texte examiné de laRFC 820conserve la grammaire personnelle mais insère une réserve: les attributions sont gérées par le même coordinateur sous réserve d'un accord entre la DARPA/IPTO et le DDN/PMO documenté à l'Annexe A.

La clause ajoutée est suffisamment petite pour disparaître dans un document dominé par des colonnes de chiffres. L'Annexe A n'est pas petite. Elle rapporte les accords conclus lors d'une réunion de septembre 1982, recommande de diviser l'espace de numéros de réseau entre la recherche et le développement, le département de la Défense et les utilisations commerciales, nomme les responsabilités institutionnelles prospectives, propose une condition d'éligibilité pour les réseaux de recherche et se termine en reconnaissant que l'arrangement n'a pas encore été entièrement mis en œuvre.

La juxtaposition pose une question précise. Le document ultérieur a-t-il exposé une autorité qui était invisible dans l'inventaire précédent? A-t-il annoncé une nouvelle politique d'attribution, documenté un arrangement déjà en pratique, géré la transition vers une architecture de réseau différente, ou simplement fourni un compte-rendu éditorial plus complet d'un travail qui avait toujours nécessité une coordination? Les pages permettent de tester certaines de ces possibilités. Elles ne permettent pas de choisir entre elles uniquement à partir de la mise en page.

Ce n'est donc pas une affirmation selon laquelle un tableau technique aurait secrètement légiféré pour l'Internet. C'est une enquête sur ce qui a dû se passer avant qu'une entrée puisse faire partie d'un enregistrement opérationnel partagé. La réponse varie selon la série de numéros. Le choix d'un code de protocole inutilisé n'est pas la même opération que décider de la classe et de la catégorie administrative d'un réseau. Enregistrer un port n'équivaut pas à décider si un réseau expérimental est devenu opérationnel. Publier un contact n'identifie pas le demandeur, l'arbitre ou le bénéficiaire. La tâche centrale consiste à séparer ces fonctions avant de demander quelles hypothèses institutionnelles les documents soutiennent.

Deux artefacts, une divergence de catalogue

La RFC 790 est un document de 15 pages du Network Working Group attribué à J. Postel de l'Information Sciences Institute de l'Université de Californie du Sud et daté de septembre 1981. Il indique qu'il enregistre les valeurs actuellement attribuées de plusieurs séries utilisées dans les implémentations de protocoles réseau. Le développeur ayant besoin d'un numéro de lien, de socket, de port, de protocole ou de réseau est invité à contacter Postel pour obtenir une attribution.

Le document passe en revue les numéros de réseau attribués, les numéros de version Internet, les numéros de protocole Internet, les numéros de port ou de socket et les numéros de lien ARPANET. Des références et un répertoire des personnes responsables suivent. Des codes entre crochets à côté des entrées renvoient à des documents ou à des contacts nommés. Le formulaire sert au moins trois objectifs immédiats: éviter les collisions numériques, indiquer aux implémenteurs ce que désigne une valeur et fournir une personne à contacter lorsque la ligne laconique est insuffisante.

La RFC 790 déclare également qu'elle sera mise à jour périodiquement. Cette promesse est fondamentale pour son statut. Elle n'a pas été conçue pour rester le dernier mot. Elle a remplacé des documents antérieurs sur les numéros attribués et serait elle-même remplacée. Sa prétention à être à jour concernait un moment opérationnel particulier, pas une autorité permanente ou une vérité historique immuable.

La section sur les numéros de réseau occupe les pages 2 à 4. Elle explique les trois classes d'adresses et imprime leurs dispositions en bits. La classe A utilise un zéro en tête, sept bits de numéro de réseau et un champ local de 24 bits. La classe B utilise le motif d'ordre supérieur10, quatorze bits de numéro de réseau et un champ local de 16 bits. La classe C utilise110, vingt et un bits de numéro de réseau et un champ local de huit bits. Il s'agissait de catégories techniques aux capacités radicalement différentes, mais l'existence de capacités différentes n'établit pas en soi comment les demandes étaient évaluées ni si la conservation était la raison d'une attribution.

Les lignes nommées de la classe A forment un instantané mixte et incomplet. Elles incluent des réseaux de recherche, des expériences de radio par paquets, des installations militaires, des réseaux de données publics, des universités, des entrepreneurs et des opérateurs commerciaux dans plusieurs pays. Le tableau n'identifie pas l'univers d'où provenaient ces entrées. Il ne s'agit pas d'un recensement des réseaux qui voulaient des identifiants, d'une liste de demandeurs ou d'un enregistrement des demandes qui n'ont pas abouti à des attributions publiées.

L'artefact examiné de la RFC 820 est plus long, avec 22 pages. Son en-tête textuel affiche J. Postel et J. Vernon et indique janvier 1983. L'entrée actuelle du catalogue RFC Editorétiquette plutôt la RFC 820 « Assigned numbers, August 1982 » et ne liste que J. Postel. Cette analyse identifie les passages par l'en-tête et les numéros de page du texte examiné tout en préservant la divergence du catalogue. Les sources disponibles ne justifient pas de choisir silencieusement une convention de date et de paternité comme la correction de l'autre.

La RFC 820 conserve la fonction d'inventaire antérieure mais élargit sa portée. Elle fait référence à la transition de l'environnement ARPANET à l'ARPA Internet, ajoute des numéros de système autonome, inclut des numéros Ethernet et des mappages de réseaux de données publics, et agrandit substantiellement les tableaux de réseau. Plus important encore ici, la page 1 soumet l'allocation de numéros à l'accord DARPA/IPTO–DDN/PMO, tandis que les pages 19 à 22 reproduisent les recommandations qui en résultent et la note de mise en œuvre.

Les deux RFC sont maintenant classées comme Historiques dans le flux Legacy. La RFC 790 a été remplacée par la RFC 820, et la RFC 820 a été remplacée par la RFC 870. Ces classifications actuelles n'impliquent pas que les documents étaient invalides ou non pertinents lorsqu'ils étaient utilisés. Une publication de registre récurrente devient obsolète parce que les attributions et les pratiques changent. L'obsolescence ultérieure fait partie de ce cycle de vie documentaire, pas une annulation rétrospective de l'instantané antérieur.

Une comparaison ultérieure aide à définir la limite. LaRFC 943, publiée en avril 1985, se décrit explicitement comme un rapport de statut officiel pour les numéros utilisés dans les protocoles de la communauté ARPA-Internet. Elle distingue également les réseaux connectés aux Internets ARPA ou DDN des réseaux indépendants utilisant les protocoles Internet. Cette articulation ultérieure ne peut pas être importée dans la RFC 790. Elle montre que le langage et l'appareil de classification ont continué à se développer.

Les différences décisives entre les deux artefacts principaux peuvent être compressées sans prétendre que chaque différence a une cause unique:

La comparaison établit un changement documentaire. La question suivante est de savoir quel type d'administration chaque mot et chaque tableau exigeaient.

« Attribué », « enregistré », « courant » et « officiel » n'étaient pas synonymes

L'instruction d'ouverture de la RFC 790 fait plus qu'inviter un développeur à signaler une valeur qu'il a lui-même choisie. Elle dit de contacter Postel « pour recevoir une attribution de numéro ». Avant qu'une nouvelle valeur puisse apparaître en toute sécurité dans une liste partagée, quelqu'un devait prendre connaissance de la demande, vérifier l'absence de collision, choisir ou confirmer une valeur, communiquer le résultat et mettre à jour l'enregistrement. Cette séquence minimale est une administration coordonnée.

Il ne s'ensuit pas que chaque série impliquait une décision également conséquente. Pour de nombreuses demandes de protocole ou de port, l'acte essentiel pouvait être de trouver un point de code inutilisé et de maintenir l'interopérabilité. Le texte ne fournit aucune base pour affirmer que les mérites institutionnels de chaque développeur étaient évalués. Le mot « attribution » désigne une opération, mais sa seule présence ne révèle ni les critères ni la profondeur du jugement qui le sous-tend.

Les numéros de réseau sont différents parce que la RFC 820 les relie à des catégories d'utilisation administrative et à une condition d'éligibilité recommandée. L'Annexe A dit que, au sein de la communauté de recherche et développement, les identifiants de réseau ne seront accordés qu'aux demandeurs qui montrent la preuve qu'ils acquièrent le logiciel de passerelle BBN standard ou qu'ils ont implémenté ou acquièrent une passerelle répondant aux exigences de l'Exterior Gateway Protocol. Elle ajoute que l'acquisition du logiciel Berkeley BSD 4.2 UNIX pourrait compter comme preuve de ce dernier.

La formulation est plus forte qu'un simple contrôle d'unicité. Elle conditionne une subvention recommandée à une preuve de préparation technique. Mais elle reste partie de la politique recommandée, pas une preuve d'une règle de fonctionnement déjà universelle. L'annexe ne spécifie pas de norme de preuve complète, de méthode d'arbitrage, de procédure d'appel ou d'enregistrement des demandes évaluées sous cette condition. La dernière page dit explicitement que la recommandation n'a pas encore été entièrement mise en œuvre.

« Courant » remplit une autre fonction. Les deux documents prétendent décrire les valeurs actuellement attribuées et indiquer aux lecteurs où obtenir des informations à jour. Dans ce contexte, le caractère « courant » est une affirmation de synchronisation: les implémenteurs devraient pouvoir consulter une référence maintenue plutôt que de se fier à des listes privées incompatibles. Cela ne signifie pas que la justification originale de chaque entrée, son histoire institutionnelle ou son détenteur actuel soient entièrement documentés.

La RFC 820 utilise « enregistré » dans sa section sur les systèmes autonomes. L'Exterior Gateway Protocol fournit un champ de 16 bits identifiant les systèmes autonomes, et les valeurs sont enregistrées dans le document. La table initiale est presque vide: zéro est réservé, un identifie les passerelles BBN, les valeurs de deux à 65 534 ne sont pas attribuées et 65 535 est réservé. Ici, l'enregistrement décrit l'enregistrement commun d'une série d'identifiants à un stade précoce. Il ne peut pas être appliqué indistinctement à l'annexe sur les réseaux, où la classification et les preuves recommandées pour les demandeurs ajoutent des considérations différentes.

« Officiel » devient explicite dans la RFC 943, pas dans le langage de statut d'ouverture de la RFC 790 ou de la RFC 820. Cette formulation ultérieure décrit la reconnaissance au sein de la communauté ARPA-Internet. Elle ne rend pas chaque acte antérieur de maintenance de liste équivalent à une décision gouvernementale formelle, et elle n'établit pas non plus qu'une entrée avait la même signification en dehors de la communauté pour laquelle le rapport fonctionnait.

Les mots identifient donc des fonctions qui se chevauchent mais sont séparables. L'attribution peut inclure la sélection ou la confirmation. L'enregistrement enregistre une valeur. Le caractère courant exprime la maintenance. Le statut officiel identifie une position reconnue dans une communauté opérationnelle définie. Leur proximité dans la lignée des numéros attribués ne les réduit pas à une autorité universelle unique.

Une publication contenait plusieurs registres différents

Le titre « Numéros attribués » rassemble plusieurs séries dans un seul document, mais leurs problèmes de collision et leurs enjeux institutionnels n'étaient pas interchangeables.

Un numéro de protocole Internet occupait un champ de huit bits dans l'en-tête IP et identifiait le protocole de niveau suivant transporté par un paquet. La coordination de ce numéro permettait à différentes implémentations d'interpréter le champ de manière cohérente. L'Annexe A de la RFC 820 proposait de réserver des portions de l'espace des numéros de protocole pour les normes DoD, les utilisations de recherche et les normes commerciales, nationales ou internationales. Il s'agissait de coordination sur les identifiants de protocole, pas d'une allocation de capacité d'adresse hôte à une organisation.

Un numéro de port identifiait un point de contact de service à la fin d'une connexion logique. La RFC 790 discutait encore à la fois des sockets AHHP et des ports TCP, tandis que la RFC 820 présentait une liste de ports centrée sur TCP et la réutilisation avec UDP lorsque c'était possible. L'attribution d'un port bien connu pouvait rendre un service interopérable entre les implémentations. Cela ne faisait pas de l'auteur du protocole nommé ou du contact de service le détenteur d'un bloc de réseau.

Les numéros de réseau jouaient un rôle différent. Ils identifiaient les réseaux dans l'architecture d'adressage Internet. La classe choisie déterminait la largeur du champ d'adresse locale: 24 bits pour la classe A, seize pour la classe B et huit pour la classe C. Les attributions de réseau différaient donc non seulement en tant qu'étiquettes, mais aussi en capacité d'adresse et en traitement de routage. Le code de catégorie, la marque de transition et la recommandation de préparation de passerelle de la RFC 820 s'appliquaient à cette opération plus différenciée institutionnellement.

Les numéros de système autonome étaient une autre série distincte. Leur but était d'identifier des groupes de passerelles pour l'Exterior Gateway Protocol. Leur apparition dans la RFC 820 enregistre le développement précoce de la coordination interdomaine; elle ne fournit pas une doctrine générale pour l'éligibilité des numéros de réseau.

Les numéros de lien ARPANET appartenaient à l'environnement d'interface Host/IMP. L'annexe de la RFC 820 recommandait d'éliminer les utilisations inutiles et d'étudier les questions d'interopérabilité entre les interfaces. Cette tâche concernait un autre champ de protocole et un autre ensemble de dépendances opérationnelles.

L'enregistrement de noms ne doit pas être déduit simplement parce que les tables de ports contiennent des services liés aux noms. La RFC 790 attribue le port 42 à un serveur de noms et le port 43 à Whois. La RFC 820 contient ces contacts de service et ajoute des ports de serveur de noms d'hôte ou de boîte aux lettres. Ce sont des entrées pour atteindre des services, pas un registre de noms d'hôte ou de domaines. La section des personnes est également un répertoire de contacts responsables, pas un registre de noms ou un grand livre des demandeurs.

L'outil de recherche du Computer History Museum pour les archives SRI ARC/NICrenforce la distinction institutionnelle. Il décrit la maintenance par le SRI Network Information Center de la table des hôtes ARPANET et les transitions de nommage ultérieures comme une activité distincte. Il indique également que l'administration des numéros attribués et l'allocation globale d'adresses ont été transférées de l'USC-ISI au contrat SRI NIC en 1987. L'outil de recherche est un contexte d'archives ultérieur, pas une preuve que le SRI exploitait la fonction d'attribution de 1981–1983 décrite dans les deux RFC.

Regrouper les séries dans une publication de référence unique avait un sens opérationnel. Les développeurs pouvaient trouver les constantes et les contacts associés en un seul endroit. Pourtant, le format commun ne faisait pas de chaque numéro listé une concession du même type. Les conclusions de gouvernance tirées de l'annexe sur les numéros de réseau doivent rester attachées à cette annexe, à moins qu'une autre section ne fournisse ses propres preuves.

Les catégories administratives n'ont pas remplacé les classes techniques

La RFC 820 superpose deux classifications différentes. La première est architecturale: les classes A, B et C définissent les formats d'adresse. La seconde est administrative:R,DetCidentifient les utilisations de recherche et développement, DoD et commerciales. Les confondre crée de fausses comparaisons.

À la page 2, le texte examiné de la RFC 820 décrit correctement la classe A comme ayant un zéro en tête et la classe B comme ayant le motif de tête10. Sa prose décrit les trois bits d'ordre supérieur de la classe C comme1-0-0, mais le diagramme adjacent montre1 1 0, et sa plage de classe C commence à 192, dont les bits d'ordre supérieur sont110. La RFC 790 imprime également le motif de la classe C comme110. La phrase1-0-0dans la RFC 820 est donc une erreur textuelle interne, pas une preuve d'une architecture d'adresse différente.

Les trois classes techniques contenaient respectivement 128, 16 384 et 2 097 152 valeurs possibles de numéro de réseau, avant les points de terminaison réservés et autres exclusions. Leurs champs locaux contenaient (2^{24}), (2^{16}) et (2^8) valeurs d'adresse numériques par réseau. Ces différences rendaient le choix de la classe conséquent, mais aucune des deux RFC ne fournit de mesures d'utilisation d'hôte pour ses réseaux listés.

Les codes administratifs répondent à une question distincte: à quelle catégorie d'utilisation le document associait-il un identifiant attribué. Un code de recherche n'implique pas une petite ou une grande classe. Une organisation commerciale pouvait participer à un projet de recherche, tandis que le réseau d'un entrepreneur pouvait être classé selon l'utilisation du réseau plutôt que le caractère juridique de l'institution. L'employeur du contact, la description du réseau et le code de catégorie ne peuvent pas être traités comme des preuves interchangeables.

L'Annexe A recommande de diviser les espaces de classe disponibles entre les trois utilisations. Pour la classe A, elle donne huit réseaux à la recherche et au développement, 24 au DoD et 94 à l'utilisation commerciale. Pour la classe B, elle donne 1 024, 3 072 et 12 286. Pour la classe C, l'annexe imprime 65 536 pour la recherche, 458 725 pour le DoD et 1 572 862 pour l'utilisation commerciale.

Ce sont des allocations proposées, pas une description d'une distribution achevée. Le tableau de travail de la page 6 rapporte 26 identifiants de classe A recherche attribués, quatre défense et un commercial. Les 26 entrées de recherche représentent 3,25 fois l'allocation recommandée de l'annexe de huit. Plusieurs entrées sont marquées comme d'anciens numéros de transition. Le décalage est compatible avec la déclaration explicite du document selon laquelle la mise en œuvre reste incomplète.

Le document contient également une incohérence numérique. Le résumé « Maximum autorisé » de la page 6 donne l'allocation de défense de classe C comme 458 752, tandis que l'Annexe A à la page 20 imprime 458 725. La différence est de 27 identifiants.

En utilisant le chiffre de la page 6, les catégories proposées de classe C totalisent:

• 65 536 identifiants de recherche;
• 458 752 identifiants de défense; et
• 1 572 862 identifiants commerciaux;

pour un total de 2 097 150. Cela correspond à l'espace de numéro de réseau de classe C de 2 097 152 valeurs après que la première et la dernière valeurs sont réservées.

En utilisant le chiffre de 458 725 imprimé dans l'Annexe A à la place, on obtient 2 097 123, ce qui est 27 de moins que le total de la page 6. Le document ne fournit aucune explication. Une reconstruction devrait préserver les deux affirmations imprimées plutôt que d'en réparer une silencieusement.

L'Annexe A recommande en outre que les réseaux expérimentaux devenant opérationnels n'aient pas besoin d'être renumérotés lorsque la renumérotation causerait des difficultés. Leurs identifiants pourraient plutôt passer du statut de recherche à celui de défense ou commercial. Les allocations globales de catégorie étaient censées rester constantes tandis que des identifiants spécifiques changeaient d'état. L'annexe déconseille donc d'allouer les catégories en simples partitions contiguës et recommande des attributions spécifiques suivies par les organismes responsables.

Ceci est une recommandation politique sur la classification, la continuité et la coordination. Elle ne prouve pas comment un réseau particulier a obtenu sa ligne existante. Un code de catégorie enregistre le résultat imprimé dans le tableau; il ne s'agit pas d'un état des motifs qui subsiste.

La recommandation, l'accord et la pratique de travail occupaient la même annexe

L'Annexe A commence par dire qu'elle résume les accords conclus par le DDN/PMO et la DARPA lors d'une réunion de septembre 1982. Elle utilise ensuite à plusieurs reprises le langage de la recommandation.

Pour les identifiants de réseau, le récit recommande que les attributions pour les utilisations de recherche, de défense et commerciales deviennent respectivement la responsabilité de la DARPA, du DCA PCCO/DDN et du National Bureau of Standards. Les tableaux numériques, cependant, nomment l'ARPA comme l'attributaire de recherche et imprimentTBDpour les attributaires de défense et commerciaux.

Trois états institutionnels sont donc visibles. Les agences avaient conclu un accord suffisant pour être résumé. Le document recommandait une distribution future des responsabilités. Des responsabilités importantes au niveau des bureaux restaient non résolues dans les tableaux.

Un quatrième état apparaît à la page 22: la pratique de travail. La note de mise en œuvre dit que la recommandation politique n'a pas été entièrement mise en œuvre et que Postel agit actuellement comme coordinateur pour toutes les attributions de numéros. Quelle que soit la division institutionnelle anticipée par l'annexe, les demandeurs et les implémenteurs rencontraient toujours un point de coordination central.

Le langage sur la préparation des passerelles doit être situé dans cette séquence. Il énonce ce que « sera la politique » au sein de la communauté de recherche dans le cadre de l'arrangement recommandé. C'est une preuve directe d'une condition d'éligibilité proposée. Ce n'est pas une preuve directe que chaque entrée antérieure dans la RFC 790, chaque entrée dans la RFC 820 ou chaque type de demande de numéro avait déjà été traitée selon cette condition.

De même, la disposition sur les difficultés est une règle de transition recommandée. Elle montre que les concepteurs de la politique reconnaissaient le coût opérationnel de la renumérotation. Elle n'identifie pas quels changements marquésTétaient volontaires, requis, négociés ou effectués pour des raisons non liées à la nouvelle allocation de catégorie.

L'annexe soutient néanmoins un constat institutionnel significatif. Ses auteurs pouvaient distinguer l'attribution substantive du suivi central. Différents organismes pouvaient faire des attributions dans différentes catégories, tandis que le DDN/PMO ou un délégué tenait à jour l'enregistrement combiné pour s'assurer que l'allocation restait dans les limites de la recommandation. Le responsable de l'enregistrement commun n'avait pas à être la source unique de chaque décision.

Cette architecture comportait également des problèmes non résolus. Si un réseau changeait de catégorie, quelqu'un devait mettre à jour les soldes de catégorie. Si un allocataire dépassait son montant, une procédure de correction ou d'exception serait nécessaire. Si deux organismes traitaient la même demande comme relevant de leur compétence, le système aurait besoin d'un moyen de résoudre le chevauchement. La RFC 820 recommande le suivi mais ne publie pas un code juridictionnel complet.

Le document contient donc une théorie administrative sous forme partielle: des pools différenciés, plusieurs allocataires possibles, une coordination centrale, une protection de la continuité et une éligibilité technique pour une catégorie. Il contient également des preuves que la théorie et l'interface d'attribution réelle n'avaient pas encore convergé.

Compter l'inventaire sans transformer les lignes en demandeurs

Les tableaux de réseau peuvent tester comment le changement documentaire est apparu dans les attributions publiées, mais seulement si trois unités d'observation restent séparées.

Uneligne impriméeest une ligne ou une entrée de plage telle qu'elle apparaît dans le document. Elle peut décrire un identifiant, des centaines d'identifiants ou un ancien numéro conservé pendant la transition. Les lignes en double restent des lignes imprimées.

Unidentifiant de réseau étenduest un numéro de réseau avec classe représenté après l'expansion d'une plage imprimée. La plage de la RFC 820192.001.xxxà192.004.xxx, par exemple, représente quatre valeurs du deuxième octet multipliées par 256 valeurs du troisième octet, soit 1 024 identifiants de classe C.

Unechaîne d'identifiant littéral uniqueest un identifiant étendu après déduplication des chaînes d'adresse imprimées identiques, sans deviner ce qu'une séquence apparente était censée dire. Cette unité préserve les conflits de transcription au lieu de les corriger de manière invisible.

Aucune de ces unités n'est un demandeur, un bénéficiaire, une organisation, une route active, un hôte ou un intérêt de propriété.

Le tableau de classe A de la RFC 790 imprime des lignes d'attribution nommées pour les valeurs 001 à 044, sauf que 013 est explicitement non attribué. Cela produit 43 lignes d'attribution nommées. Cela ne produit pas 43 identifiants attribués incontestés. La ligne pour 044 nomme AMPRNET, mais la plage non attribuée qui suit immédiatement commence également à 044 et continue jusqu'à 126. Le document fournit donc 42 identifiants nommés sans ambiguïté plus un identifiant en conflit interne, 044.

La classe B ne contient aucune attribution nommée dans la RFC 790, et la classe C non plus. Cette déclaration décrit le tableau, pas l'absence de tout réseau plus petit dans le monde. Les réseaux de classe A listés incluent de multiples expériences, des installations connexes et des réseaux de test. Une ligne nommée n'est pas la preuve d'un bénéficiaire légalement indépendant.

La RFC 820 fournit un résumé imprimé des « Totaux de réseau » à la page 6:

En utilisant ce résumé imprimé, la recherche représente (1 078 / 1 097), soit 98,267 pour cent, arrondi à 98,3 pour cent. Ceci est un résultat du résumé imprimé, pas une constatation que 98,3 pour cent des demandeurs ou des organisations étaient des institutions de recherche.

La contribution dominante provient d'une seule plage associée aux réseaux locaux BBN. L'expansion de192.001.xxxà192.004.xxxdonne (4 \times 256 = 1 024) identifiants de classe C. Ces 1 024 identifiants représentent (1 024 / 1 097), soit 93,345 pour cent, arrondi à 93,3 pour cent, du total attribué imprimé de la RFC.

Ce dénominateur est explicite: 1 097 attributions étendues telles que représentées par le résumé imprimé. Le ratio ne signifie pas que BBN a fait 1 024 demandes distinctes, a reçu 1 024 décisions indépendantes ou a utilisé chaque réseau comme une unité routée extérieurement. Le document associe une plage aux « réseaux locaux BBN » mais n'explique pas l'historique des demandes ou la topologie opérationnelle qui la sous-tend.

La déduplication littérale produit un résultat différent. Dans le tableau de classe C,192.005.022est imprimé pour BRLNET2, BRLNET3, BRLNET4 et BRLNET5. Les noms suggèrent une séquence intentionnelle, et la plage non attribuée suivante commence à 192.005.026, mais une reconstruction littérale ne peut pas substituer 023, 024 et 025 sans marquer cela comme une correction.

Dédupliquer les quatre occurrences de192.005.022supprime trois occurrences en double du total imprimé de classe C:

Parce que les lignes BRL répétées sont codées défense, les totaux de catégorie littérale unique deviennent 1 078 recherche, treize défense et trois commerciaux, pour 1 094 au total. Le compte de recherche reste 1 078; le compte de défense tombe de seize à treize.

La différence est petite par rapport à la plage BBN mais décisive pour la méthode. Un résumé imprimé peut être reproduit comme l'affirmation de la source. Un compte de chaînes uniques peut être reproduit comme une lecture littérale distincte. Aucun ne doit être présenté comme l'autre.

Les entrées de transition ajoutent une autre complication. La RFC 820 explique que les anciens numéros peuvent rester listés avec unTpour faciliter les changements. Un réseau peut donc apparaître sous un ancien identifiant de classe A et un identifiant plus récent de classe B sans représenter deux bénéficiaires situés indépendamment. Compter les deux peut être correct pour la reconnaissance opérationnelle et faux pour l'analyse des bénéficiaires.

Le mouvement entre les documents est toujours visible. La RFC 790 contient des lignes nommées uniquement dans le tableau de classe A. La RFC 820 contient un mélange de 31 attributions de classe A, 24 de classe B et 1 042 de classe C selon son résumé, aux côtés de marques de transition explicites. Certains grands identifiants antérieurs avaient été remplacés, abandonnés ou conservés temporairement tandis que des identifiants de classe plus petite apparaissaient.

Ce changement est cohérent avec des tailles d'attribution plus différenciées. Ce n'est pas une preuve que la rareté a causé chaque changement. Les tableaux ne contiennent aucune série d'utilisation d'hôte, de prévisions, de formulaires de demande ou de raisons de décision. La capacité d'un identifiant de classe A dit ce que le format d'adresse permettait, pas combien d'adresses le réseau nommé utilisait ni pourquoi les administrateurs ont sélectionné cette classe au moment pertinent.

La plage BBN est un contre-argument important contre un récit simple de préférence uniforme pour la plus grande classe disponible. Un entité majeur apparaît à travers 1 024 petits identifiants de classe C ainsi que d'autres entrées. Les tableaux n'expliquent pas si cet arrangement reflétait des expériences, une segmentation locale, une pratique de routage, une commodité administrative ou un autre objectif. Ils montrent que la proéminence institutionnelle n'a pas mécaniquement produit une classe d'adresse dans tous les cas.

Le compte commercial imprimé est également facile à mal interpréter. Seulement trois attributions sont codées commerciales dans le résumé de la page 6, tandis que l'Annexe A propose une grande allocation commerciale prospective. Ce contraste peut refléter une transition politique à un stade précoce, la portée limitée de l'Internet fonctionnel, la pratique de codage, la composition de la demande ou une mise en œuvre incomplète. Sans les demandes et la correspondance, il ne peut pas établir d'exclusion ou de traitement préférentiel.

Ce que les données d'attribution ultérieures peuvent et ne peuvent pas réparer

L'histoire visuelle de l'allocation IPv4de CAIDA offre une reconstruction utile du mouvement de l'espace d'adressage. Elle démontre également pourquoi les visualisations ultérieures ne peuvent pas fournir le dénominateur manquant des demandeurs.

CAIDA explique que la partie précoce de la visualisation dérive des RFC de numéros attribués, tandis que les périodes ultérieures utilisent des données de l'IANA. La représentation opère à une granularité/8, plaçant des allocations plus petites à l'intérieur des blocs d'adresses plus grands qui les contiennent. Elle note que l'espace d'adressage alloué a diminué entre la RFC 790 et la RFC 820, en partie parce que certaines organisations ont échangé de gros blocs contre des attributions plus petites.

Ce compte rendu est compatible avec les marques de transition de la RFC 820 et le déclin des entrées nommées de classe A. Ce n'est pas une corroboration indépendante au niveau des bénéficiaires parce que sa reconstruction précoce repose sur la série de RFC examinée. La séquence de dates publiques passe de novembre 1977 à janvier 1983, et les données Sankey associées agrègent les flux par/8. Elles ne peuvent pas reconstruire indépendamment chaque demande, décision d'attribution ou transition de bénéficiaire entre la RFC 790 et la RFC 820.

Les enregistrements de registre ultérieurs introduisent d'autres problèmes. Le compte rendu séparé de CAIDA sur la méthodologie de consommation d'IPv4 note qu'une mise à jour de 1993 a attribué à de nombreuses allocations héritées une date d'août 1993 lorsque des dates antérieures précises n'étaient pas disponibles. Les enregistrements ultérieurs peuvent également hériter de changements de nom organisationnels, de transferts de responsabilité administrative, de corrections et de changements de statut.

Une entrée de registre actuelle est donc une preuve d'un état administratif survivant, pas un enregistrement intact de ce qu'un demandeur a demandé en 1981. Elle peut aider à retracer la continuité ultérieure, mais elle ne peut pas par elle-même restaurer la raison, la date ou l'unité de décision qui a produit une première ligne.

Les tableaux peuvent soutenir plusieurs constats empiriques sans exagération:

• La RFC 790 imprime 43 lignes d'attribution de classe A nommées, dont 42 sont sans ambiguïté et une est en conflit avec la plage non attribuée suivante.
• Le résumé imprimé de la RFC 820 rapporte 1 097 attributions, mais la déduplication littérale donne 1 094 chaînes d'adresse uniques.
• La recherche représente 98,3 pour cent du total imprimé, en grande partie parce qu'une plage BBN s'étend à 1 024 identifiants de classe C codés recherche.
• La plage BBN seule représente 93,3 pour cent du total du résumé imprimé de 1 097.
• Les anciens et les nouveaux identifiants peuvent coexister parce que les lignes de transition préservent la continuité opérationnelle.
• Le tableau de travail ne correspond pas encore aux allocations de catégorie recommandées par l'Annexe A.
• Les documents ne contiennent aucun dénominateur direct pour les demandes, les refus, les retraits ou les demandes découragées.

Ces constats montrent que l'inventaire était produit administrativement. Les catégories, les changements, les réservations et les transitions devaient être enregistrés. Ils ne révèlent pas si des demandeurs placés dans des situations similaires étaient traités de manière similaire, parce que la population pertinente et les dossiers de décision sont absents.

Quatre explications survivent au delta textuel

Le mouvement de la RFC 790 à la RFC 820 a au moins quatre explications possibles à l'époque.

La première est le développement politique. La réunion de septembre 1982 a pu produire une réponse plus explicite à un Internet en croissance et en diversification. Les nouveaux codes de catégorie, les tailles de pool recommandées, la condition de préparation des passerelles et la division proposée des responsabilités institutionnelles soutiennent cette lecture. L'Annexe A les présente directement comme une politique recommandée liée à un accord d'agence.

La deuxième est la gestion de la mise en œuvre. La transition de l'environnement ARPANET à l'ARPA Internet, le développement de MILNET et la renumérotation ou la reclassification des réseaux ont pu nécessiter un document opérationnel plus élaboré même sans une philosophie de distribution entièrement nouvelle. Les marquesT, les attributions de classe plus petite et la disposition sur les difficultés correspondent à cette explication.

La troisième est le nettoyage de la documentation. Des pratiques qui étaient auparavant comprises par correspondance ou relations de travail ont pu être écrites plus clairement. Les totaux, les codes administratifs et les notes de mise en œuvre pourraient refléter une meilleure publication plutôt que le début de chaque pratique qu'ils décrivent.

La quatrième est la préférence de rédaction. L'en-tête examiné de la RFC 820 affiche un nom supplémentaire, J. Vernon, même si le catalogue actuel ne liste que Postel. Un processus de rédaction différent aurait pu produire une prose institutionnelle plus explicite sans changement proportionnel dans les décisions quotidiennes. La divergence catalogue/en-tête fait de la paternité et de la transmission éditoriale une partie de l'incertitude plutôt qu'une base pour attribuer un rôle politique particulier.

Ces alternatives ne s'excluent pas mutuellement. L'annexe pourrait simultanément enregistrer un accord, guider une transition, formaliser des attentes existantes et refléter un style éditorial plus expansif.

La correspondance contemporaine pourrait les distinguer. L'outil de recherche du Computer History Museum identifie des carnets de réunion, des rapports d'avancement du NIC, des fichiers de nommage et d'adressage, des courriels chronologiques, des enregistrements de groupes de travail et des rapports mensuels Internet collectés auprès d'entrepreneurs. Il indique que des communications potentiellement pertinentes entre le personnel du NIC, les utilisateurs du réseau, les groupes de travail et les agences fédérales survivent dans des collections d'archives.

L'outil de recherche ne divulgue pas le contenu d'une demande spécifique de la RFC 790, de l'enregistrement de la réunion de septembre 1982 ou de la correspondance de rédaction de l'Annexe A. Il prouve l'existence et la portée des collections, pas ce que des enregistrements non ouverts établiraient.

Un examen archivistique ciblé demanderait qui a rédigé l'annexe, si les codes de catégorie étaient déjà utilisés en interne, comment la preuve de passerelle était évaluée, pourquoi certaines autorités d'attribution restaientTBDet si des renumérotations particulières étaient proposées par les réseaux ou par les administrateurs. Jusqu'à ce que les enregistrements sous-jacents répondent à ces questions, le delta textuel soutient de multiples explications.

Les contacts exposaient la responsabilité sans définir la chaîne de décision

Les deux RFC consacrent un espace substantiel aux personnes responsables. Un code entre crochets à côté d'un protocole ou d'un réseau renvoie à un nom, une affiliation et une boîte aux lettres dans la section des personnes. Cela rendait les entrées laconiques utilisables opérationnellement. Un développeur pouvait demander à quelqu'un ce que signifiait un protocole non documenté ou qui contacter à propos d'un réseau nommé.

Le mot « responsable » est néanmoins élastique. La personne pouvait être un auteur de protocole, un implémenteur, un contact de site, un ingénieur, une source de documentation ou un responsable de registre. La colonne ne dit pas si cette personne a demandé le numéro, l'a approuvé, contrôlait le réseau ou en savait simplement assez pour répondre à des questions techniques.

L'ambiguïté est visible dans l'utilisation deJBP, le code de Postel. Il apparaît à côté de plages réservées et non attribuées ainsi que de valeurs de protocole attribuées. Dans ces positions, il ne peut pas désigner un bénéficiaire. Il marque la responsabilité de l'état du registre ou de la définition technique. D'autres codes pointent vers des personnes associées à des réseaux nommés. Une notation représente donc plusieurs relations.

L'appareil de contact soutient une affirmation institutionnelle limitée: la coordination précoce dépendait d'experts identifiables et de boîtes aux lettres joignables. Il ne soutient pas l'affirmation que la réputation personnelle était un critère d'allocation. Il ne montre pas non plus si les discussions préliminaires se déroulaient par courrier électronique, téléphone, correspondance papier ou réunions.

La publication dans la liste partagée donnait à une attribution une visibilité opérationnelle. Les implémenteurs qui s'appuyaient sur la référence pouvaient éviter la duplication et identifier le contact pertinent. Cette importance pratique n'établit pas que la liste créait l'existence technique de chaque réseau ou conférait un droit de propriété. Le modèle multi-allocataire proposé par l'Annexe A suggère plutôt que les décisions d'attribution pouvaient provenir de plusieurs institutions et être consolidées pour le suivi.

Un grand livre plus complet était faisable, mais pas sans coût

Imaginez que la partie sur les numéros de réseau de la RFC 820 ait conservé cinq types d'informations supplémentaires: les critères d'éligibilité applicables, un code de raison court, la provenance de chaque révision, les dispositions agrégées des demandes et le bureau autorisé à décider des exceptions.

Cela n'aurait pas nécessairement requis un système de demande public moderne. Une conception réalisable à l'époque aurait pu utiliser une annexe distincte à largeur fixe, des formulaires papier, des modèles de courrier électronique et des totaux mensuels agrégés. Les codes de raison auraient pu distinguer la préparation de passerelle, l'expérimentation, la transition, le changement de catégorie et la correction. Une colonne de révision aurait pu enregistrer l'identifiant précédent et la date d'effet. Les détails sensibles auraient pu rester dans des fichiers restreints tandis que la liste publique portait un code minimal.

De tels enregistrements rendraient plusieurs questions historiques testables. Les chercheurs pourraient comparer les attributions complétées avec les retraits ou les refus, distinguer la renumérotation demandée par le demandeur de l'initiation administrative et déterminer si le critère de passerelle était appliqué de manière cohérente. Une autorité d'exception nommée montrerait où la division proposée des responsabilités s'arrêtait.

L'enregistrement supplémentaire imposerait également des charges. Le personnel devrait conserver les données d'entrée de manière cohérente, maintenir des vocabulaires de raisons et réconcilier les révisions à travers les publications successives. Les demandes expérimentales ou liées à la défense pourraient contenir des détails inadaptés à la diffusion publique. Les règles de caviardage créeraient d'autres décisions. Les entréesTBDdans la RFC 820 montrent que l'identification d'une autorité d'exception était elle-même inachevée.

L'outil de recherche du SRI NIC décrit des incompatibilités de médias, des difficultés de production d'impression et des publications de référence rapidement obsolètes dans la période plus large. Parce que l'administration des numéros attribués est restée à l'USC-ISI jusqu'en 1987, cette preuve ne peut pas établir le processus de production précis ou les coûts de la RFC 790 et de la RFC 820. C'est un contexte d'époque montrant qu'une documentation plus riche aurait interagi avec des contraintes techniques et de publication réelles.

Le contrefactuel change donc la preuve survivante, pas nécessairement la légitimité de l'institution. Les critères peuvent être mal conçus, les raisons peuvent être stéréotypées et les comptes agrégés peuvent omettre des personnes qui n'ont jamais appris comment postuler. Même ainsi, la différence entre une liste d'entrées réussies et un enregistrement de décision motivé aurait rendu les affirmations ultérieures sur le traitement substantiellement plus faciles à tester.

Maintenant, inversez la conception. L'unicité aurait-elle pu être coordonnée sans qu'un bureau central décide de chaque attribution?

La propre recommandation de la RFC 820 répond oui en principe. Les identifiants de recherche, de défense et commerciaux pouvaient être attribués par différents organismes tandis qu'un coordinateur désigné suivait l'enregistrement combiné. L'époque supportait déjà le courrier électronique, la coordination téléphonique et les documents périodiquement mis à jour. Plusieurs arrangements réalisables étaient concevables.

Une option était des attributions spécifiques rapportées à un traqueur commun, ce que l'Annexe A préférait parce que les identifiants pouvaient changer de catégorie. Une autre était des pools partitionnés dans lesquels chaque allocataire contrôlait une plage définie et publiait périodiquement des mises à jour. Une troisième était un ensemble distribué de listes responsables réconciliées selon un calendrier, avec des messages de réservation temporaires empêchant les collisions entre les éditions.

Chaque alternative avait des coûts. Les partitions simples rendaient les changements de catégorie plus difficiles et pouvaient bloquer des identifiants inutilisés dans un pool. La réconciliation périodique introduisait un délai. Les listes distribuées risquaient des états conflictuels. L'attribution spécifique par un traqueur commun réduisait certains risques de collision mais rendait le traqueur opérationnellement important.

Le point n'est pas que la décentralisation aurait nécessairement été supérieure. C'est que le contrôle des collisions, l'éligibilité substantive et la publication pouvaient être divisés. Le suivi commun était précieux opérationnellement et explicitement recommandé dans l'architecture de la RFC 820, mais un inventaire universel unique n'était pas la seule conception logiquement possible.

Cette distinction importe lors de l'interprétation du rôle du coordinateur. Si les allocataires de catégorie désignés n'étaient pas résolus ou indisponibles, la personne maintenant l'enregistrement commun pourrait continuer à traiter les demandes en pratique. Cette expansion pourrait résulter d'une mise en œuvre incomplète plutôt que d'une revendication d'autorité exclusive. La RFC 820 documente précisément un tel écart: la responsabilité distribuée est recommandée tandis qu'un coordinateur gère encore toutes les attributions.

Le soutien fédéral explique la capacité, pas toutes les règles

Le contexte gouvernemental ne peut être ajouté qu'après que les deux documents ont établi leurs propres termes.

Unavis juridique du Government Accountability Office de 2016déclare que les fonctions regroupées plus tard sous le nom d'IANA ont commencé dans un travail dirigé par Postel à l'UCLA et ont déménagé avec lui à l'USC-ISI en 1977. Le GAO décrit le travail comme effectué dans le cadre de projets de recherche financés par le département de la Défense des États-Unis et poursuivi par le biais de contrats ultérieurs de la DARPA.

Ce compte rendu ultérieur est cohérent avec les références directes de la RFC 820 à la DARPA/IPTO, au DDN/PMO et à la réunion de septembre 1982. Il aide à expliquer pourquoi un inventaire technique mondial avait un centre administratif aux États-Unis et pourquoi la politique proposée distinguait les utilisations de recherche, de défense et commerciales.

Le GAO dit également qu'il n'a pas pu obtenir les contrats DARPA pertinents des années 1970 aux années 1990. Ses preuves contractuelles plus détaillées concernent des périodes ultérieures, et sa question juridique s'est posée des décennies après la RFC 790 et la RFC 820.

L'avis ne peut donc pas établir la clause d'un contrat manquant de 1981, les critères appliqués à une demande particulière ou la portée de l'autorité comprise par chaque entité. Le parrainage fédéral explique la capacité et le contexte institutionnel. Il ne prouve pas, par lui-même, la propriété des identifiants, le consentement universel ou la légitimité de chaque choix administratif.

La preuve primaire reste plus étroite. La RFC 790 nomme un coordinateur pour les attributions. La RFC 820 ajoute un accord d'agence, une division recommandée de l'espace de numéros, des responsabilités institutionnelles prospectives, une condition d'éligibilité à la recherche proposée et une note de mise en œuvre incomplète. L'histoire gouvernementale ultérieure corrobore l'environnement mais ne transforme pas ces déclarations en une charte complète.

Ce que les colonnes soutiennent finalement

La politique dans une liste d'adresses n'apparaît pas simplement parce que la liste distribue des identifiants avec différentes capacités techniques. Elle devient visible lorsque le document montre la classification, l'éligibilité, la transition, la responsabilité institutionnelle et les conséquences de s'appuyer sur un enregistrement commun maintenu.

La RFC 790 établit une interface de coordination concentrée. Plusieurs séries de numéros étaient publiées ensemble, les développeurs étaient dirigés vers un contact d'attribution nommé et les valeurs résultantes étaient présentées comme des informations opérationnelles courantes. Son tableau de réseau enregistre un ensemble mixte de réseaux de recherche, gouvernementaux, militaires, de données publiques et commerciaux mais ne donne aucun critère général de demandeur ni aucune division de la responsabilité d'attribution.

La RFC 820 ajoute une couche administrative plus articulée. Elle classifie les identifiants de réseau par utilisation, préserve les anciens numéros pendant les transitions, imprime des totaux d'attribution et énonce des allocations de catégorie recommandées. Elle propose des preuves liées aux passerelles pour les demandeurs de recherche, permet à un réseau de changer de catégorie sans renumérotation lorsque cela entraînerait des difficultés et imagine des attributions faites par plusieurs institutions dans le cadre d'un arrangement de suivi partagé.

Le même document empêche que ces recommandations soient confondues avec une pratique achevée. Les attributaires de défense et commerciaux restentTBDdans les tableaux numériques. Les attributions de travail ne correspondent pas à la distribution recommandée de classe A. La note de mise en œuvre finale dit que Postel coordonne toujours toutes les attributions.

Les tableaux résistent également à un récit distributif simple. La valeur 044 de la RFC 790 est en conflit interne. La RFC 820 répète quatre fois une adresse de classe C littérale et imprime des totaux d'allocation de défense de classe C incompatibles. Son résumé de 1 097 attributions est dominé par une plage BBN de 1 024 identifiants. Les entrées de transition peuvent compter le même réseau sous des numéros anciens et nouveaux. Ce sont des enregistrements opérationnels avec des problèmes éditoriaux et de comptage identifiables, pas un jeu de données propre de demandeurs.

Les documents soutiennent par conséquent l'inférence que la coordination des numéros de réseau impliquait plus qu'une transcription passive. L'unicité technique devait être protégée, mais l'attribution de catégorie, la gestion des transitions et la condition de préparation proposée nécessitaient un jugement administratif. Ce jugement opérait dans un cadre institutionnel soutenu par le gouvernement fédéral et, dans le texte examiné de la RFC 820, passait encore par un coordinateur de travail unique.

Ils soutiennent également une inférence moins centralisatrice. La RFC 820 n'assimilait pas le suivi partagé à une autorité exclusive d'attribution substantive. Son architecture recommandée permettait aux décisions de provenir de plusieurs institutions tandis qu'un organisme surveillait l'allocation combinée. La conception était incomplète, mais la distinction conceptuelle est présente.

L'incertitude restante n'est pas une qualification mineure. Les listes publiques ne contiennent aucune population de demandeurs, aucun compte de rejets, aucun historique de retraits, aucune série d'utilisation ni aucune raison pour chaque attribution. L'outil de recherche disponible identifie la correspondance potentiellement pertinente mais n'en révèle pas le contenu. Les documents ne peuvent pas montrer si le format compact résultait de la commodité, des limites de publication, de la convention héritée, du minimalisme délibéré ou d'une autre cause.

Les tableaux n'établissent pas non plus une doctrine de rareté mature. Ils montrent des espaces de classe finis, des valeurs réservées, des allocations de catégorie et des mouvements entre tailles d'adresse. Ils ne montrent pas que la rareté a motivé une attribution particulière ou qu'un demandeur a été refusé à cause d'elle. L'épuisement ultérieur des adresses a augmenté les conséquences des distributions précoces sans reconstruire leurs motifs originaux.

Ce qui survit, c'est une capacité administrative documentée avec des effets opérationnels réels. Les listes coordonnaient les valeurs, rendaient certaines attributions visibles, classifiaient les réseaux et aidaient à préserver la continuité pendant le changement. La dépendance à cet enregistrement pouvait rendre sa maintenance conséquente même si le responsable de l'enregistrement ne prétendait pas être l'auteur de la légitimité de chaque réseau.

Sous la lampe de lecture, la différence significative entre les deux documents n'est donc pas que la politique est soudainement entrée dans le tableau en 1983. C'est que la RFC 820 a rendu une plus grande partie de la machinerie administrative lisible: un accord, des catégories d'utilisation, des allocataires prospectifs, une recommandation d'éligibilité, des règles de transition et une admission que la mise en œuvre était en retard par rapport à la conception.

Cette machinerie peut être décrite sans attribuer de motifs cachés à ses opérateurs. Ses conséquences distributives peuvent être mesurées sans transformer les plages en demandeurs. Son autorité peut être examinée sans supposer qu'une colonne propre est une preuve de légitimité ou de dissimulation. La leçon la plus durable de l'archéologie des deux documents est qu'un inventaire technique peut être une preuve indispensable de ce qu'un système de coordination reconnaissait tout en restant une preuve incomplète de comment, pourquoi et par qui la reconnaissance a été décidée.