Résumé

  • RFC 1291 est une RFC informationnelle de décembre 1991. Elle proposait que les réseaux intermédiaires offrent des services techniques à leurs sites connectés et à leurs pairs ; elle ne définissait pas une norme Internet ni le déploiement de ces services.
  • Ses idées de meta-dns, swdist, timekeeper-x, nic et noc dessinent une architecture de proximité. Elles ne font pas d'un libellé local une preuve d'accès amont, d'autorité sur une source distante, de disponibilité, d'adoption ou de résultat pour l'utilisateur.

Une couche de service n'était pas une couche de souveraineté

RFC 1291 emploie « réseau intermédiaire » comme un terme générique pour des réseaux régionaux et comparables, dont les rôles évoluaient. Son modèle est un graphe : ces réseaux se relient les uns aux autres, relient à leur tour des campus ou des organisations, et les utilisateurs se trouvent sous les campus. Le modèle répartit des fonctions ; il ne transforme pas la couche du milieu en propriétaire de tout ce qui circule à travers elle.

Le texte voulait réduire le trafic inutile et augmenter la robustesse. C'est une ambition d'organisation, non un titre de maîtrise générale. Un service proche peut éviter un détour, fournir une information maintenue localement ou offrir un premier interlocuteur. Il dépend encore d'autres réseaux, d'autres opérateurs et d'autres sources de vérité. Lire les grands noms de services comme une promesse d'achèvement — DNS, distribution, temps, information, exploitation — serait précisément effacer les dépendances que le RFC décrit.

Publié en décembre 1991 comme document informationnel, RFC 1291 ne spécifie pas une norme Internet. Il atteste donc d'une proposition et de ses compromis. Il n'établit pas qu'un réseau donné ait exploité l'un de ces noms, qu'un campus s'y soit effectivement appuyé, ni qu'un utilisateur ait obtenu le bénéfice espéré.

meta-dns pouvait préserver un voisinage, pas remplacer la racine

Le cas DNS est le plus précis. RFC 1291 observe que des serveurs secondaires placés sur des réseaux physiques distincts peuvent améliorer la fiabilité. Mais il ajoute que la résolution vers l'extérieur d'un domaine exige encore la disponibilité des serveurs de niveau supérieur. Pour résoudre un nom d'un autre domaine, la chaîne vers la racine ou vers un niveau plus haut doit rester joignable.

La proposition est plus étroite : un réseau intermédiaire pourrait conserver au moins un serveur capable de répondre directement pour les domaines qui lui sont connectés. Si le réseau intermédiaire se trouvait isolé du reste d'Internet, une application pourrait encore résoudre les sites directement connectés et joignables. Le nom meta-dns servirait à localiser cette fonction dans le domaine.

Il s'agit d'une capacité de continuité locale, non de la reconstitution d'Internet. Une réponse locale ne rend pas la racine accessible. Elle ne rend pas disponible une destination externe. Elle ne prouve ni qu'un service nommé acceptera une connexion, ni que son contenu est actuel, ni qu'un lecteur recevra une réponse utile. La valeur de l'idée est de dire ce qui peut rester vrai pendant l'isolement sans prétendre que l'isolement n'a plus de conséquence.

Le nom lui-même doit être traité avec la même retenue. meta-dns est une convention de repérage. Il ne montre pas qu'un hôte existe, qu'il répond, que ses données sont à jour ou que sa sortie décide du statut d'une cible indépendante. Nommer une fonction aide à coordonner ; cela ne transfère pas vers cette fonction l'autorité tenue ailleurs dans la chaîne de résolution.

swdist indiquait une piste, pas un logiciel reçu

La discussion du logiciel public refuse elle aussi la promesse totale. RFC 1291 explique qu'un dépôt à jour de tous les paquets serait difficile, voire impossible, à cause du volume et de la vitesse de développement. Le coût économique des archives centrales compte également. Le document mentionne des archives populaires ainsi que des moyens de découverte, notamment Archie et Prospero.

Il recommande que le réseau intermédiaire fournisse des pointeurs à jour vers les hôtes de distribution, et préfère la découverte automatisée à une liste statique difficile à distribuer. Dans des conditions idéales, certains logiciels populaires ou significatifs pourraient être archivés et distribués localement ; mais le RFC qualifie la mesure de la popularité et de l'importance de discutable et la laisse à une évaluation ultérieure. Une entrée swdist pourrait présenter des alternatives : emplacement statique, pointeur vers Archie ou autre information de découverte, éventuellement au moyen d'un CNAME ou d'un TXT.

