Organisme de normalisation ouvert dont les normes ont un impact mondial par leur mise en œuvre.
Gouvernance / IETF
IETF
La veille IETF couvre l’actualité publique qui touche l’infrastructure Internet, les décisions de gouvernance, les marchés de la connectivité, les flux de capitaux numériques et le risque opérationnel.

Processus de protocole et légitimité des normes.
Écart entre la spécification et la mise en œuvre chez les fournisseurs et les opérateurs.
Les changements majeurs de normes affectent généralement les systèmes sur des cycles de 120 jours et plus.
Articles récents
À la une : IETF
874 articles

IETF
Une dérogation IETF n’est pas une réécriture silencieuse
Dans un registre de gouvernance, une exception mal classée devient vite une règle. Il suffit qu’une décision liée à un document précis soit recopiée dans la colonne « procédure applicable » pour que le dossier suivant hérite d’une permission qu’il n’a jamais demandée. La…

IETF
Le conseil de l’IETF LLC interdit les preneurs de notes IA
En avril 2025, le registre des entités associait le nom d’un observateur à un `AI Noota Assistant`, tandis qu’une secrétaire humaine restait chargée du procès-verbal. La page actuelle du conseil d’administration de l’IETF LLC tranche désormais ce partage des rôles: les outils de…

IETF
Le projet 2418bis de l’IETF prévoit enfin une sortie de l’adoption
Un document de travail peut cesser de mobiliser des relecteurs sans avoir été réfuté. Il peut perdre son éditeur, être dépassé par une autre proposition ou simplement ne plus justifier le temps collectif qu’il exige. Jusqu’ici, le vocabulaire de l’adoption racontait surtout…

IETF
Ross Callon et ce port UDP qui était de l’entropie, pas une session
Dans RFC 7510, un numéro placé là où l’on attend un port d’application sert à répartir des paquets MPLS entre plusieurs chemins. Le travail collectif auquel Ross Callon a participé rappelle qu’une information utile au routage ne devient ni une identité ni une autorisation.

IETF
La Final Review n’est pas un second vote sur la norme
Sur le tableau de suivi, trois voyants étaient allumés: un Internet-Draft déjà approuvé, une pull request encore ouverte et plusieurs validations d’auteurs manquantes. Une note en déduisait que « la norme était remise au vote ». Elle confondait une garde de fidélité avec une…

IETF
Eric Vyncke et la sonde qui s’identifie sans devenir digne de confiance
Une équipe réseau ne reçoit pas d’abord l’intention du chercheur, mais un paquet inattendu et l’alerte qu’il a déclenchée. À travers le RFC 9511, Eric Vyncke et ses coauteurs proposent une façon sobre de rendre une sonde joignable et explicable, tout en refusant de confondre…

IETF
Le minuteur que l’autre extrémité pouvait entendre : TCP User Timeout sans patience négociée
Une extrémité TCP pouvait décider combien de temps conserver des données restées sans accusé de réception, mais l’autre n’en savait rien. La RFC 5482 a placé cette durée sur le fil sous forme de conseil. Elle s’est surtout appliquée à ne pas transformer ce conseil en promesse…

IETF
Le champ qui changeait de sens après la poignée de main : l’échelle de fenêtre TCP
TCP n’a pas élargi son champ de fenêtre de réception lorsque les liaisons rapides et lointaines ont dépassé 65 535 octets en vol. Il a confié à la poignée de main une tâche plus subtile: fixer, pour chaque sens, l’unité dans laquelle ce champ serait lu.

IETF
La requête avant la poignée de main : le compromis de rejeu de TCP Fast Open
TCP Fast Open a permis à un client déjà connu de placer ses premiers octets applicatifs dans le paquet qui demandait l'ouverture de la connexion. Le gain d'un aller-retour s'accompagnait d'une dette précise: maîtriser le rejeu, les clés de cookie, le travail avant confirmation et…

