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
8 058 articles

Dossier
RDAP a trouvé un lien geofeed, pas une vérité géographique : RFC 9877
RFC 9877 rend les geofeeds plus faciles à découvrir dans RDAP. Cette avancée ne raccourcit pourtant pas la chaîne de preuve: un pointeur normalisé indique où regarder, pas ce qu'une organisation est autorisée à conclure.

Dossier
Le numéro figurait au registre. Le logiciel n’avait encore rien accepté : RFC 9876
Un identifiant CoAP économise des octets en réunissant type de média, paramètres et codage. RFC 9876 améliore la qualité de cette correspondance commune. Il ne transforme pas pour autant une inscription en autorisation d’exécuter le contenu.

Dossier
L’atelier du W3C sur le commerce réunit deux ACP. Son dossier doit identifier les protocoles
L’atelier que le W3C et GS1 consacrent au commerce électronique pour les humains et les agents d’IA va rapprocher plusieurs protocoles récents. Ses pages publiques révèlent déjà une difficulté de traçabilité: ACP y renvoie à deux objets distincts. Avant que les interventions ne…

Histoire d'Internet
Le courrier restait lisible. Chaque réécriture devenait le problème du vérificateur : RFC 1421
Un texte en clair possède une autorité trompeusement immédiate. L’œil le reçoit avant que le logiciel ait reconstruit les octets signés, retrouvé la clé et comparé le contrôle d’intégrité. Avec `MIC-CLEAR`, RFC 1421 acceptait volontairement ce décalage: le destinataire pouvait…

Dossier
La réponse accusait réception d’une sonde, pas du prochain datagramme : RFC 9869
Une taille de paquet n’est pas une propriété éternelle d’un correspondant. RFC 9869 construit une preuve positive plus modeste: un jeton renvoyé confirme qu’une sonde rembourrée précise a atteint le récepteur UDP Options, sur un chemin donné et à un instant donné.

Histoire d'Internet
Le plan fut publié avant le résultat. L’annonce pouvait modifier l’échantillon : RFC 1273
Un avis impossible à livrer ne vaut ni consentement ni refus. Dans les essais décrits par RFC 1273, près de la moitié des courriels adressés aux administrateurs revinrent à l’expéditeur, tandis que l’annonce consommait davantage de trafic et de temps administratif que la mesure.…

ICANN
Le nouveau projet RIR permet d’écarter une évaluation. Le dénominateur doit rester public
Le projet recommandé pour la reconnaissance des registres Internet régionaux prévoit qu’ICANN puisse retirer du seuil des deux tiers l’avis négatif d’un RIR matériellement touché dans sa région de service ou ses revenus. Le texte organise la notification et la réponse. Il lui…

Dossier
La case s’est cochée. L’histoire des paquets avait disparu : RFC 9870
Un collecteur peut voir une case cochée après un million de paquets. RFC 9870 lui apprend qu’une option UDP a été observée au moins une fois dans un flux, pas lequel des paquets la portait, combien de fois elle est revenue ni ce que le destinataire en a fait.

Histoire d'Internet
Le service de noms tomba en panne ; l’agent pouvait encore répondre : RFC 1419
Une station d’administration connaissait le nom d’un équipement et gardait son adresse de la veille. Si la recherche du nom échouait le lendemain, elle pouvait encore envoyer un datagramme à cette ancienne adresse. L’équipement visé répondrait peut-être. Mais un autre aurait…

Histoire d'Internet
La session est morte. La mémoire des routes est devenue une exception explicite : RFC 1267
Un UPDATE vide peut constituer une preuve. Dans le redémarrage gracieux de BGP, ce message ne dit pas qu’une route fonctionne; il ferme l’incertitude sur la fin de la table initiale d’une famille d’adresses. Cette ponctuation tardive éclaire le principe posé dès RFC 1267: une…

Dossier
La clé de route n’a pas changé. Son sens, si : RFC 9871
Dans un domaine, le faible délai porte la couleur C2; dans l’autre, C1. RFC 9871 ne force pas les deux opérateurs à adopter le même dictionnaire. Il maintient la clé `(E2,C2)` et confie la traduction locale à une communauté étendue distincte, LCM-EC.

IETF
Le bilan d’IETF 126 a besoin d’une clé de source pour chaque affirmation
Le nouveau bilan de la réunion de Vienne fait une chose rare et utile: il indique qu’aucun rédacteur ne pouvait suivre toute la semaine et que le texte rassemble agenda, descriptions publiées avant les séances et pièces versées ensuite au Datatracker. Cette transparence situe…

Histoire d'Internet
Le RFC disait VAR pour zéro ; le code en service y lisait VALUE : RFC 1408
Une erreur de protocole n’est pas toujours un paquet rejeté. Elle peut produire deux messages parfaitement plausibles, selon la table que possède le lecteur. Avec l’option Telnet ENVIRON, l’octet zéro désignait le début d’un nom de variable dans RFC 1408, tandis que…

Dossier
Le préfixe était juste, mais le paquet a pris le mauvais accès : RFC 9872
Deux fournisseurs peuvent donner à un même terminal deux chemins IPv6 valides, sans rendre leurs traducteurs NAT64 interchangeables. RFC 9872 replace ainsi le PREF64 dans son véritable contexte: une valeur n'est exploitable que si le terminal sait quel routeur l'a annoncée.

Histoire d'Internet
Le rapport comptait 56 routeurs. Il refusa de faire du cas extrême la norme : RFC 1266
Sept routeurs disparaissent lorsqu’on passe d’une phrase à la suivante. La RFC 1266 en recense d’abord 56 dans sept systèmes autonomes, puis précise que 49, répartis dans six systèmes, appartiennent à l’Internet en exploitation. Les sept autres sont ceux du réseau d’essai T3…

IETF
Colin Perkins et l’événement « Sent » qui ne disait pas « transmis »
Un programme peut savoir qu’il a confié un message à sa pile locale sans savoir si ce message est sorti de la machine. Dans RFC 9622, cosignée par Colin Perkins, l’événement `Sent` décrit précisément ce passage de responsabilité; il ne vaut ni preuve de transmission ni accusé de…

Histoire d'Internet
Le graphe pouvait voyager, à condition d’emporter son histoire de mesure : RFC 1404
Deux centres d’exploitation pouvaient afficher le même mot, « pic », sans avoir mesuré le même phénomène. RFC 1404 répondit moins par un dessin commun que par une discipline de mémoire: conserver l’intervalle réellement observé, la période d’agrégation, la ressource suivie et la…

Dossier
RFC 9873 : une seule règle de divulgation pour deux adresses
Le détail le plus politique de RFC 9873 n'est pas la prise en charge d'une adresse internationalisée. C'est l'interdiction implicite d'en faire une voie latérale moins protégée: la règle de divulgation du contact doit couvrir l'adresse historique et l'adresse supplémentaire…

IETF
Le dossier permanent de soutien de l’IETF a besoin d’un registre public de l’adoption
L’IETF veut faire des réussites de ses protocoles un argument de financement qui s’enrichit dans le temps. L’exercice est légitime, à condition que la narration ne devienne pas sa propre preuve. Dès qu’un chiffre de déploiement passe d’une observation technique à un rapport…

Histoire d'Internet
La liste de contrôle fut retirée. La question de la preuve changea de lieu : RFC 1264
En 1991, un protocole de routage ne devait pas avancer parce que son texte paraissait achevé. La RFC 1264 demandait des pièces distinctes: code indépendant, essais de chaque fonction, démonstration de la sécurité, expérience d’exploitation et analyse du point de rupture. En 2006…
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