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.

La recherche d’Archie ne pouvait pas être plus à jour que sa dernière liste FTP

Histoire d'Internet

La recherche d’Archie ne pouvait pas être plus à jour que sa dernière liste FTP

Archie a rendu consultables des archives FTP anonymes dispersées sur le réseau en recueillant leurs listes de répertoires. Cette nuance définit le service: il pouvait indiquer un nom et un emplacement, mais le fichier restait sur une autre machine et l’index ne décrivait que ce…

8 oct. 2026
La licence visait le logiciel, pas le protocole : la frontière tracée par Gopher en 1993

Histoire d'Internet

La licence visait le logiciel, pas le protocole : la frontière tracée par Gopher en 1993

Le 11 mars 1993, l’équipe Gopher du Minnesota publie dans un groupe Usenet une note qui commence par vouloir calmer les rumeurs. La formule retenue par la mémoire collective tient en quelques mots: les usages commerciaux devraient payer. Le texte, lui, distingue les services…

8 oct. 2026
Avec le RFC 10065, l’identifiant de groupe déclenche une règle sans prouver son application

IETF

Avec le RFC 10065, l’identifiant de groupe déclenche une règle sans prouver son application

Un accusé de réception RADIUS peut montrer qu’un NAS a reçu une valeur de groupe; il ne démontre pas, à lui seul, que la règle voulue filtre le trafic en aval. Le RFC 10065 clarifie le transport de cette valeur, tandis que la preuve d’application reste à construire dans chaque…

8 oct. 2026
Alan Greenberg et la demande qui a ouvert un dossier au GNSO

Dirigeants

Alan Greenberg et la demande qui a ouvert un dossier au GNSO

En mai 2007, Alan Greenberg a transmis au GNSO une décision de l’ALAC: demander aux services de l’ICANN d’examiner le domain tasting. Cette démarche a ouvert un espace d’étude officiel. Elle n’a ni arrêté la politique ni conféré à ses auteurs un mandat sur l’ensemble des…

8 oct. 2026
La prise avait quatre broches : NORDUnet et le choix européen des protocoles

Histoire d'Internet

La prise avait quatre broches : NORDUnet et le choix européen des protocoles

En mai 1988, un réseau de recherche nordique demanda aux États-Unis une liaison vers NSFNET tout en prévoyant de transporter plusieurs services déjà utilisés dans la région. Sa « prise » à quatre broches répondait à une question plus difficile qu’un choix de protocole: pouvait-on…

8 oct. 2026
Tina Dam et le test de la racine qui ne pouvait pas valider un nom

Dirigeants

Tina Dam et le test de la racine qui ne pouvait pas valider un nom

Avant d’ajouter un domaine de premier niveau internationalisé à la racine, l’ICANN a posé une question volontairement étroite: des étiquettes encodées perturberaient-elles les serveurs et les résolveurs qui acheminent les requêtes DNS ? Le laboratoire a répondu dans les limites…

8 oct. 2026
Syslog pouvait signaler la qualité de son horloge. L’opérateur devait encore en définir les limites : RFC 5424

IETF

Syslog pouvait signaler la qualité de son horloge. L’opérateur devait encore en définir les limites : RFC 5424

Lorsqu’un incident se joue entre plusieurs machines, une heure affichée à la milliseconde donne facilement une impression de certitude. RFC 5424 prévoit justement un moyen de joindre au journal ce que l’émetteur sait — ou ne sait pas — de sa propre mesure du temps.

8 oct. 2026
Dans le tunnel EAP-FAST, le type 6 changeait de sens : RFC 5421

IETF

Dans le tunnel EAP-FAST, le type 6 changeait de sens : RFC 5421

Le RFC 5421 a placé un code EAP familier dans un nouveau cadre: le type 6 restait associé au Generic Token Card, mais, à l’intérieur d’un tunnel EAP-FAST, il sélectionnait un échange interne au format différent. Le texte imposait une séparation stricte entre ces usages et son…

8 oct. 2026
Lorrie Cranor veut relier le code aux étiquettes de confidentialité

Universitaires

Lorrie Cranor veut relier le code aux étiquettes de confidentialité

Le travail mené autour de la rubrique Data safety de Google Play pose une question concrète: un développeur peut-il rattacher chaque déclaration affichée par le store au code et au comportement des SDK ? Les recherches de Lorrie Cranor sur la confidentialité utilisable placent ce…

8 oct. 2026
La réussite du provisionnement ne décidait pas, à elle seule, de l’accès réseau : RFC 5422

IETF

La réussite du provisionnement ne décidait pas, à elle seule, de l’accès réseau : RFC 5422

La RFC 5422 distingue la préparation des identifiants de l’autorisation réseau; son mode sans authentification du serveur reste réservé au provisionnement.

8 oct. 2026
Décrire la faille ne revenait pas à publier le ver : le débat de la RFC 1135

Histoire d'Internet

