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 661 articles
IETF
L’ancien lien fut libéré à l’ACK. Le désengagement ne faisait que commencer.
RFC 5184 ne décrit pas une bascule instantanée, mais une suite d’observations, de demandes et d’événements entre couches. Confondre l’accusé de réception d’une commande avec son achèvement transforme un gain de vitesse en coupure difficile à expliquer.
IETF
Deux serveurs affichaient « post ». Ils ne décrivaient pas le même monde.
Lors d’une migration, une règle Sieve peut retrouver les mêmes valeurs `location` et `phase` sans retrouver la même architecture. RFC 5183 fournit un vocabulaire de contexte; il ne transporte ni la topologie locale, ni la confiance, ni la preuve de l’effet obtenu.
IETF
Le second SAVE a effacé le sens du premier
Deux recherches IMAP peuvent être valides, deux réponses peuvent être positives et pourtant une seule population demeure derrière le signe `$`. RFC 5182 décrit une case mémoire utile, pas deux dossiers que l’on pourrait rouvrir plus tard.
IETF
Un débit sans protocole de mesure n’est pas une capacité
Le laboratoire n’est pas une miniature du réseau de production. C’est un instrument de mesure. Avec le RFC 5180, sa configuration, ses incertitudes et le chemin réellement exécuté doivent voyager avec le chiffre IPv6.
IETF
Le repli a rétabli la connexion. Il avait aussi changé la question d’autorisation.
RFC 5178 permet d’autoriser un serveur pour un service et un domaine précis. Revenir silencieusement à un nom fondé sur le seul hôte peut sauver l’interopérabilité tout en supprimant la portée qui devait protéger une découverte non sûre.
IETF
Le préfixe absent n’attendait pas : il a été retiré
Dans RFC 5177, une mise à jour explicite ne complète pas simplement l’état antérieur. Elle le remplace: tout préfixe déjà enregistré mais absent de la nouvelle requête doit être supprimé, même si la réponse globale reste positive grâce à un autre préfixe.
IETF
Un identifiant a trouvé trois sessions. La modification devait les toucher toutes — ou aucune.
RFC 5176 ne suppose pas qu’une demande d’autorisation dynamique désigne un seul état de connexion. Lorsque les attributs sélectionnent plusieurs sessions, le NAS doit réussir l’opération sur l’ensemble ou n’en modifier aucune: l’atomicité protège la cohérence, pas la justesse du…
IETF
Le registre avait réservé le bit. Le réseau n’avait pas encore prouvé la fonction.
Entre une ligne IANA et un comportement observable, il existe une chaîne de décisions que les tableaux de bord effacent trop facilement. RFC 5175 organise l’espace des annonces IPv6; il ne certifie ni les logiciels, ni les politiques, ni leurs effets.
IETF
Le message n’avait pas un seul corps pour le filtre.
Le même courriel pouvait être un bloc d’octets, un arbre de parties MIME ou le texte qu’un extracteur réussissait à produire. Le RFC 5173 n’a pas choisi une version comme vérité. Il a donné au script trois surfaces distinctes et, avec elles, trois raisons différentes de trouver…
IETF
Le silence n’était pas une panne. Le mode agressif en a fait une décision.
Le port avait d’abord connu son voisin dans les deux sens. Puis les messages ont cessé. Le RFC 5171 ne prétend pas que ce silence révèle sa cause: il explique quand une politique locale peut néanmoins décider que l’incertitude est devenue trop dangereuse pour laisser le port…
IETF
Le nom persistait. Son statut, lui, avait changé.
Le RFC 5165 a créé un espace mondial pour les noms OGC, tout en laissant l’autorité de nommage gérer les sous-arbres et tolérer des valeurs expérimentales non enregistrées. La leçon durable n’est pas qu’une URN ne change jamais, mais qu’un nom n’est fiable que si son autorité…
Dossier
DFINFRA : la couche contact face au miroir, à la fusion et au déficit de responsabilité
Le résumé de veille DFINFRA: la couche contact face au miroir, à la fusion et au déficit de responsabilité 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…
IETF
Le canal était digne de confiance. L’ordre restait opaque.
Le RFC 5164 imaginait une couche de transport commune pour plusieurs services de mobilité. Elle pouvait découvrir un interlocuteur, protéger l’échange et transporter des octets; elle ne pouvait pas, précisément parce que la charge utile restait opaque, décider seule de la…
IETF
Cinq paquets, une seule enveloppe : le coût caché de PDU-Concat
Le RFC 5163 traite l’agrégation comme une économie comptable: un type, une destination et une enveloppe remplacent plusieurs répétitions. Mais la somme doit tomber juste, faute de quoi l’efficacité devient une perte commune.
IETF
La responsabilité s’arrêtait au prochain domaine. La preuve du trajet, elle, devait continuer.
En limitant chaque garantie QoS au domaine que l’opérateur maîtrise, la RFC 5160 rend la responsabilité bilatérale praticable. Elle ne fait toutefois pas disparaître la performance de bout en bout: elle déplace sur le vendeur du service la charge de composer et de conserver la…
Récits
Hygiène d'enregistrement ou vrai mouvement ? Ce que les éditions 2026 du registre d'AS210328 ont réellement changé
Le résumé de veille Hygiène d'enregistrement ou vrai mouvement ? Ce que les éditions 2026 du registre d'AS210328 ont réellement changé explique le développement, les preuves publiques disponibles, les organisations concernées, le contexte régional, l’exposition au marché et les…
IETF
Le média a changé de flux de clés. Rien ne prouvait que le terminal l’avait vu.
Dans RFC 5159, une association `stkmstream` placée au niveau d’un média remplaçait celle annoncée pour toute la session. Cette règle était précise et utile: deux pistes d’un même service pouvaient dépendre de flux de messages de clés différents. Elle créait aussi un point de…
IETF
Les serveurs étaient prêts. Ils ne certifiaient pas la vérité du PTR.
RFC 5158 cherchait à rendre exploitable la délégation DNS inverse d'un site 6to4. Le service pouvait vérifier que les serveurs proposés répondaient, faisaient autorité et présentaient le même SOA ainsi que les mêmes NS. C'était un contrôle de préparation sérieux. Ce n'était ni…
IETF
Le modèle est arrivé trente et une minutes plus tard. Les données avaient déjà cessé d’exister.
Le collecteur avait reçu les octets, réservé de la mémoire et attendu leur définition. À l’expiration du délai, il les a journalisés puis supprimés. Une minute plus tard, le Template est arrivé. Le réseau venait de livrer les deux pièces nécessaires, mais la politique de durée…
IETF
La frontière était joignable. Elle condamnait pourtant la paire de chemins.
Le prochain ASBR répondait, le segment local respectait les contraintes et le premier LSP atteignait sa destination. Rien, dans ces reçus pris séparément, ne disait que cette sortie préservait assez de liberté pour un second chemin diversifié. RFC 5152 montre pourquoi une…
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