Domaine principal
Infrastructure Internet
Au sein de la facette Domaine principal, l'analyse Infrastructure Internet regroupe les articles par domaine principal afin que les lecteurs puissent suivre un périmètre précis de l'infrastructure Internet, de la gouvernance, des marchés de connectivité ou du capital numérique. Cette page rassemble les articles associés, les preuves publiques, les institutions, les entreprises, les personnes, l'exposition régionale, les dépendances opérationnelles et le contexte de marché qui pourraient sinon être répartis entre différentes pages de catégories. Elle explique le domaine, la classe d'acteurs probable, le contexte de marché ou de gouvernance, ainsi que les sources que les lecteurs devraient utiliser pour comparer les signaux. Opérateurs, analystes et lecteurs de gouvernance peuvent voir comment un même domaine se manifeste à travers les événements, les profils, les évolutions de marché, les preuves issues de sources publiques, les dépendances régionales et les décisions d'infrastructure à plus long cycle au fil du temps.

Dirigeants
Prasanna Premachandra et le réseau scolaire qui a rendu du temps à l’apprentissage
Une connexion sans fil interrompue entre deux salles paraît être un incident mineur. Répétée tout au long d’une journée scolaire, elle devient du temps d’enseignement perdu, un accès inégal et une charge récurrente pour l’équipe d’assistance. Le parcours public de Prasanna…
Dossier
La notification était arrivée. Un serveur n’avait encore rien à livrer
Une petite réponse XML peut annoncer une nouvelle vue RPKI avant que l’infrastructure soit réellement prête à la servir. Le projet soumis au dernier appel de l’IETF fixe donc une règle de publication très concrète: les objets d’abord, leur notification ensuite. Dans une ferme de…
Dossier
BGP avait retenu la route. Le headend n’avait encore choisi aucun chemin : RFC 9830
Un réflecteur de routes présente au headend une annonce SR Policy parfaitement recevable. Le tableau BGP l’affiche comme meilleure route de son NLRI. Quelques secondes plus tard, le trafic continue pourtant d’emprunter une candidate apprise par PCEP. Il n’y a pas contradiction…

Dirigeants
Karthick Thangavel et le travail de réseau caché sous la croissance du haut débit indien
Chaque réponse d’IA, match diffusé en continu ou paiement numérique commence par une opération moins visible: quelqu’un a reconnu un tracé, raccordé une fibre, configuré un équipement d’accès et pris en charge la panne. Le parcours public de Karthick Thangavel mérite l’attention…
Dossier
Le défi a libéré le message. Il n’avait pas encore atteint la liste
Le 11 septembre, l’IETF prévoit de basculer ses services de courrier vers une architecture modulaire. Entre le dépôt d’un message inconnu et son arrivée chez un abonné se succèdent pourtant plusieurs prises de responsabilité. Une réponse positive à l’une d’elles ne peut servir de…
Dossier
Le numéro de CRL montait. L’autorité, elle, était passée au manifeste : RFC 9829
Un validateur voit un compteur plus élevé et s’apprête à choisir. Pourtant, dans la RPKI, ce réflexe produit précisément le second centre d’autorité que RFC 9829 supprime. La CRL pertinente n’est pas celle dont le numéro impressionne: c’est l’objet vers lequel convergent le…

Dirigeants
Artem Izbaenkov et le coût de la représentation au RIPE NCC
En se présentant en 2024 au Conseil exécutif du RIPE NCC, Artem Izbaenkov a relié son expérience de la protection contre les attaques DDoS à une question institutionnelle plus large: qui peut réellement participer à la gouvernance du registre lorsque la langue, les cotisations et…
Dossier
La trace reliait l’action. Elle ne prouvait pas l’autorité
Lorsqu’un paiement contesté traverse trois agents et deux entreprises, la chronologie la plus nette n’est pas forcément la plus vraie. Chaque système peut produire un enregistrement valide et pourtant décrire une autre frontière. La nouvelle liste AUDIT de l’IETF ouvre le bon…
Dossier
La liste a gardé son ordre. Une partie de la politique s’est perdue : RFC 9825
Lors d’un changement d’aire, une équipe a voulu « préserver » les étiquettes de quatre routes composantes sur leur préfixe agrégé. Le routeur, lui, ne les avait pas oubliées: il appliquait la règle qui déconseille de transférer les étiquettes des composants vers le résumé. En…
Dossier
Le jeton autorisait l’outil, pas les arguments choisis par l’agent
Un agent peut présenter le bon jeton, la bonne clé et le bon périmètre OAuth, puis virer l’argent vers le mauvais compte. La faute ne se trouve alors ni dans l’authentification ni forcément dans la granularité du droit. Elle se situe entre le moment où le modèle produit l’acte…

