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 652 articles
IETF
Le prix ANRP ne fait pas du mémoire une contribution de l’IRTF
Le programme 2026 de l’IRTF a retenu six articles parmi 70 candidatures. Avant l’IETF 127, deux lauréats — Mona Wang et Protick Bhowmick — sont annoncés pour la réunion ouverte de l’IRTF. La règle mérite d’être lue au mot près: l’article primé n’est pas une contribution à l’IETF…
IETF
Le protocole a gagné. Son domaine de conception, lui, n’a pas suivi.
Le succès n’est pas un état final. RFC 5218 montre qu’un protocole devenu utile au-delà de sa fonction ou de son échelle d’origine entre dans une nouvelle zone de responsabilité: il faut de nouveau prouver ses invariants, ses limites et le bénéfice réel pour l’utilisateur.
Histoire d'Internet
L’espace marquait la coupure—jusqu’à ce qu’il faille l’effacer : RFC 3676
En texte « flowed », l’espace final d’une ligne peut séparer deux mots d’origine ou signaler seulement que la phrase continue. Le paramètre `DelSp` indique au logiciel destinataire lequel de ces deux cas il doit reconstruire.
IETF
Le certificat était valide. Le commutateur a pourtant gardé le port fermé.
Une authentification EAP-TLS réussie produit une preuve cryptographique solide. Elle ne transforme pas le serveur EAP en contrôleur omniscient du VLAN, du NAS et du service livré. RFC 5216 devient plus utile lorsque chaque équipe respecte cette limite au lieu de la masquer sous…
IETF
Le chemin de certification existait. La politique exigeait pourtant son rejet.
Une chaîne complète et correctement signée peut conduire à la bonne décision: refuser. RFC 5217 montre pourquoi la circulation entre domaines de PKI ne vaut jamais, à elle seule, autorisation de faire confiance.
Histoire d'Internet
La réponse disait 200 OK. L’inventaire n’était pas terminé : RFC 3624
Le Call Agent avait demandé à une passerelle de rendre compte d’une famille entière de terminaux. La réponse commençait par `200 OK`, précisait quels terminaux avaient effectivement été comptés, puis indiquait le nom du suivant. La transaction avait réussi; l’inventaire, lui…
IETF
Tous les paquets audio sont arrivés. Le décodeur devait pourtant se taire.
Le silence n'était pas la conséquence d'un réseau troué. Il résultait d'une discipline prévue par la norme: après un changement d'Ident, RFC 5215 interdit au récepteur d'interpréter le flux Vorbis tant qu'il ne possède pas la configuration désignée.
IETF
Le DNS avait raison. Le service IPv6 restait pourtant absent.
Dans ISATAP, une liste de routeurs potentiels rend la découverte possible sur un réseau IPv4 sans diffusion générale. RFC 5214 ne demande jamais à cette liste de certifier l’état réel du chemin: cette preuve commence seulement lorsque les machines échangent, routent et livrent.
ICANN
Une référence UCAS pour les labels, sans approbation automatique des registres
Le 5 octobre, l’ICANN a annoncé l’ajout d’un jeu de règles de référence de second niveau pour l’écriture syllabique autochtone canadienne unifiée. La proposition prévoit une utilisation compatible avec des IDN français dans une même zone, mais sa publication ne vaut ni validation…
IETF
Le réseau a parlé au nom du mobile. Qui a vérifié que le mobile était encore là ?
Le LMA accepte la mise à jour, crée son état de tunnel et renvoie un accusé positif. Dans ce scénario, le terminal n'a pourtant émis aucun message de mobilité. RFC 5213 organise précisément cette délégation. Il n'autorise pas pour autant à confondre la parole authentifiée du…
IETF
RFC 5212 : la carte proposait un lien qui n’existait pas encore
Un calculateur peut tracer un passage cohérent entre couche paquet et transport optique alors que la ressource sous-jacente reste à créer. RFC 5212 ne masque pas cet écart: il en fait une propriété explicite du lien TE virtuel.
IETF
Le lien existait dans la topologie. Sa couche inférieure n’existait pas encore.
Le calculateur avait livré une route exploitable. Pourtant, l’un de ses liens n’était ni une fibre réservée ni un LSP déjà établi: c’était la promesse qu’un LSP de couche inférieure serait créé si la couche cliente le choisissait. RFC 5212 donne un nom précis à cette promesse…
IETF
RFC 5210 : trois contrôles d’adresse ne prouvent pas l’identité de l’émetteur
L’expérience SAVA a montré qu’un chemin IPv6 équipé de plusieurs barrières pouvait rejeter les adresses sources forgées. La conclusion utile porte sur un paquet, une couverture et un état de règles; elle ne transforme pas l’adresse en identité mondiale.
IETF
Le calendrier avait basculé. Le réseau restait à prouver.
Un comité peut déclarer l’entrée dans une nouvelle phase à minuit. Les routeurs, les catalogues commerciaux et les applications n’obéissent pas à l’horloge du programme. La borne de janvier 2012 de RFC 5211 organisait une attente collective; elle ne constituait ni une mesure ni…
IETF
Conforme à 9 h, inconnu à 9 h 25 : la frontière temporelle de RFC 5209
Une évaluation NEA ne décerne pas à un terminal une qualité permanente. Elle juge des attributs recueillis, sous une politique donnée, à un instant donné. RFC 5209 prévoit précisément le moment où cette vérité historique ne suffit plus.
IETF
La clé privée était bien formée. Sa protection restait à prouver.
Le résumé de veille La clé privée était bien formée. Sa protection restait à prouver. 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
Les tags des RFC orienteront les alertes : leurs corrections doivent rester visibles
Les nouveaux tags thématiques de RFC-Editor.org ne servent plus seulement à parcourir un catalogue lorsque des lecteurs s’y abonnent. La question de gouvernance porte sur l’information donnée aux abonnés lorsqu’un classement change après l’unique alerte envoyée à la publication.
IETF
Le pair a signé sa nouvelle adresse. Le chemin restait à éprouver.
Un UPDATE HIP peut être irréprochable et annoncer une route qui ne fonctionne pas. La cryptographie attribue la déclaration au pair; elle ne fait ni apparaître une interface, ni converger le routage, ni revenir le paquet de contrôle. RFC 5206 avait un mot précis pour cet…
IETF
Le DNS était à jour, pas le chemin HIP : la limite de RFC 8005
Un enregistrement HIP validé par DNSSEC peut publier fidèlement une identité et un serveur de rendez-vous alors que le chemin d’exécution a déjà disparu. RFC 8005 sépare la découverte, la preuve d’usage de la clé et la joignabilité présente.
Histoire d'Internet
Base64 n’a jamais suffi : RFC 3548 et le profil d’encodage
Deux échanges peuvent transporter les mêmes octets tout en divergeant sur leur forme. En 2003, la RFC 3548 a voulu rendre ces choix explicites, au lieu de laisser les habitudes du courrier électronique devenir les règles implicites d’autres protocoles.
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