Résumé

  • RFC 1261 annonçait le transfert du Network Information Center de SRI International à Government Systems Inc. au 1er octobre 1991. Pendant cinq jours, aucune modification WHOIS et aucune action d’enregistrement ne devaient être acceptées afin de transférer la base maître.
  • La persistance d’un hôte, d’une boîte HOSTMASTER, d’un service d’aide ou d’une apparence en ligne établit une continuité de contact. Elle n’établit ni qu’une demande est devenue une inscription, ni que la nouvelle autorité peut déjà modifier l’état maître.

Ce que les utilisateurs voyaient, et ce que le registre devait garder

Le Network Information Center réunissait des fonctions de natures différentes. Il répondait aux utilisateurs, distribuait des RFC et des Internet-Drafts, offrait des services d’information et participait à l’enregistrement des réseaux et des noms de domaine de premier niveau. Dans l’usage quotidien, ces activités pouvaient sembler former un même service. Pour une transition, elles n’avaient pourtant ni le même rythme ni la même preuve d’accomplissement.

RFC 1261 fixait le transfert du NIC de SRI International, à Menlo Park, vers Government Systems Inc., à Chantilly, au 1er octobre 1991. Le texte promettait de conserver l’essentiel : SRI devait continuer à répondre aux appels et aux demandes jusqu’au 30 septembre; GSI devait assurer les activités d’enregistrement, les services d’information, le Help Desk et la diffusion des archives RFC et Internet-Draft. Le lecteur est naturellement invité à imaginer une relève ordonnée.

Mais le mémo introduit une précaution plus instructive que la promesse. Les services en ligne devaient, sauf quelques exceptions, paraître les mêmes depuis le nouvel hôte. Les exceptions tenaient au passage de TOPS-20 à SunOS; RFC 1261 nommait même le Sun 470 SPARCserver sous SunOS 4.1. Cette continuité d’apparence était utile : elle réduisait la charge cognitive des usagers. Elle ne signifiait pas que toutes les opérations administratives pouvaient être menées sans interruption au-dessous de cette apparence.

Un écran familier décrit un point d’accès. Une base maître décrit un état auquel des décisions doivent être appliquées. Entre les deux, il y a l’autorité de mutation : la capacité de décider qu’une demande relative à un numéro de réseau ou à un nom de domaine entre effectivement dans le registre. RFC 1261 rend cette couche visible parce qu’il accepte de l’interrompre explicitement.

Cinq jours sans écriture

Du 26 au 30 septembre, la base WHOIS ne devait pas être modifiée. Toutes les actions d’enregistrement étaient suspendues. La raison donnée était le transfert de la base maître vers GSI; les activités d’enregistrement devaient reprendre le 1er octobre.

Cette suspension ne constituait pas un échec du service. C’était au contraire un choix de gouvernance des données. Le NIC refusait de faire comme si une base à déplacer pouvait rester simultanément un lieu d’écriture indifférencié pour deux régimes opérationnels. La continuité pour l’usager était organisée autour des canaux; la cohérence de l’état était organisée autour d’une pause déclarée.

Cette distinction permet de ne pas surestimer les événements qui surviennent pendant une migration. Une lettre peut être reçue. Un fax peut parvenir à la nouvelle adresse. Un message électronique peut atteindre HOSTMASTER ou REGISTRAR à NIC.DDN.MIL; SRI pouvait le rediriger vers GSI selon les cas. Un agent peut même expliquer la procédure. Aucun de ces faits ne prouve qu’une écriture a été acceptée dans la base maître. Ils décrivent une réception, un routage ou une assistance, non une décision enregistrée.

Le texte répartissait précisément les voies : à partir du 26 septembre, le courrier et le fax devaient aller vers GSI, tandis que les demandes électroniques continuaient à employer les boîtes existantes. Cela évitait d’abandonner les requérants au moment du transfert. Mais la conservation de l’adresse de messagerie ne transformait pas le routage en droit d’écrire. Une demande peut survivre à son chemin; son effet dépend encore de l’autorité qui traitera la base après la reprise.

Une promesse n’est pas une preuve rétrospective

RFC 1261 emploie le futur et l’intention avec retenue. DISA et GSI feraient tout leur possible pour une transition régulière et rapide; les utilisateurs devraient être peu affectés. Ces phrases sont importantes comme engagements publics. Elles ne sont pas un procès-verbal démontrant que chaque enregistrement a été transféré sans erreur, que chaque demande a reçu une réponse à temps ou que personne n’a subi de rupture.

La différence compte particulièrement pour un registre. La présentation d’un service peut demeurer stable tandis que la garde du fait modifiable passe d’une organisation à une autre. Pour prouver qu’une modification est devenue effective, il faut une trace plus précise : la demande reçue, sa mise en attente éventuelle, l’autorité qui l’a examinée, la version maîtresse modifiée et le résultat communiqué. Un nom d’hôte qui répond ne remplace aucune de ces traces.

L’histoire du NIC offre donc une méthode de lecture plutôt qu’une leçon de nostalgie. Elle sépare les promesses d’expérience, les chemins de demande, les surfaces compatibles et le registre qui fait foi. Elle refuse que l’on appelle « continuité » un seul de ces éléments lorsque l’autre est précisément suspendu.