Histoire d'Internet
« Si les réponses sont nombreuses » : RFC 1501 avant le mandat
Le passage décisif de RFC 1501 était au conditionnel. Une réponse assez forte devait précéder la démarche auprès d’IBM, laquelle devait elle-même précéder la formation d’une organisation. Le numéro RFC rendait cette promesse publique; il ne pouvait accomplir les étapes annoncées.
Dossier
L’en-tête disait NOERROR ; le corps signé prouvait que le nom n’existait pas : RFC 9824
Le cache avait conservé la preuve DNSSEC, sa signature et sa durée de vie. Il avait oublié un seul bit: la capacité CO annoncée par l’amont. Au moment de répondre, le résolveur savait encore que le nom n’existait pas, mais ne savait plus s’il pouvait présenter cette conclusion…
Dossier
Le service a changé de relais. Son ancien enregistrement a gagné
Dans un réseau local, l’ancienneté protège utilement un nom contre un nouvel arrivant. Dans une architecture à plusieurs mandataires, elle peut au contraire protéger une copie périmée contre le propriétaire légitime du service. Le projet de nouveau mandat de DNSSD place cette…

Histoire d'Internet
Le lecteur pouvait archiver l’objet sans pouvoir le comprendre : RFC 1496
Dans un environnement X.400(84), recevoir une pièce MIME inconnue pouvait aboutir à un geste très modeste: l’enregistrer dans un fichier, puis chercher un autre programme capable de l’ouvrir. RFC 1496 considérait cette issue comme préférable à la destruction du message. Il ne la…
Dossier
La méthode EAP a réussi ; la session protégée attendait encore son second témoin : RFC 9820
Le contrôleur avait supprimé la session après expiration de son délai. Dans son journal, l’objet était donc clos. L’équipement, isolé au même instant par une coupure radio, n’avait reçu ni la requête DELETE protégée ni la raison de son éviction. Il conservait son contexte et…
Dossier
Trois groupes ML-KEM approuvés, mais aucune recommandation générale
Une ligne de registre peut être techniquement complète tout en refusant de trancher à la place de l’exploitant. Pour les trois groupes ML-KEM autonomes que l’IESG vient d’approuver pour publication, le code existe, DTLS est admis, mais la colonne `Recommended` reste à `N`. Cette…

Histoire d'Internet
Le serveur de noms avait sauté une étape visible, pas une relation : RFC 1498
Un serveur de noms pouvait recevoir le nom d’un service et rendre directement plusieurs points d’attachement. Cette réponse compacte était commode. Elle ne supprimait pourtant ni la machine qui exécutait le service ni les deux liaisons conceptuelles que le résultat venait de…

Histoire d'Internet
Le code répondait. La spécification d’origine restait introuvable : RFC 1492
« Believed compatible »: quelques mots prudents portent tout le poids institutionnel de RFC 1492. En juillet 1993, la mise en œuvre simple de Cisco pouvait servir de témoin pour reconstruire TACACS, mais non de preuve d’un texte original que l’auteur n’avait pu obtenir pour des…
Dossier
Le commutateur a exécuté le programme. Il n’a pas acquis le droit de lire, de réécrire ou de décider : RFC 9817
Pendant une répétition immersive, le son reste fluide mais l’image d’un interprète prend un autre chemin. Le nom du service n’a pas changé. Le programme annoncé n’a pas changé. Pourtant, l’instance s’est déplacée vers un autre équipement, avec un état plus ancien et un accès plus…
Dossier
Trois attestations exactes ne prouvent pas qu’elles appartiennent à la clé du CSR
Dans une chaîne de certification automatisée, trois voyants verts peuvent cacher une faute d’identité. Une preuve décrit une clé créée dans un HSM, une autre une machine détenue par l’entreprise, une troisième un état jugé sain. Tant que l’autorité n’a pas démontré qu’elles…