IETF
La connexion est plus grande que le chemin : Multipath TCP maintient un flux unique sur plusieurs routes
Un téléphone quitte le Wi-Fi d’un bureau alors qu’un échange est toujours en cours, puis retrouve le réseau par la liaison cellulaire. Pour TCP classique, le chemin fait partie de l’identité de la connexion. Multipath TCP place au-dessus de plusieurs sous-flux TCP un même flux…

IETF
Quand le récepteur a dessiné la carte : l'histoire de SACK dans TCP
Pendant longtemps, un accusé de réception TCP ne montrait qu'une frontière continue. SACK y a ajouté une carte sommaire des octets déjà arrivés au-delà d'un trou. Ce changement a rendu la réparation plus sélective sans transférer au récepteur la maîtrise de la congestion ni le…

IETF
Comment DNSSEC a appris à prouver qu’un nom n’existe pas
Signer une réponse permet d’authentifier un enregistrement présent. Le problème plus subtil consiste à authentifier l’espace vide où un attaquant pourrait cacher un nom, en inventer un ou remplacer un « non » légitime par un refus falsifié.

IETF
L’heure creuse n’est qu’une prévision : ALTO transforme le calendrier du trafic en promesse publiée
Un transfert massif peut attendre deux heures du matin. Mais rien ne garantit que le réseau sera encore calme à cet instant. Avec les calendriers de coûts ALTO, un opérateur publie une préférence dans le temps afin qu’une application choisisse quand agir. Cette préférence n’est…

IETF
Happy Eyeballs : le prix discret d’une connexion qui paraît immédiate
La course entre IPv6 et IPv4 n’est pas un simple artifice de vitesse. Elle répartit le coût d’une transition inachevée entre l’utilisateur, le logiciel client et les réseaux qui tardent à corriger leurs chemins défaillants.

IETF
Rejoindre le groupe ne suffit plus : SSM nomme la source
Avec SSM, le réseau ne cherche plus lui-même qui parle dans le groupe: le récepteur doit demander un canal précis, source comprise.

IETF
Le nom secret a encore besoin d’une porte publique : la nouvelle frontière de confidentialité d’ECH
Avant même que TLS puisse chiffrer le nom demandé, le client doit apprendre où trouver la clé qui permettra de le cacher. ECH protège donc le `ClientHello`, mais fait de la réponse DNS, de la porte d’entrée mutualisée et du renouvellement des clés les nouveaux maillons visibles…

IETF
Le paquet marqué avant d’être perdu : la longue controverse de l’ECN sur la congestion
L’ECN a introduit un geste presque paradoxal dans le réseau: prévenir de la congestion sans détruire le paquet qui porte l’avertissement. Derrière deux bits d’en-tête se trouve pourtant une chaîne de responsabilités beaucoup plus vaste, du gestionnaire de file au destinataire, du…

IETF
Un Internet-Draft expiré n’est pas une proposition rejetée
Dans le registre de veille, le raisonnement tenait sur une ligne: `Expired`, donc « rejeté par l’IETF ». Aucun avis de rejet n’était joint. Ni appel à adoption, ni constat de consensus, ni Last Call, ni décision de l’IESG ne permettaient d’identifier l’auteur du verdict. Une…

IETF
Un MUST d’un RFC sans sujet n’est pas un constat d’audit
Dans le cahier de recette, la ligne tenait en trois cases: « RFC 8200 », « MUST », « échec ». La couleur rouge lui donnait l’air d’une conclusion. Pourtant, personne ne pouvait dire si l’exigence visait un émetteur, un récepteur, un routeur ou l’exploitant. La condition…

IETF
Après Max-Age, la bonne réponse n’est pas « faux » mais « je ne sais plus »
Un capteur de chambre froide annonce une température correcte puis se tait. La valeur reste fraîche pendant la durée indiquée par Max-Age. Une seconde après l’expiration, le protocole ne dit pas que la chambre s’est réchauffée, que le paquet suivant s’est perdu ou que le capteur…
Déverrouillage de l’accès membre
Analyse de profil réservée
Connectez-vous pour débloquer les briefings de profil complets et les sections approfondies.
Briefing du Strategic Circle
Adhérez pour débloquer les briefings stratégiques après connexion.
Rejoindre Strategic CircleBriefing Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance