Résumé

  • En 2001, RIPE NCC a déplacé les mises à jour de RIPE-181 vers RPSL en plusieurs phases : démarrage le 23 avril, changement de l’adresse principale le 14 mai, puis fermeture de la conversion le 15 octobre.
  • Les archives relient Andrei Robachevsky à cette transition en tant que Database Group Manager : il a présenté les nouveaux comportements de requête en 2000 et signé, en avril 2001, l’annonce de la première phase achevée.
  • Convertir un objet modifie la représentation conservée par le registre. Cela ne prouve ni la propriété d’un bloc d’adresses, ni l’annonce d’une route, ni la livraison de paquets.

Deux adresses, deux contrats de mise à jour

L’avis du 14 mai donne une lecture opérationnelle du changement. auto-dbm n’accepterait plus que RPSL. auto-181 continuerait à recevoir du RIPE-181 et à le convertir, jusqu’à la date annoncée du 15 octobre. auto-rpsl acceptait également les mises à jour RPSL, et les mêmes distinctions s’appliquaient à la base de test.

Il fallait donc demander non seulement si « la base était migrée », mais quel format une application donnée pouvait envoyer à quelle adresse, et jusqu’à quand. Un générateur conservé en RIPE-181 n’avait pas les mêmes conditions qu’un client déjà adapté à RPSL. Les avis publics ne mesurent ni le nombre de scripts à reprendre ni l’existence d’une panne pour chaque utilisateur. Ils montrent toutefois un changement que les participants pouvaient vérifier : adresses, formats, restrictions et échéance étaient explicités.

Le message du 23 avril décrivait déjà la nouvelle version comme active et indiquait que les objets existants avaient été automatiquement convertis en RPSL puis chargés. Mais la conversion des données n’avait pas encore supprimé l’ancien chemin. Pendant cette première phase, auto-dbm acceptait encore du RIPE-181 sous restrictions : attributs vides ou mal orthographiés interdits, authentification PGP non prise en charge sur cette voie, et règles d’autorisation RPSL maintenues. auto-rpsl recevait directement le nouveau format. C’était donc une transition de règles d’exploitation, pas seulement un changement de syntaxe.

Une requête choisit aussi son niveau de preuve

En août 2000, Robachevsky, alors Database Group Manager, présentait les changements de l’interface v3 et sollicitait les retours de la communauté. Les exemples distinguaient deux demandes souvent confondues : l’exact-match renvoyait l’objet correspondant à la plage saisie ; la recherche moins spécifique renvoyait la plus petite plage plus large qui la contenait. L’option -K réduisait la réponse aux clés principales. Une requête de sources décrivait les bases disponibles et leurs informations de réplication, tandis que les recherches inverses pouvaient parcourir des attributs de contact.

Ces fonctions ne valident pas la vérité d’un objet. Elles déterminent quelle question le client pose et ce qu’il reçoit. Un résultat moins spécifique ne répond pas à la même question qu’une correspondance exacte. Une réponse réduite facilite parfois le traitement automatique, mais peut masquer du contexte. Des informations de réplication décrivent une interface et une plage de numéros de série ; elles ne sont pas une mesure complète des routes visibles dans le réseau mondial. Une modification d’interface peut ainsi affecter les outils de surveillance sans que le contenu d’un objet paraisse radicalement nouveau.

Les minutes de RIPE 38, marquées comme projet, attribuent à Robachevsky une présentation de vingt minutes sur la migration. Elles notent que les utilisateurs de requêtes, les utilisateurs de mises à jour, les scripts et les miroirs quasi en temps réel étaient concernés par RPSL, le contrôle d’accès, le format de base et le protocole de réplication. Comme les minutes sont un brouillon, elles attestent ce que le projet consigne de la réunion, non que chaque échéance annoncée avait déjà été réalisée. Les avis ultérieurs et le rapport annuel établissent mieux l’achèvement.

La compatibilité a un coût identifiable

La fenêtre de six mois répartissait les adaptations. Le registre devait faire fonctionner la conversion et expliquer les règles. Les responsables d’objets devaient décider quand modifier leurs générateurs de mise à jour. Les opérateurs de miroirs devaient contrôler le format et la réplication. Les clients devaient distinguer l’exact-match d’une réponse plus large. Les sources ne chiffrent pas ce travail et ne recensent pas toutes les implémentations touchées ; elles rendent néanmoins visibles les points contrôlés par l’opérateur : syntaxe acceptée, vérifications d’autorisation, noms d’adresses et date de fermeture de la passerelle.

C’est une manière concrète de mesurer la responsabilité d’un registre partagé. Un chargement de données réussi ne suffit pas. Les utilisateurs doivent savoir quelle représentation envoyer, quelles règles d’authentification s’appliquent, comment interpréter les résultats, comment suivre les miroirs et quand une solution transitoire disparaîtra. Ces engagements relèvent du service. Ils ne transfèrent pas au registre la propriété des ressources décrites, ni un pouvoir politique sur les organisations qui s’en servent.

RFC 2622 clarifie une autre frontière : le document définit RPSL pour exprimer des politiques de routage et décrit le rôle de l’objet mainteneur dans l’autorisation de modifications. Il nomme Alaettinoglu, Villamizar, Gerich, Kessens, Meyer, Bates, Karrenberg et Terpstra ; Robachevsky n’en fait pas partie. Son rôle documenté dans une migration ne doit pas devenir une attribution de la création du langage ou de la RFC.

L’objet du registre n’est pas la route observée

Une inscription dans une base, un objet de politique dans un registre Internet de routage et une observation BGP répondent à des questions différentes. Après conversion, un objet montre ce que la base RIPE conservait alors. Un objet RPSL exprime une politique déclarée. Un collecteur de routes peut montrer qu’une annonce BGP a été vue depuis un point de mesure, à un moment donné. Aucun ne remplace les deux autres. L’enregistrement seul ne démontre ni l’accessibilité actuelle, ni le parcours des paquets, ni la propriété légale, ni l’application de la politique sur chaque routeur.

Cette séparation protège les utilisateurs autant que l’institution. Une inscription qui n’est plus à jour appelle une enquête sur les données et les autorisations. Une disparition de route demande des observations de routage distinctes. Une contestation sur le droit de modifier l’objet n’est pas résolue par une conversion de format. La portée de la migration est plus précise : elle rend visibles les interfaces et les responsabilités du registre, sans confondre le système de tenue des dossiers avec les ressources et le réseau qu’il documente.

Une attribution à garder à sa juste mesure

Les archives permettent une biographie circonscrite. En août 2000, Robachevsky signe un message de travail comme Database Group Manager et expose les changements de requête de v3. En avril 2001, il signe l’avis qui décrit la première phase achevée, la conversion automatique et les limites temporaires de la voie RIPE-181. Le projet de minutes de RIPE 38 le désigne comme présentateur prévu. Ces documents montrent un responsable qui communique une transition et sollicite les utilisateurs ; ils ne prouvent pas qu’il a écrit le logiciel de conversion, décidé seul chaque règle ou vérifié chaque objet.

La limite fait partie du récit. Administrer le système qui conserve des références publiques crée une obligation d’accès prévisible et de changement traçable. Cela ne fait pas de l’opérateur le propriétaire des ressources enregistrées. Pour cette migration, les éléments les plus solides sont les dates, les interfaces et les règles publiées ; les coûts individuels, l’adoption universelle et l’état actuel d’une route restent hors de portée des archives citées.

Sources