Résumé

  • RIPE Database 1.124 a été déployée en production le 27 août 2026 avec une modification indiquant que le serveur NRTMv3 doit ignorer les objets invalides.
  • Écarter un objet inutilisable peut préserver la disponibilité, mais un flux qui avance ne prouve pas, à lui seul, que le miroir contient tout ce que le serveur faisant autorité a examiné.
  • Les documents publics ne précisent ni le nombre d’objets concernés, ni leurs classes ou leurs sources, ni la règle de validation, le traitement des numéros de série ou la possibilité d’une réémission.
  • Un reçu d’omission respectueux de la vie privée pourrait enregistrer la frontière du flux, la classe, la version de la règle, la famille de motif, le nombre, la décision et l’état de réconciliation sans divulguer l’objet rejeté.

Le numéro de série avance, mais que sait le miroir ?

Le 27 août, la version 1.124 de RIPE Database est entrée dans l’environnement de production. Parmi plusieurs changements, la note de version contient une phrase brève : le serveur NRTMv3 doit ignorer les objets invalides. Elle ne décrit ni incident, ni plainte d’opérateur, ni défaut de routage. Elle décrit un comportement du logiciel en service, ce qui suffit pour déplacer la frontière de preuve.

Un miroir NRTMv3 commence avec un export de la base et le numéro de série correspondant, puis reçoit les changements en temps quasi réel. La documentation de RIPE invite l’opérateur à conserver ce point de départ et à vérifier que le numéro maximal de la copie dépasse celui de l’export. Ce contrôle montre que la réplication progresse. Il ne démontre pas nécessairement que chaque objet considéré par le serveur a été livré.

Si une mise à jour faisant autorité contient un objet que le serveur juge invalide, la version 1.124 prévoit désormais qu’il puisse être écarté afin que les changements suivants continuent de circuler. Les sources examinées ne disent pas ce que faisait précisément la version antérieure, à quel stade intervient le test, ni si un objet a effectivement été ignoré depuis le déploiement. Il serait donc faux de transformer cette modification en récit d’incident.

La conséquence plus étroite est néanmoins réelle. L’absence d’un objet dans une copie peut signifier qu’il n’a jamais existé, qu’il a été supprimé, que le serveur ne l’a pas émis, que le transport a échoué, que le client l’a refusé ou qu’un filtre local l’a retiré. Quand le serveur peut choisir l’omission, la continuité du flux et la complétude de la copie deviennent deux affirmations distinctes.

« Invalide » dépend d’une règle et d’une époque

Dans une base de registre accumulée pendant des décennies, l’invalidité n’est pas toujours une propriété simple et intemporelle. La documentation combinée de RIPE reconnaît que de nombreux objets présentent une syntaxe invalide au regard des règles actuelles. Un objet ancien peut précéder une contrainte plus récente tout en restant intelligible. Un autre peut être impossible à analyser sans ambiguïté. Un troisième peut contenir des données qu’il ne faut pas redistribuer.

Ces situations ne méritent pas la même décision. Une structure illisible, un conflit avec une règle héritée, une restriction de confidentialité et une panne de traitement interne n’appellent ni la même alerte ni le même remède. Selon le cas, l’objet peut être mis en quarantaine, transformé sans risque, exclu durablement ou réémis après correction.

Le projet NRTMv4 de l’IETF fournit une comparaison utile : il distingue les objets ininterprétables de ceux qui s’écartent d’une règle tout en restant compréhensibles, et demande une application cohérente des restrictions aux instantanés et aux deltas. Mais ce texte reste un Internet-Draft consacré à un autre protocole. Il ne prouve rien sur l’implémentation du saut dans NRTMv3.

La leçon porte sur la version de la règle. Si un objet est écarté par l’analyseur de la version 1.124 puis accepté par une version ultérieure sans modification de son contenu, sa situation opérationnelle a changé parce que la règle a changé. Sans identifiant de règle, le miroir ne peut pas distinguer une correction de l’objet d’une nouvelle interprétation du même objet.

Préserver la disponibilité est un argument sérieux

Le meilleur argument en faveur du saut est pratique. Un enregistrement défectueux ne devrait pas bloquer tous les changements valides qui le suivent. Arrêter un service partagé au premier objet impossible à sérialiser agrandirait le rayon d’un défaut local. Les opérateurs utilisent les miroirs pour leurs recherches, leurs outils de politique de routage, leurs vérifications et leur résilience locale ; retarder tout le flux peut être plus dangereux que circonscrire l’exception.

Forcer la publication du contenu rejeté serait également une mauvaise réponse. Ce contenu peut comporter des données personnelles, une structure dangereuse pour certains clients ou des éléments qui ne doivent pas être distribués. Une exigence de transparence ne doit pas recréer le défaut ni exposer une personne.

