Sujet
Preuves fondées sur les ressources réseau
Au sein de la facette Sujet, la veille thématique Preuves fondées sur les ressources réseau rassemble des articles qui partagent un même sujet, un même signal ou un même thème de suivi. Cette page offre aux lecteurs un parcours plus riche à travers les reportages associés, les preuves issues de sources publiques, les acteurs du marché et les implications pour l’infrastructure, avec suffisamment de contexte pour comprendre pourquoi le sujet compte pour les mouvements d’entreprises, les décisions de gouvernance, l’exposition régionale et le risque opérationnel. Les lecteurs peuvent comparer les signaux récurrents, les organisations concernées, les preuves publiques, le contexte du marché, la continuité de service, les achats, la concurrence, la conformité et les questions de planification stratégique liées au sujet, au lieu de se contenter d’une liste succincte d’articles correspondants. Elle explique ce que couvre le sujet, quels acteurs ou politiques de l’infrastructure sont impliqués, quelles preuves étayent la couverture et pourquoi le sujet peut être important pour les opérateurs, les clients, les investisseurs et les lecteurs de politiques publiques.

IETF
La clé maîtresse a tourné. Les anciennes associations pouvaient encore parler
PSP conserve deux clés maîtresses côté réception. Quand l’une cesse d’être active, les nouvelles associations passent à l’autre, mais les anciennes peuvent continuer à produire des clés valides. Une rotation change donc le futur; elle n’efface pas encore le passé. Le projet qui…

IETF
La liste était exacte. Encore fallait-il que la configuration soit entière
IntraSAV propose de remplacer l’inférence par une autorisation explicite des préfixes sources. La promesse de zéro erreur dépend toutefois d’un fait que chaque interface doit encore prouver: la configuration reçue était-elle complète et actuelle ?

Histoire d'Internet
La même zone était sûre ici et non sécurisée ailleurs : RFC 3090
En 2001, demander si une zone DNS était « sûre » ne suffisait déjà plus. Il fallait savoir quel résolveur posait la question, quelle racine de confiance il connaissait et quel chemin il avait suivi. RFC 3090 a donné des mots à cette relativité: une zone signée pouvait former un…

Histoire d'Internet
Le serveur racine indiquait une piste, pas la réponse LDAP : RFC 3088
Dans un annuaire réparti, le premier serveur peut connaître le prochain relais sans détenir la fiche recherchée. En 2001, l’expérience OpenLDAP a rendu cette frontière visible: son service racine consultait DNS et renvoyait des URL LDAP, puis laissait l’annuaire désigné répondre.

Dossier
Tideo Administration : un enregistrement qui ne bouge pas, même après la disparition du réseau
Le résumé de veille Tideo Administration: un enregistrement qui ne bouge pas, même après la disparition du réseau explique le développement, les preuves publiques disponibles, les organisations concernées, le contexte régional, l’exposition au marché et les conséquences possibles…

Histoire d'Internet
L’URI choisissait le menu vocal, sans authentifier l’appelant : RFC 3087
En 2001, un appel SIP pouvait parvenir à une messagerie sans emporter tous les indices fiables qui guidaient les anciens commutateurs. RFC 3087 a confié au destinataire courant de la requête le choix du premier état de l’application. L’adresse donnait une consigne de service…

IETF
L’en-tête de débogage racontait chaque étape sans pouvoir en prouver aucune
Un nouveau brouillon DKIM2 propose aux testeurs une piste médico-légale commune à l’intérieur du message. Sa précision aide à enquêter, mais son autorité est volontairement nulle.

Entreprises services cloud Europe et Moyen-Orient
NovaCloud-Hosting : six semaines après la panne FFM2, une empreinte registre figée entre annonces et routage
Six semaines se sont écoulées depuis que NovaCloud-Hosting, la marque réseau de la société portugaise Tech Tide Portugal Unipessoal LDA, a déclaré résolu l'incident majeur qui avait paralysé son site de Francfort FFM2 du 20 juillet au 8 août 2026. La lecture croisée des pages…

IETF
Dix minutes de maximum ne racontent pas dix minutes de Wi-Fi
Un serveur RADIUS reçoit une valeur de débit accompagnée de `MAX(10m)`. La chaîne est valide, la fenêtre est explicite et la donnée semble plus sérieuse qu’un simple instantané. Pourtant, le maximum ne dit ni combien de temps le débit a été tenu, ni quels paquets ont servi au…

