Signaux de continuité des politiques, de légitimité et de redevabilité dans les institutions de gouvernance de l’Internet.
Gouvernance
Gouvernance
La veille en gouvernance suit les institutions, les processus politiques, les organismes de normalisation, les opérations des registres, les litiges de responsabilité et les communautés d'opérateurs qui façonnent la gouvernance et le fonctionnement de l'Internet.
Veille RIRDossierSociété des ressources numériquesICANNIETFHistoire d'InternetGroupes d'opérateurs réseau
Veille RIR, Dossier, Société des ressources numériques, ICANN, IETF, Histoire d’Internet et sessions NOG.
La couverture privilégie les preuves de mise en œuvre et les comportements institutionnels plutôt que les positions déclaratives.
Articles récents
À la une : Gouvernance
7 720 articles
IETF
La clé active a signé sa remplaçante. C’était précisément le risque.
Une rotation peut être parfaitement signée et pourtant constituer la persistance de l’attaquant. La question décisive n’est pas seulement « la signature est-elle valide ? », mais « cette clé avait-elle, seule, le mandat de choisir tout l’avenir de l’identifiant ? »
Histoire d'Internet
Une liste de préfixes n’était pas encore une politique d’accès : RFC 3123
Le DNS pouvait transporter une liste compacte de réseaux. La décision la plus rigoureuse de la RFC 3123 fut de ne pas confondre ce contenant avec une consigne: le record décrivait, tandis que l’application devait encore interpréter, décider et agir.
Histoire d'Internet
La réponse d’absence était une politique, pas un modèle : RFC 5230
Un message d’absence part au nom d’une personne qui ne lit pas son courrier. La RFC 5230 transforme ce geste banal en règle opérationnelle: vérifier que le message lui était destiné, reconnaître la réponse précise qui s’applique, se souvenir de son envoi à cette adresse et…
Histoire d'Internet
Le chiffre du délai engageait aussi l’horloge : RFC 3116
Mesurer le passage d’une cellule ATM semblait demander une simple soustraction. RFC 3116 montra que le résultat appartenait autant au dispositif de mesure qu’au commutateur: horloge, compteurs et charge devaient rester visibles.
IETF
Le nœud était bien authentifié. La carte, elle, restait locale.
Au cours d’une revue d’incident, deux équipes présentent des captures valides du même nœud SAND. Les signatures passent, les identités concordent, mais les voisinages ne se recouvrent presque pas. La tentation est de désigner une vue « correcte » et l’autre « incomplète ». La…
Histoire d'Internet
Ils partageaient un système, pas le pouvoir d’approuver : RFC 3113
En 2001, la téléphonie mobile avait besoin des protocoles Internet, et l’Internet avait besoin de comprendre les contraintes radio. RFC 3113 organisa cette rencontre sans inventer une autorité commune au-dessus de l’IETF et de 3GPP.
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…
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…
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.
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…
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.
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…
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.
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.
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…
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.
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…
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…
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…
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…
Carte des sessions
Pôle Gouvernance
Veille RIR
Cinq sessions régionales consacrées aux politiques d’allocation, à la légitimité des conseils et à la continuité institutionnelle.
Ouvrir la veille RIRDossier
Dossiers de gouvernance de long terme, avec analyse des tensions juridiques, électorales et institutionnelles.
Ouvrir le dossierSociété des ressources numériques
Veille sur les adhésions, les chartes et la gouvernance des ressources dans l'écosystème NRS.
Ouvrir la session NRSICANN
Coordination du DNS, cadres de responsabilité et dynamique des processus multipartites à l'échelle mondiale.
Ouvrir la session ICANNIETF
Trajectoire de normalisation des protocoles et risques d’interopérabilité dans un contexte de fragmentation des politiques.
Ouvrir la session IETFHistoire d'Internet
L’historique des infrastructures sur un cycle long permet d’interpréter la gouvernance et d’anticiper les évolutions structurelles.
Ouvrir la session HistoireGroupes d'opérateurs réseau
Analyses de mise en œuvre au niveau des opérateurs, issues d'APRICOT et des écosystèmes des NOG régionaux et nationaux.
Ouvrir la session NOG