Il ne faut pourtant pas choisir entre envoyer l’objet défectueux et garder le silence. Le serveur peut continuer à émettre les changements valides tout en déclarant, dans un enregistrement séparé et minimal, qu’une omission a eu lieu. La disponibilité demeure ; l’exception devient observable.

Cette séparation respecte une coordination mince. RIPE NCC conserve la maîtrise de la validation et de la réparation dans la base faisant autorité. Le miroir décide de son alerte, de sa quarantaine ou de sa resynchronisation. La couche commune ne porte que les faits nécessaires pour distinguer une omission volontaire d’une perte extérieure.

Quatre surfaces, quatre responsabilités

La base faisant autorité décide de l’acceptation, de la conservation et de la correction de l’objet. Elle voit le contenu et le résultat complet de validation. Tout n’a pas à être public, mais c’est là que naît la preuve fiable du défaut.

Le serveur NRTMv3 contrôle l’émission. Sa question est plus étroite : cet état peut-il être transmis sous une forme que le protocole et le destinataire peuvent traiter ? La version 1.124 rend « ignorer » explicite comme résultat possible. Cette décision devrait donc être enregistrée comme un état, et non uniquement comme une absence d’octets.

Le client contrôle l’ingestion. Il peut appliquer ses propres filtres, refuser une entrée, conserver un bac de quarantaine ou avertir un opérateur. Une exclusion côté client n’est pas une omission côté serveur, même si les deux aboutissent à la même réponse locale : objet absent.

Enfin, l’utilisateur d’un générateur de filtres ou d’un outil de recherche peut ne jamais voir les journaux de réplication. Il risque alors de transformer un manque d’information en certitude. RIPE NCC n’a pas à dicter la politique de routage de cet utilisateur ; il lui revient seulement de rendre la transition qu’il contrôle distincte des pannes et choix situés ailleurs.

Ce que les sources ne permettent pas d’affirmer

Aucune source consultée ne publie un nombre d’objets ignorés. Aucune ne nomme une source telle que RIPE ou RIPE-NONAUTH, une classe d’objet, une version de règle ou une famille de motifs. La note ne précise pas si l’objet consomme un numéro, si le client reçoit un commentaire, si le serveur tient un journal privé ou si une correction déclenche une réémission.

Les documents ne prouvent pas davantage qu’un miroir soit devenu incomplet, qu’une route ait été filtrée ou qu’un opérateur ait subi un dommage. La présentation de RIPE 92 éclaire la logique des instantanés, deltas, notifications, sessions et reprises de NRTMv4 ; elle ne complète pas le dossier factuel d’une version NRTMv3 déployée plus tard.

Ces inconnues imposent une recommandation modeste. Il ne faut publier ni la clé de l’objet, ni son corps, ni des données personnelles, et il serait prématuré d’imposer la même réaction à toutes les causes. Le premier besoin est seulement une déclaration stable de la décision prise par le serveur.

Le reçu minimal

Pour chaque intervalle de publication borné, RIPE NCC pourrait fournir un reçu agrégé ou événementiel comprenant : la source et la version du protocole ; la position ou l’intervalle de série compatible avec le comportement réel ; la classe sans nécessairement révéler la clé ; l’identifiant et la version de la règle ; une famille de motifs ; le nombre d’omissions ; la décision — quarantaine, exclusion, transformation, attente ou correction — ; l’état de réémission ou de rapprochement ; enfin l’horodatage et l’historique des corrections.

Si la combinaison d’une classe et d’un intervalle trop étroit crée un risque de divulgation, les nombres peuvent être retardés ou regroupés. Un identifiant stable peut permettre aux opérateurs autorisés de demander davantage en privé. La trace publique doit montrer qu’une décision a été prise, pas exposer la matière sensible sur laquelle elle repose.

Le reçu doit aussi avoir une fin. Lorsqu’une anomalie est corrigée, il faut savoir si l’objet a rejoint un flux ultérieur, uniquement un nouvel export, s’il demeure exclu ou s’il a été supprimé de la base faisant autorité. Sans cet état de clôture, le miroir reste condamné à deviner.

Le code en production mérite une preuve en production

Une note de version montre qu’un comportement a changé. Elle ne remplace pas le relevé produit quand ce comportement s’exerce. La version 1.124 indique qu’un objet peut être ignoré, mais elle ne permet pas encore à l’opérateur d’associer une omission précise à une règle et à une issue.

Il ne faut pas annuler l’amélioration pour conserver une illusion de complétude. Il faut rendre la complétude dégradée visible : préserver la disponibilité, protéger le contenu sensible, nommer la règle et offrir une voie bornée de rapprochement. Un numéro qui avance prouve le mouvement. Un reçu permettrait de dire ce qui a avancé avec lui — et ce qui est resté de l’autre côté.

Sources