Aller au contenu principal

Type de contenu

Research

Dans la facette Type de contenu, les articles de type Research de BTW.MEDIA sont regroupés selon un même format éditorial, afin de permettre aux lecteurs de comparer briefings, profils, notes de risque, analyses de marché et reportages d'événements sans mélanger différents types de preuves. Cette page explique comment ce type de contenu met en perspective les événements liés à l'infrastructure Internet, les mouvements d'entreprises, les décisions de gouvernance, les signaux opérationnels et les preuves publiques sur l'ensemble du site. Les lecteurs peuvent ainsi identifier les acteurs ou systèmes d'infrastructure les plus fréquents, comprendre comment la qualité des sources modifie l'interprétation et déterminer si le contenu relève d'un profil durable, d'un événement urgent, d'un signal de marché stratégique ou d'une évolution de gouvernance. Le résultat est une page de recherche utile aux opérateurs, investisseurs, clients, analystes et décideurs publics qui doivent comprendre les conséquences, le calendrier et les preuves qui sous-tendent des formats d'articles similaires.

Le correctif temporaire avait désormais son propre budget permanent

IETF

Le correctif temporaire avait désormais son propre budget permanent

Le réflecteur fonctionnait, les keepalives maintenaient le mapping et les incidents baissaient. C’est précisément ainsi qu’un contournement peut cesser d’être provisoire: sa réussite masque le coût de la dépendance et retire toute urgence à sa sortie.

2 oct. 2026
La relance a réussi et effacé la panne qui comptait

IETF

La relance a réussi et effacé la panne qui comptait

Une requête DNS graissée échoue, la relance ordinaire répond, puis le journal ne conserve que le succès final: le service est rétabli, mais la preuve d’ossification a disparu.

2 oct. 2026
Le verrou le plus fort était proposé. L’attaquant l’effaça avant le choix : RFC 3329

Histoire d'Internet

Le verrou le plus fort était proposé. L’attaquant l’effaça avant le choix : RFC 3329

La première liste de sécurité devait circuler avant que les deux pairs aient choisi le moyen de la protéger. Une suppression suffisait alors à transformer une capacité forte en option prétendument absente. RFC 3329 n’a pas protégé ce premier instant; il a exigé qu’un reçu…

2 oct. 2026
REGISTER prenait fin ; son chemin servait ensuite : RFC 3327

Histoire d'Internet

REGISTER prenait fin ; son chemin servait ensuite : RFC 3327

La liaison répond à « où joindre l’UA ? »; elle ne répond pas à « par quels relais devra passer la prochaine requête ? ». RFC 3327 a donné à ces deux questions des réponses distinctes: le registrar gardait le Contact, tandis qu’un Path ordonné accompagnait cette liaison pour…

2 oct. 2026
Le registraire connaissait le contact, mais pas encore le chemin pour l’atteindre : RFC 3327

Histoire d'Internet

Le registraire connaissait le contact, mais pas encore le chemin pour l’atteindre : RFC 3327

Enregistrer une adresse et savoir lui livrer le prochain appel sont deux opérations différentes. Au début de SIP, une inscription pouvait réussir tout en perdant, dès la réponse envoyée, la chaîne de mandataires indispensable pour revenir vers le terminal. RFC 3327 a donné une…

2 oct. 2026
Le cache avait mémorisé la réponse, pas le consentement

IETF

Le cache avait mémorisé la réponse, pas le consentement

Un client qui n’a jamais autorisé ECS peut recevoir une réponse adaptée au réseau d’un autre utilisateur si le résolveur conserve les données sans conserver leur provenance.

2 oct. 2026
Le repli a sauvé la requête. Il a aussi effacé la panne du protocole

IETF

Le repli a sauvé la requête. Il a aussi effacé la panne du protocole

Le navigateur a abandonné ECN, refait un SYN ordinaire et chargé la page. La RFC 3360 oblige à conserver l’autre récit: un équipement de chemin avait peut-être transformé son ignorance de deux bits en décision attribuée au serveur.

2 oct. 2026
Chez RIPE, le flux d’updates de RRC12 s’est grippé après un afflux venu de DE-CIX

Récits

Chez RIPE, le flux d’updates de RRC12 s’est grippé après un afflux venu de DE-CIX

RIPE NCC indique qu’un volume inhabituellement élevé de messages BGP envoyé par un pair de DE-CIX a fait expirer à répétition le processus chargé de publier les fichiers de RRC12. Lors de la vérification, l’archive s’arrêtait encore à 01 h UTC le 2 octobre.

2 oct. 2026
Le téléphone cessa de sonner ; le protocole devait conserver la raison : RFC 3326

Histoire d'Internet

Le téléphone cessa de sonner ; le protocole devait conserver la raison : RFC 3326

Une annulation peut raconter deux histoires opposées tout en produisant exactement le même silence. RFC 3326 a donné à SIP un moyen de transporter l’événement déclencheur sans confondre cette explication avec la commande qui arrêtait l’appel.

2 oct. 2026
John Curran et l’épreuve de résilience d’ARIN en 2019

Dirigeants

John Curran et l’épreuve de résilience d’ARIN en 2019

En décembre 2019, une panne de stockage a neutralisé le basculement prévu pour les machines virtuelles d’ARIN. Le site public et l’application ARIN Online ont été rétablis à des heures différentes. Les comptes rendus qui ont suivi montrent comment l’organisation a rendu les…

2 oct. 2026
Le résolveur a ignoré le serveur qui répondait encore

IETF

Le résolveur a ignoré le serveur qui répondait encore

La délégation contenait un nouveau type censé remplacer NS, ainsi qu’un ancien enregistrement NS parfaitement joignable. Le résolveur a écarté ce dernier. Ce refus n’était pas une panne de repli: c’était précisément la règle de sécurité choisie par le protocole.

2 oct. 2026
Le CANCEL portait la cause ; SIP exécutait toujours l’annulation : RFC 3326

Histoire d'Internet

Le CANCEL portait la cause ; SIP exécutait toujours l’annulation : RFC 3326

Quand une branche répond à un appel forké, le proxy peut interrompre les autres branches et joindre une explication brève. RFC 3326 rend cette explication transportable sans lui confier l’action protocolaire.

2 oct. 2026
L’utilisateur choisissait une identité préférée ; le proxy devait effacer ce choix : RFC 3325

Histoire d'Internet

L’utilisateur choisissait une identité préférée ; le proxy devait effacer ce choix : RFC 3325

Une préférence pouvait entrer dans le proxy, influencer sa décision, puis devait disparaître. RFC 3325 ne traitait pas cette disparition comme une optimisation de taille: elle empêchait la parole de l’utilisateur de voyager sous l’apparence d’une preuve produite par le réseau.

2 oct. 2026
Le port de console portait le bon nom. Le câble allait vers un autre routeur

IETF

Le port de console portait le bon nom. Le câble allait vers un autre routeur

Une étiquette peut rendre un chemin de secours rassurant sans le rendre vrai. La RFC 3871 demandait déjà une console indépendante des plans IP et de forwarding; l'exploitation doit encore prouver l'identité de l'équipement, l'autorité de l'opérateur et le retour du service.

2 oct. 2026
Ils partageaient un domaine de confiance sans se faire confiance : RFC 3324

Histoire d'Internet

Ils partageaient un domaine de confiance sans se faire confiance : RFC 3324

Le dessin de RFC 3324 contient une anomalie volontaire: A et B sont placés dans le même domaine, mais A ne fait pas confiance à B. Le périmètre dit qui est censé suivre les mêmes règles; seule une liaison vérifiée dit ce qu’un récepteur peut croire.

2 oct. 2026
Le chiffre de LACNIC sur la sécurité de 47 universités manque de dénominateur

Récits

Le chiffre de LACNIC sur la sécurité de 47 universités manque de dénominateur

Dans son récapitulatif de septembre, LACNIC reprend une amélioration marquée de la part d’universités équatoriennes classées au niveau critique en matière de sécurité. Les sources publiques donnent les pourcentages et décrivent le groupe suivi, mais pas les effectifs qui…

2 oct. 2026
Le PDF était privé. La référence, elle, était valide

IETF

Le PDF était privé. La référence, elle, était valide

Un service a extrait l’identifiant d’une pièce jointe depuis une réponse JMAP, puis l’a injecté dans un objet partagé avec toute une équipe. Le chemin était juste, le type conforme et l’écriture autorisée. Pourtant, le document venait de franchir une frontière que chacun de ces…

2 oct. 2026
L’appelant était anonyme pour le destinataire, pas pour le service de confidentialité : RFC 3323

Histoire d'Internet

L’appelant était anonyme pour le destinataire, pas pour le service de confidentialité : RFC 3323

Le mot `critical` transformait une préférence de confidentialité en règle d’échec: si le réseau ne pouvait pas masquer l’identité demandée, il devait refuser la requête plutôt que l’acheminer à découvert.

2 oct. 2026
Masqué pour les autres, joignable dans le dialogue : RFC 3323

Histoire d'Internet

Masqué pour les autres, joignable dans le dialogue : RFC 3323

La RFC 3323 ne faisait pas disparaître l’appelant SIP. Elle posait une question plus précise: quelles informations d’identité le destinataire peut-il voir, et quel état un service doit-il conserver pour que l’échange continue ?

2 oct. 2026
L’adjacence venait de renaître, le LSP appartenait encore au routeur d’avant

IETF

L’adjacence venait de renaître, le LSP appartenait encore au routeur d’avant

Le calcul SPF n’avait reçu aucun objet manifestement faux. Les voisins annonçaient une adjacence qu’ils venaient réellement d’établir; le LSP de l’autre extrémité avait réellement été émis par ce routeur. Pourtant, l’ensemble décrivait deux incarnations différentes et autorisait…

2 oct. 2026