Décrire la faille ne revenait pas à publier le ver : le débat de la RFC 1135

Après le ver de 1988, « divulguer » ne désignait pas une seule décision. Les documents distinguent la description des failles, l’explication des méthodes, la diffusion des correctifs et la publication du code désassemblé. La RFC 1135 a conservé plusieurs positions concurrentes…

8 oct. 2026
Le retour de Rebecca MacKinnon met deux méthodes de redevabilité en regard

Dirigeants

Le retour de Rebecca MacKinnon met deux méthodes de redevabilité en regard

Le retour de Rebecca MacKinnon au Global Network Initiative (GNI) en août 2026 relie deux démarches qu’il faut pourtant distinguer. Ranking Digital Rights (RDR), qu’elle a fondé, comparait les informations publiées par les entreprises; le processus d’évaluation plus récent de GNI…

8 oct. 2026
L’AAA connaissait l’abonné. Le Home Agent avait encore besoin d’une clé : RFC 5419

IETF

L’AAA connaissait l’abonné. Le Home Agent avait encore besoin d’une clé : RFC 5419

RFC 5419 explique pourquoi certains opérateurs de Mobile IPv6 souhaitaient s’appuyer sur leur relation AAA existante pour authentifier les abonnés. La question la plus révélatrice vient ensuite: le serveur AAA du réseau d’origine peut reconnaître l’abonné, mais le Home Agent…

8 oct. 2026
« Courant » ne voulait pas dire « sans examen » : le test de la RFC 6709

Histoire d'Internet

« Courant » ne voulait pas dire « sans examen » : le test de la RFC 6709

Une extension peut ajouter très peu de syntaxe et demander beaucoup de travail aux systèmes déjà en service. La RFC 6709 ne mesurait donc pas le caractère « courant » au nombre de lignes ajoutées. Elle le rattachait à une condition plus exigeante: le protocole de base et les…

8 oct. 2026
L’authentification CAPWAP n’inscrivait pas l’équipement dans le réseau : RFC 5418

IETF

L’authentification CAPWAP n’inscrivait pas l’équipement dans le réseau : RFC 5418

L’analyse de RFC 5418 sépare l’authentification WTP–AC de l’appartenance à un déploiement, du rôle de l’équipement et du trajet des données. Une session valide ne répond qu’à une partie de la question opérationnelle.

8 oct. 2026
Un seul Internet, plusieurs opérateurs : l’analogie téléphonique de la RFC 1462

Histoire d'Internet

Un seul Internet, plusieurs opérateurs : l’analogie téléphonique de la RFC 1462

Pour rendre l’architecture lisible, le FYI de 1993 part d’un appel téléphonique: l’usager voit un service, tandis que des réseaux distincts exploitent et réparent chacun leur portion.

8 oct. 2026
Le NAT était une fonction, pas une interface : pourquoi le modèle de la RFC 4008 a dû changer

Histoire d'Internet

Le NAT était une fonction, pas une interface : pourquoi le modèle de la RFC 4008 a dû changer

Dans l’exemple de configuration de la RFC 4008, le gestionnaire SNMP crée d’abord une ligne associée à un `ifIndex`, puis y rattache des mappages. Dix ans plus tard, NATV2-MIB décrit la traduction comme une fonction logique qui peut traverser plusieurs interfaces. Entre les deux…

8 oct. 2026
Pour Anriette Esterhuysen, la capacité de l’IGF se mesurait dans la durée

Dirigeants

Pour Anriette Esterhuysen, la capacité de l’IGF se mesurait dans la durée

En 2021, l’Gouvernance de l’Internet Forum pouvait compter des bourses, des personnes accompagnées et des ateliers. Le cadre préparé plus tôt par Anriette Esterhuysen posait une question moins immédiate: les personnes et leurs institutions pouvaient-elles encore poursuivre leurs…

8 oct. 2026
La trame traversait le pseudowire, sans son rôle de service : RFC 7152

Histoire d'Internet

La trame traversait le pseudowire, sans son rôle de service : RFC 7152

En 2014, un mémo de l’IETF sur les exigences a mis au jour une lacune discrète des VPN de couche 2: un routeur de périphérie pouvait recevoir une trame Ethernet par un pseudowire sans savoir si elle provenait d’un accès racine ou feuille. La RFC 7152 a transformé ce manque de…

8 oct. 2026
Avant la découverte CAPWAP, DHCP ordonnait les contrôleurs que le WTP pouvait essayer : RFC 5417

IETF

Avant la découverte CAPWAP, DHCP ordonnait les contrôleurs que le WTP pouvait essayer : RFC 5417

Une option DHCPv4 ou DHCPv6 peut placer un contrôleur d’accès avant un autre dans la recherche initiale d’un point de terminaison sans fil. RFC 5417 définit cet ordre comme une préférence configurée; la découverte et DTLS déterminent ensuite quel pair peut devenir le point de…

8 oct. 2026