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 filtre pouvait retenir une correspondance, pas une conversation : RFC 5229

Histoire d'Internet

Le filtre pouvait retenir une correspondance, pas une conversation : RFC 5229

Sieve devait permettre aux utilisateurs de trier leurs courriels sans transformer le serveur de livraison en environnement de programmation sans limites. RFC 5229 lui a donné une mémoire de poche: des valeurs nommées et les fragments issus d’une correspondance réussie. Ces…

1 oct. 2026
Le préfixe était enregistré. L’interprète restait local.

IETF

Le préfixe était enregistré. L’interprète restait local.

Une adresse IP écrite sous une forme lisible paraît se suffire à elle-même. Pourtant, avant qu’elle devienne une valeur CBOR, un registre a résolu un nom, une extension précise a été chargée et une politique locale a autorisé son exécution. La lisibilité montre l’intention; elle…

1 oct. 2026
Le registre et le RFC divergeaient. Le réseau avait déjà tranché : RFC 3115

Histoire d'Internet

Le registre et le RFC divergeaient. Le réseau avait déjà tranché : RFC 3115

Deux mois après RFC 3025, RFC 3115 dut corriger deux numéros d’extension Mobile IP. Le choix n’était pas arbitraire: les implémentations utilisaient déjà les valeurs inscrites chez IANA.

1 oct. 2026
Le préfixe qui ne pouvait pas recevoir la réponse : RFC 5220

Histoire d'Internet

Le préfixe qui ne pouvait pas recevoir la réponse : RFC 5220

Un hôte IPv6 pouvait posséder deux adresses valides, envoyer un paquet par le mauvais fournisseur et recevoir une réponse destinée à un préfixe sans route de retour depuis l’Internet public. La RFC 5220 a identifié un problème de sélection par l’hôte; elle ne rapporte ni panne…

1 oct. 2026
Le mot de passe correspondait. L’utilisateur n’était pas encore authentifié : RFC 3112

Histoire d'Internet

Le mot de passe correspondait. L’utilisateur n’était pas encore authentifié : RFC 3112

RFC 3112 permettait à LDAP de comparer un secret à une valeur dérivée conservée dans l’annuaire. Mais la réponse vraie restait volontairement étroite: elle ne transformait pas la connexion en association authentifiée.

1 oct. 2026
DFINFRA : les ressources figées d'un acteur RIPE silencieux depuis mars 2026

Récits

DFINFRA : les ressources figées d'un acteur RIPE silencieux depuis mars 2026

Le résumé de veille DFINFRA: les ressources figées d'un acteur RIPE silencieux depuis mars 2026 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 pour…

1 oct. 2026
Une mise à jour atomique peut être entièrement mauvaise

IETF

Une mise à jour atomique peut être entièrement mauvaise

Le mérite de DUJ est d’empêcher qu’une modification DNS composée s’arrête au milieu. Sa limite est tout aussi importante: l’atomicité protège la cohérence de l’opération, pas la légitimité de celui qui l’a demandée ni la justesse de son résultat.

1 oct. 2026
Les deux couches disaient « vers l’avant », mais regardaient en sens opposés : RFC 3108

Histoire d'Internet

Les deux couches disaient « vers l’avant », mais regardaient en sens opposés : RFC 3108

Dans RFC 3108, un paramètre pouvait être exact, bien formé et pourtant appliqué au mauvais flux. La commande d’appel et la signalisation du support ATM employaient toutes deux « avant », mais ne plaçaient pas l’origine au même endroit.

1 oct. 2026
Le nouveau RFC a corrigé le nom de session, pas la conception du payload : RFC 5219

Histoire d'Internet

Le nouveau RFC a corrigé le nom de session, pas la conception du payload : RFC 5219

En 2008, RFC 5219 a remplacé une spécification RTP pour le MP3 qui associait le bon nom à son exemple, mais le mauvais à sa consigne SDP. La révision a supprimé cette contradiction et précisé le pseudocode d’implémentation; elle ne présente ni nouvelle architecture de payload ni…

1 oct. 2026
Le certificat était valide, pas encore sa délégation AS2

IETF

Le certificat était valide, pas encore sa délégation AS2

Le moment dangereux d'une rotation n'est pas toujours celui où la cryptographie échoue. C'est parfois celui où tout fonctionne, alors que personne ne peut encore produire l'acte qui autorise cette clé à parler au nom de ce partenaire précis.

1 oct. 2026
La passerelle prêtait l’adresse, la localité devenait un protocole : RFC 3102

Histoire d'Internet

La passerelle prêtait l’adresse, la localité devenait un protocole : RFC 3102