Une piste n'est pas un transfert. Un pointeur peut faire connaître un hôte ; il ne place pas le logiciel sur le disque du lecteur. Il ne prouve pas que l'hôte distant accepte l'accès, que la version est complète, que l'objet est intègre ou que la licence et la pertinence conviennent. Même une archive locale ne prouve pas qu'un utilisateur déterminé a reçu puis employé le paquet. Le RFC propose de garder la route de découverte utile, non d'abolir la différence entre la route, le dépôt et l'usage.

Les petits noms portaient des charges opérationnelles distinctes

Pour le temps, RFC 1291 propose au moins un serveur de strate 1 et deux de strate 2, avec des noms timekeeper-x classés selon préférence et précision. Il relie cette disposition à la fiabilité et à la charge, mentionnant la surcharge d'un serveur de strate 1 par trop de sites voulant s'y apparier. Pourtant le RFC ne prescrit aucun protocole particulier : tout protocole offrant une précision raisonnable pourrait être employé.

Cette réserve interdit de certifier l'heure à partir du nom. timekeeper-1 peut exprimer une préférence locale. Il ne prouve ni la synchronisation à une référence nationale, ni la joignabilité immédiate, ni la configuration correcte d'une strate, ni la synchronisation effective d'un client.

Les rubriques consacrées aux nouvelles et aux listes rendent visibles d'autres coûts. Les nouvelles consommaient disque, processeur et bande passante ; un réseau intermédiaire pouvait fournir un flux ou agir en transit afin de réduire une partie du stockage. Les listes ne disposaient d'aucun dépôt central ni d'une stratégie claire de distribution et de maintenance. Des exploseurs de listes pouvaient réduire la charge de l'émetteur et aider à diagnostiquer des problèmes ; cela ne prouve pas qu'un message est arrivé, qu'un responsable a agi, ou qu'un abonné a reçu le contenu.

Un banc d'essai diffusait une possibilité, pas une adoption

RFC 1291 voyait les réseaux intermédiaires comme de bons médias pour diffuser des idées et des technologies nouvelles, grâce à leurs relations avec les sites terminaux et les pairs. Des bancs d'essai coopératifs pourraient tester et déployer des techniques, fournir de l'aide et aider les sites à démarrer. Le texte dit cependant que l'interaction exacte entre réseaux intermédiaires n'était pas très claire et que la concurrence pour les membres la compliquait.

Cette incertitude est un fait, non une lacune qu'il faudrait combler par une fiction institutionnelle. Un banc d'essai permet un essai. Il ne décide pas qui adoptera, qui paiera, qui exploitera, qui portera une défaillance, ou si une technologie dépasse l'expérience. Une aide réduit peut-être le coût d'entrée d'un site, sans prendre en charge son déploiement final.

Les services d'information et d'exploitation conservent la même limite. Un NIC peut être un premier contact, tenir de l'information sur les sites directement connectés, publier une entrée nic et aider les utilisateurs. Des NOC peuvent être premiers contacts pour des problèmes, avec une entrée noc dans DNS, Finger ou un annuaire. Le RFC reconnaît qu'un annuaire statique peut être périmé ; les mécanismes distribués ne peuvent fournir une information correcte et actuelle que si les hôtes sont joignables au moment voulu. Une voie de contact n'est pas un incident résolu.

Sources et limites de preuve

Cet article s'appuie sur RFC 1291 — Mid-Level Networks: Potential Technical Services. La source étaye son statut informationnel, son graphe de réseaux intermédiaires, ses objectifs de robustesse et de réduction du trafic, les services proposés, le cas d'isolement DNS des domaines directement connectés, meta-dns, swdist, les noms de temps, les coûts et incertitudes signalés, et l'absence de discussion de sécurité. Elle n'établit ni déploiement, ni hôte actif, ni joignabilité amont, ni résolution réussie, ni livraison de logiciel, ni heure exacte, ni flux économique, ni adoption, ni données NOC actuelles, ni autorité, permission, incident résolu ou résultat utilisateur.