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
7 558 articles

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…

Récits
Moins de 1 % des UPDATE BGP liés au RPKI : un résultat utile, pas un verdict sur la stabilité
Une étude évaluée par les pairs estime que les mises à jour associées au RPKI restent marginales dans le volume observé des UPDATE BGP. Cela compte, mais le volume des messages n’épuise pas la question de la stabilité.

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.

ICANN
.agent : cinq candidats réapparaissent dans au moins onze groupes ICANN
Le premier fichier CSV du cycle ICANN 2026 place treize candidats dans le groupe `.agent`. Cinq de ces entités candidates figurent dans au moins onze groupes de contention numérotés du fichier: le dossier révèle ainsi des portefeuilles d’engagements, au-delà du seul affrontement…

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…

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…

Histoire d'Internet
Sans AFI, la politique valait pour « any » : les quatre familles de RFC 4012
RPSLng a ajouté une clause facultative pour préciser la famille d’une politique multiprotocole. Son absence ne laissait pas la portée indéterminée: RFC 4012 lui donnait le sens « any », tandis que les anciens attributs conservaient leur sens IPv4 unicast.

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’IETF, un appel rejeté n’est pas un appel non traité
Les règles en vigueur à l’IETF distinguent le dossier arrêté à l’entrée de celui qui est rejeté après examen. Elles ne lui donnent pas non plus le même lieu de publication. Cette séparation est décisive: la liste des appels acceptés ne suffit pas, à elle seule, à mesurer toutes…

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…

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…

Récits
AS24940 : 91 routes, 63 correspondances et 49 autorisations plus larges
Le résumé de veille AS24940: 91 routes, 63 correspondances et 49 autorisations plus larges 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 l’infrastructure.…

IETF
La sécurité SLAPP est une frontière historique, pas une preuve de déploiement
Le RFC 5413 conserve Secure Light Access Point Protocol tel qu'il a été soumis aux travaux CAPWAP. Ses idées de découverte, d'authentification et de transport protégé sont utiles pour l'histoire, mais le RFC Editor le publie pour le registre historique et déconseille de…

IETF
LWAPP est une archive historique, pas une base de déploiement
Le RFC 5412 conserve l'état du Lightweight Access Point Protocol au moment où il a été soumis aux travaux CAPWAP. Il éclaire l'architecture contrôleur–point d'accès, mais le RFC Editor le classe Historic et indique qu'il ne doit pas servir de base à un déploiement. Le RFC 5415…

Dossier
À la PP-26, la parole a sa file ; les décisions ont besoin d’une autre trace
Cent quatre-vingts secondes peuvent suffire à rendre une priorité visible, sans suffire à raconter ce que la Conférence en fera. Avant l’ouverture de la PP-26, l’UIT a déjà fixé une procédure pour les déclarations de politique générale: un intervenant par délégation, des demandes…

IETF
CATS a choisi le contact du service. Le backend est resté caché : RFC 10053
CATS peut orienter une requête vers un point de contact prometteur à partir de l’état du réseau et des ressources de calcul. Ce choix ne révèle pas nécessairement quelle instance interne traitera la requête, ni si les métriques publiées décrivent cette instance seule.
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