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 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
3 701 articles
Histoire d'Internet
Le numéro de version a survécu. Pas le cadre de sécurité : RFC 1441
Dans un message SNMP, l’entier `1` peut désigner la version communautaire de SNMPv2. Ce petit décalage n’est pas une erreur de calcul: c’est le vestige d’une architecture en pièces détachées. Le numéro aide le moteur à choisir une grammaire de message. Il ne certifie ni le modèle…
IETF
Dan Harkins et la clé d’amorçage qui ne pouvait pas prouver sa propre garde
Une preuve cryptographique peut établir qu’un appareil tient une clé privée sans dire comment la clé publique correspondante est arrivée sur le serveur, ni qui était habilité à l’y inscrire. C’est la limite que RFC 9966 rend lisible. Elle organise une preuve d’amorçage; elle ne…
Histoire d'Internet
L’alarme subsistait. Sa route vers l’autre gestionnaire avait expiré : RFC 1451
Une station continuait de mesurer, de comparer et de compter. Pourtant, le chemin qui devait porter ses alertes vers une autre station pouvait disparaître après un simple compte à rebours. La RFC 1451 avait séparé la permanence de l’alarme de celle de son destinataire. Cette…
Récits
AFRINIC : ce que contient le total des réserves de juin
Une réserve qui progresse sur un an mais recule légèrement depuis mars peut susciter des lectures contradictoires. Le rapport financier d’AFRINIC permet de préciser les montants. Il ne permet pas de transformer ces écarts en rendement.
Histoire d'Internet
Le nom d’utilisateur ressemblait à une personne. L’espace de noms ne garantissait qu’une case : RFC 1439
Un identifiant facile à deviner rendait le courrier électronique plus humain. Il rendait aussi l’erreur plus trompeuse: lorsque deux noms produisaient la même chaîne, le système pouvait livrer sans faute technique au mauvais destinataire humain. En 1993, la RFC 1439 a placé cette…
IETF
David Benjamin et le code de compatibilité qui ne devenait pas une autorisation générale
Un ancien dispositif cryptographique peut bloquer une migration moderne à un instant précis de l’échange. La solution ne reste sûre que si elle garde cette précision. RFC 9963 ménage une voie étroite pour une signature client ancienne; elle ne rétablit pas une permission générale…
Dossier
Le canal sécurisé a échoué. Le client ne pouvait pas revenir en arrière : RFC 9887
La RFC 9887 transforme une modernisation du transport en règle d’autorité: l’échec du chemin TACACS+ protégé n’autorise pas l’usage du chemin ancien, même s’il reste joignable.
Histoire d'Internet
Le fichier était arrivé. Le destinataire ne l’avait pas encore accepté : RFC 1440
La RFC 1440 imaginait un dépôt sans rendez-vous: un expéditeur poussait un fichier vers une machine où il ne possédait aucun compte, puis repartait tandis que l’objet attendait dans un espace commun. Le réseau avait fini son travail. Pour le destinataire, l’histoire n’avait pas…
IETF
Al Morton et le test de capacité qui ne devenait pas une promesse de service
Une mesure de débit peut éclairer une méthode, un chemin et un instant déterminés. Elle devient trompeuse lorsqu’on la transforme en promesse sur chaque session future, un abonnement, une application ou un réseau entier.
IETF
Muhammad Shahzad et l’enregistrement d’appareil qui ne révoquait pas l’accès
Supprimer un enregistrement d’appareil peut être un signal opérationnel important. Cela ne prouve pas, à lui seul, qu’un point d’application a retiré l’accès, que l’appareil s’est déconnecté ou qu’une tentative ultérieure a été refusée.
Récits
RIPEstat : une adresse sans résultat, un préfixe avec des routes
Un signalement sur Looking Glass rappelle qu’une recherche doit d’abord identifier ce qu’elle observe. Nos vérifications ont toutes abouti, sans expliquer pour autant la divergence rapportée auparavant.
ICANN
Un changement ISO peut déclencher la sortie d’un ccTLD IDN. Il ne donne pas à l’ICANN un verdict territorial.
Une infrastructure de coordination peut avoir besoin d’un repère entretenu par une autre institution. Elle ne devrait pas, pour autant, se présenter comme l’institution qui tranche la réalité désignée par ce repère. C’est cette discipline que la ccPDP4 de la ccNSO rend visible…
Dossier
Externaliser la messagerie ne règle pas qui s’occupe de DMARC
L’hébergement des boîtes peut être parfaitement défini alors que la politique du domaine reste sans responsable désigné. Une nouvelle enquête sur le DNS invite à regarder ce partage des tâches.
IETF
Cédric Fournet et le reçu qui ne rendait pas un journal complet
Une preuve signée peut établir une relation exacte entre une entrée et un état d’arbre. Elle ne transforme pas, par son seul format, un journal en histoire complète, digne de confiance et encore valable.
Histoire d'Internet
La session WAN était ouverte, mais les terminaux gardaient deux liaisons distinctes : RFC 1434
Le terminal recevait bien un acquittement, mais celui-ci venait du commutateur voisin, pas de la machine distante. Avec la RFC 1434, cette différence n'était pas une imperfection à masquer: elle devenait le principe même du Data Link Switching, qui isolait les délais du WAN tout…
Dossier
L’identifiant a été résolu. L’aéronef n’a pas été localisé : RFC 9886
La RFC 9886 rend un DRIP Entité Tag consultable dans le DNS, mais la réponse appartient au registre des identifiants, pas à la surveillance aérienne. Un certificat HHIT et un endorsement BRID validés attestent une inscription; ils ne disent ni où se trouve l’aéronef, ni qui le…
ICANN
Pas d’avis collectif du ccNSO Council sur les règles anti-abus
Le ccNSO Council ne prévoit pas de déposer une réponse collective à la consultation sur les abus dans les gTLD. Les gestionnaires de domaines nationaux restent invités à intervenir pour leur propre compte. Cette retenue institutionnelle peut laisser circuler l’expérience sans…
IETF
Christian Amsüss et le contexte de sécurité DoC qui ne protégeait pas le DNS amont
Une résolution DNS transportée par CoAP peut être protégée sans que toute sa chaîne le soit. La RFC 9953, écrite collectivement avec Christian Amsüss, limite clairement la portée: DTLS, TLS ou OSCORE protège l’échange entre les parties qui partagent le contexte. Le serveur DoC…
IETF
L’IETF peut borner la mention de pied de mail. Il lui faut encore un reçu de statut de contribution.
Une formule au bas d’un courriel envoyé à l’IETF peut paraître décisive: elle réserve des droits, interdit des œuvres dérivées ou répète une règle d’entreprise. La dernière version d’un projet consacré à ce sujet propose une limite précise: le mécanisme spécial de restriction des…
Histoire d'Internet
Les codes concordaient. Le circuit exigeait encore une autorisation : RFC 1394
En 1993, savoir que `FR`, un indicatif téléphonique et un answerback télex renvoyaient à la France ne suffisait pas à joindre qui que ce soit. Il fallait encore un réseau, une passerelle, une permission et un destinataire. La RFC 1394 rassembla les repères sur une même ligne sans…
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