Histoire d'Internet
Le serveur avait poussé les règles. La reconnexion devait encore réconcilier ce que l’équipement avait gardé : RFC 3084
RFC 3084 organisait le provisioning de politiques comme une conversation à états partagés: une décision groupée, un accusé d’exécution, un retour à l’état antérieur en cas d’échec. La coupure révélait pourtant la limite du modèle. Le serveur et l’équipement pouvaient tous deux…

IETF
Le rafraîchissement s’est terminé. Le collecteur ignorait encore si la RIB était entière
Une proposition BMP permet de réparer une seule vue de routage sans interrompre toutes les sessions surveillées. Son marqueur final ferme la retransmission, mais ne certifie pas à lui seul qu’aucune route n’a disparu en chemin.

Histoire d'Internet
Le numéro de révision ordonnait les NewsItems ; il ne les livrait pas : RFC 3085
Un même NewsItem pouvait être conservé sur plusieurs serveurs. En 2001, RFC 3085 lui a donné un URN unique et un numéro pour ordonner ses versions. Le texte distinguait aussi la mise à jour d’un article du remplacement de ses seules métadonnées de gestion, sans promettre qu’un…

Histoire d'Internet
Le câble chiffrait le trafic. Son plan de gestion pouvait encore désactiver la confidentialité : RFC 3083
RFC 3083 a rendu la confidentialité DOCSIS observable, réglable et réinitialisable par SNMP. Cette visibilité aidait le diagnostic, mais elle ouvrait une seconde frontière de sécurité: l’interface qui regardait les clés pouvait aussi relancer l’autorisation, modifier les délais…

IETF
Le tableau de bord disait SRv6. L’arbre multicast parlait encore PIM
Une route vers la source peut suivre Flex-Algo 128 dans un réseau SRv6 sans qu’aucune branche multicast soit décrite par une liste de SID. Entre le voyant vert de l’architecture et la vidéo reçue se trouvent un calcul IP, un contrôle RPF, un état `(S,G)`, des interfaces de…

IETF
Le SID a choisi la voie. Il n’a pas prouvé qu’elle existait
Une nouvelle révision du travail SPRING donne au SID une portée matérielle: choisir non seulement un chemin, mais aussi une part de bande passante, de mémoire tampon et de files. Cette portée rend l’intention visible; elle ne transforme pas l’identifiant en preuve de livraison.

Histoire d'Internet
TCP était fiable. Un canal pouvait encore affamer les autres : RFC 3081
RFC 3081 a placé une session BEEP sur une seule connexion TCP, puis a traité le problème que la fiabilité du transport ne résolvait pas: un canal applicatif lent pouvait retenir la capacité commune et priver ses voisins de progrès. La réponse fut un crédit propre à chaque canal…

IETF
L’arbre s’est tu. L’alarme est revenue par une autre route
Un projet du groupe BIER permet à une extrémité active de signaler spontanément une perte BFD. Le retour emprunte volontairement un chemin unicast distinct de l’arbre multicast: il confirme un témoin, pas la réparation de l’arbre.

Dossier
Le SID a trouvé la voie. Il n’a pas prouvé que la capacité l’attendait
Dans un réseau segment-routé, la bonne étiquette peut conduire le paquet vers le bon ensemble de files et de bande passante. Cette réussite de sélection ne dit pourtant rien, à elle seule, sur l’état réel de ces ressources au troisième routeur, sur un repli en best effort ou sur…

FAI régionaux d'Asie-Pacifique
XEONFIBER TECHNOLOGY : deux lignées APNIC au même nom, des relevés de routage contradictoires et aucun registre qui nomme une licence de télécoms
Le résumé de veille XEONFIBER TECHNOLOGY: deux lignées APNIC au même nom, des relevés de routage contradictoires et aucun registre qui nomme une licence de télécoms explique le développement, les preuves publiques disponibles, les organisations concernées, le contexte régional…

IETF
Le lien a accepté de dormir. Sa disparition n’était pas encore sûre
Un nouveau brouillon de l’IETF organise la mise en veille bilatérale d’une ressource d’ingénierie de trafic. Son garde-fou essentiel tient en une distinction: la réussite d’un échange de signalisation ne prouve ni l’état physique du lien ni sa capacité à revenir.
