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 732 articles
Histoire d'Internet
L’octet disparu est devenu une promesse de la couche liaison : RFC 3408
Sur une ancienne interface radio, un octet supplémentaire pouvait coûter une unité de transmission entière. RFC 3408 a accepté de l’effacer, mais seulement après avoir dressé l’inventaire de ceux qui devraient désormais faire son travail.
IETF
La politique tenait dans un identifiant. La pratique exigeait tout un système.
La politique d’horodatage pouvait être désignée par un identifiant d’objet. La pratique, elle, occupait des procédures, des salles sécurisées, des sources de temps, des cérémonies de clés, des journaux et des décisions d’arrêt. Confondre ces deux échelles revient à croire que le…
Histoire d'Internet
Le terminal disait qu’il pouvait, pas que la session réussirait : RFC 3407
Une liste de codecs ressemblait à un engagement collectif alors qu’elle décrivait souvent plusieurs choix impossibles à exécuter ensemble. RFC 3407 a rendu cette ambiguïté observable.
Récits
AS142207 : le registre continue de vivre après le silence du routage
Le résumé de veille AS142207: le registre continue de vivre après le silence du routage 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. Le…
IETF
Le tableau était vert. Il ne comptait pas le trafic évincé.
Une expérience de contrôle de congestion peut améliorer tous les indicateurs de ses propres flux et dégrader ceux qui partagent le même goulot. RFC 9743 oblige à regarder cette coexistence, puis à distinguer l’étiquette du document, le choix par défaut, la mesure en exploitation…
Histoire d'Internet
Un nom persistant avait besoin d’un plan de succession : RFC 3406
Le danger n’était pas seulement qu’un serveur tombe. Il était qu’une institution disparaisse en laissant derrière elle des noms que personne ne devait recycler. RFC 3406 a placé cette dette au centre de l’architecture.
Histoire d'Internet
L’indice racine devait changer moins souvent que le résolveur : RFC 3405
RFC 3405 installait deux vitesses dans un même système. Le premier indice partagé pouvait rester des années en cache; les règles susceptibles de bouger vivaient derrière lui, dans une autre zone. La stabilité venait de la localisation du changement, non de son interdiction.
IETF
Le diagnostic était juste. Son autorité, elle, avait expiré.
Le RFC 3627 avait correctement décrit un conflit entre un préfixe IPv6 `/127` et l’adresse anycast Subnet-Router. Le RFC 6164 a pourtant recommandé ce même préfixe dans un périmètre précis. Ce renversement montre qu’une preuve peut rester valable alors que la règle qui s’en…
IETF
Mille messages sont arrivés. Les cinq cents plus anciens sont restés hors champ.
Après une semaine d’absence, une boîte reçoit quinze cents messages. Le client en affiche mille, le serveur répond correctement, et rien à l’écran ne dit que le début de la semaine manque. RFC 9738 ne supprime pas ce risque; il donne au client le moyen précis de ne plus le…
Histoire d'Internet
Le même URI pouvait mener à un emplacement, une ressource ou une description : RFC 3404
Dire qu’un URI a été « résolu » ne dit presque rien. RFC 3404 obligeait le demandeur à préciser la nature de la réponse: où se trouve la ressource, quelle instance récupérer, comment la décrire ou sous quel nom persistant la reconnaître.
IETF
Le message avait déjà été vu. Personne n'avait encore prouvé la diffusion.
Dans OLSR, l'ensemble des doublons évite de traiter et de retransmettre sans fin le même message de contrôle. Cette mémoire locale est indispensable à l'optimisation. Elle ne dit pourtant ni jusqu'où le message est allé, ni quelle route a été installée, ni si un paquet applicatif…
Histoire d'Internet
Le premier NAPTR du paquet n’était pas la première règle : RFC 3403
DNS transportait un ensemble de règles sans faire de leur ordre d’arrivée un ordre d’autorité. Avec RFC 3403, le client devait reconstruire la séquence à partir de `ORDER`, puis seulement départager les options d’un même niveau.
IETF
Le silence du client ne valait pas absence d’erreur
Après le redémarrage du serveur de métadonnées, deux clients peuvent ne signaler aucune erreur pour des raisons opposées: l’un a récupéré son fichier sans incident; l’autre a disparu avec sa mémoire. RFC 9737 interdit de confondre ces deux silences.
Histoire d'Internet
Chaque règle réécrivait la clé. Aucune ne pouvait réécrire la chaîne d’origine : RFC 3402
Une délégation peut déplacer le lieu où l’on cherche sans déplacer l’objet que l’on cherche. RFC 3402 a transformé cette nuance en invariant technique: les clés évoluaient d’étape en étape, tandis que la chaîne fournie par l’application restait intacte.
IETF
La table a été vidée. Le réseau devait encore réapprendre juste.
Dans RFC 3619, la purge des tables de pontage évite de conserver une topologie devenue fausse. Elle constitue pourtant un acte d’oubli, pas une preuve de rétablissement: après la purge viennent le réapprentissage, le comportement des paquets et le résultat du service.
Histoire d'Internet
La réponse était signée. DHCP avait choisi le nom qui avait été demandé : RFC 3397
Une validation DNSSEC impeccable ne prouve pas que le résolveur a posé la bonne question. RFC 3397 révéla l’autorité exercée en amont: en fournissant la liste de recherche, DHCP pouvait transformer un nom court en un domaine que l’utilisateur n’avait jamais eu l’intention de…
IETF
Le cache venait d’être rafraîchi. La source pouvait déjà s’être tue.
Avec RFC 3618, une annonce Source-Active pouvait traverser les domaines, être mise en cache puis rejouée à la reconnexion. Ce mécanisme accélérait la construction d’un arbre multicast; il ne transformait ni l’horodatage du cache ni le succès du peer-RPF en observation continue de…
IETF
Le premier routeur attendait BFD. Le second attendait BGP.
Deux équipements peuvent être correctement configurés et rester pourtant bloqués: l'un refuse BGP tant que BFD n'est pas stable, l'autre ne lance BFD qu'après la progression de BGP. Le problème n'est pas l'absence de règle. C'est l'existence de deux règles locales qui se ferment…
Histoire d'Internet
Les champs du paquet étaient dans le désordre. L’option devait pourtant redevenir un seul objet : RFC 3396
Dans DHCPv4, trois emplacements physiques pouvaient porter les morceaux d’une même option, sans même suivre leur ordre dans la mémoire du paquet. RFC 3396 imposa une discipline simple et profonde: reconstruire d’abord, interpréter ensuite.
IETF
Le fichier a démarré la machine. Son origine restait à prouver.
Une machine peut télécharger son image, accuser réception du dernier bloc puis redémarrer sans jamais avoir établi qui a fourni les octets. RFC 3617 donne une adresse commune à cette opération; son avertissement central est que la lisibilité du chemin ne rend pas le transfert…
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