Profil
Research
Research rassemble les profils des personnes, entreprises, institutions et autres entités couvertes par BTW.MEDIA, afin que les lecteurs puissent comparer les sujets derrière ses reportages. La page permet de comparer les profils publics, les événements associés, les dossiers de preuves, les changements de responsabilités, l’ampleur des activités, l’exposition aux instances de gouvernance, les liens organisationnels et la pertinence sur le marché, tout en distinguant les fiches des organisations et des personnes de la simple chronologie de l’actualité. Les lecteurs peuvent comprendre qui ou ce que représente le profil, sur quelles sources publiques il s’appuie, comment il se relie aux entreprises, aux infrastructures, aux marchés, aux instances de gouvernance ou aux événements, et quels changements méritent une attention continue à mesure que le sujet évolue.
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…
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.
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…
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…
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.
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…
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…
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…
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…
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.
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.
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…
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…
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…
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…
Dossier
Le trafic des racines DNS a doublé ; l’indice venait d’une mise à jour de résolveur
Pendant environ une semaine, le débit de requêtes reçu par le DNS racine est passé d’environ 1,6 à 3,2 millions par seconde. Le trafic était valide et provenait de réseaux de résolveurs récursifs; les opérateurs n’ont constaté aucun effet mesurable sur le service racine.…
IETF
RFC 5416 : la liaison 802.11 a une frontière d’époque
RFC 5416 décrit une liaison CAPWAP précise pour IEEE 802.11. Elle organise les échanges entre le point de terminaison radio et le contrôleur, mais ne transforme pas un champ de capacité en garantie pour toutes les fonctions Wi-Fi ultérieures. Pour une décision de direction, il…
IETF
L’état CAPWAP ne prouve pas le service : RFC 5415
RFC 5415 organise un plan de contrôle WLAN: un Access Controller gère des Wireless Termination Points, établit des sessions protégées, applique des réglages et transporte des données clients. Mais un état de protocole terminé, une session DTLS ou un paquet de données reste une…
Dirigeants
Quand les demandes pour la zone racine ont augmenté, Kim Davies a refondu le RZMS
En 2022, la croissance des portefeuilles de domaines de premier niveau et la fréquence accrue des changements de clés DNSSEC avaient dépassé les hypothèses du Root Zone Management System. Kim Davies a décrit la refonte d’ICANN: seuils d’approbation configurables, demandes…
IETF
WiCoP est une archive historique, pas une base de déploiement : RFC 5414
RFC 5414 décrit WiCoP, un protocole de contrôle et de provisionnement des grands réseaux WLAN. Le RFC Editor le classe Historic et renvoie à RFC 5415. La distinction est décisive: un contrôleur visible ou un accusé de réception ne prouve ni l’autorité actuelle, ni l’application…