Avec Realm Specific IP, l’hôte privé ne subissait plus une traduction invisible: il empruntait des paramètres publics et les plaçait lui-même dans ses paquets. Cette transparence ne supprimait pourtant pas la passerelle; elle rendait visibles son allocation, son bail et son…

1 oct. 2026
L’authentification DHCP restait dans le domaine de confiance : RFC 3118

Histoire d'Internet

L’authentification DHCP restait dans le domaine de confiance : RFC 3118

RFC 3118 a ajouté l’authentification à DHCP, mais pas une identité valable sur tout le réseau. Son échange différé supposait qu’un client et un serveur reçoivent hors bande un secret partagé dans un même domaine administratif; la politique locale gardait le dernier mot sur…

1 oct. 2026
Avant que le consentement ne devienne une case à cocher : RFC 3098

Histoire d'Internet

Avant que le consentement ne devienne une case à cocher : RFC 3098

RFC 3098 ne demandait pas seulement aux annonceurs d'être courtois. Il transformait la responsabilité en dispositif: ne pas inscrire par défaut, expliquer l'usage des données, confirmer la demande avec sa provenance, offrir une sortie et laisser à l'annonceur le coût d'entretien…

1 oct. 2026
DFINFRA et AS210860 : ce que le registre du commerce de Hambourg peut prouver là où le registre RIPE reste illisible

Récits

DFINFRA et AS210860 : ce que le registre du commerce de Hambourg peut prouver là où le registre RIPE reste illisible

Le résumé de veille DFINFRA et AS210860: ce que le registre du commerce de Hambourg peut prouver là où le registre RIPE reste illisible explique le développement, les preuves publiques disponibles, les organisations concernées, le contexte régional, l’exposition au marché et les…

1 oct. 2026
Un paquet par seconde avait déjà changé la machine

IETF

Un paquet par seconde avait déjà changé la machine

Entre le silence absolu et un trafic presque invisible, un équipement réseau peut franchir une frontière énergétique. La révision 03 de PowerBench montre pourquoi la comparaison commence par la description du test, pas par le chiffre en watts.

1 oct. 2026
ROHC a commencé sans voie de retour : RFC 3095

Histoire d'Internet

ROHC a commencé sans voie de retour : RFC 3095

Avant de pouvoir croire un accusé de réception, ROHC devait fonctionner là où aucune réponse ne pouvait revenir. RFC 3095 imposait donc un départ en mode unidirectionnel, puis donnait au décompresseur le pouvoir de demander un mode fondé sur le retour d'information.

1 oct. 2026
TALI ne pouvait présumer que son pair était en version 2 : RFC 3094

Histoire d'Internet

TALI ne pouvait présumer que son pair était en version 2 : RFC 3094

Avant d’envoyer une nouvelle opération de gestion, une passerelle TALI 2.0 devait déterminer ce que le pair distant savait comprendre. La RFC 3094 transforme cette négociation en règle de protocole, tout en publiant la proposition du fournisseur avec un avertissement…

1 oct. 2026
AS210328 / almazcloud.network : ce que la modification d'août 2026 du registre révèle — et ce qu'elle ne prouve pas — sur le transfert de confiance en routage

Entreprises services cloud Europe et Moyen-Orient

AS210328 / almazcloud.network : ce que la modification d'août 2026 du registre révèle — et ce qu'elle ne prouve pas — sur le transfert de confiance en routage

Le résumé de veille AS210328 / almazcloud.network: ce que la modification d'août 2026 du registre révèle — et ce qu'elle ne prouve pas — sur le transfert de confiance en routage explique le développement, les preuves publiques disponibles, les organisations concernées, le…

1 oct. 2026
De RIPE NCC à AFRINIC : la queue contractuelle — qui a régi les LIR africaines pendant les dix mois après la bascule

Récits

De RIPE NCC à AFRINIC : la queue contractuelle — qui a régi les LIR africaines pendant les dix mois après la bascule

Le 21 février 2005, AFRINIC est devenue le registre opérationnel de l'Afrique; le 31 décembre 2005 seulement, les contrats qui liaient encore les LIR africaines au RIPE NCC ont pris fin. Entre les deux, une structure contractuelle à double voie a gouverné un continent entier — et…

1 oct. 2026
Huit numéros dans le brouillon, aucun encore dans le registre

Dossier

Huit numéros dans le brouillon, aucun encore dans le registre

Un comité d’autorisation peut valider un programme cryptographique tout en restant incapable de répondre à une question élémentaire: à quelle autorité le nombre qu’il s’apprête à déployer appartient-il ? Le 1er octobre 2026, la révision 05 d’un Internet-Draft OpenPGP nommait huit…

1 oct. 2026