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 699 articles
Histoire d'Internet
La MIB se souvenait de la dernière commande. Elle ne prouvait pas que la commutation restait active : RFC 3498
Les octets K1/K2 reçus et émis pouvaient démentir une commande pourtant fidèlement conservée. RFC 3498 faisait de cette contradiction une propriété normale du système.
IETF
Le compteur a chuté, pas nécessairement le trafic : relire RFC 5132
À 14 h 03, un compteur de route multicast affichait plusieurs milliards d’octets. Au relevé suivant, il était presque revenu à zéro. Le graphique annonçait un effondrement du trafic; la ligne de la MIB avait en réalité été remplacée. RFC 5132 donne les indices pour distinguer ces…
IETF
Le réseau a préservé le chiffré. Il n’a toujours pas prouvé la session sûre : RFC 9607
Avec RFC 9607, un réseau peut reconnaître SCIP sans prétendre comprendre son trafic chiffré. Cette retenue protège l’interopérabilité; elle ne certifie ni l’identité du correspondant, ni l’achèvement de la négociation de sécurité, ni l’arrivée d’un média intelligible.
Histoire d'Internet
La séquence sur 32 bits comptait 1,485 Gbit/s. Elle ne contrôlait pas la congestion : RFC 3497
Le récepteur pouvait savoir exactement quels paquets manquaient et devoir quand même quitter la session. RFC 3497 distinguait ainsi la qualité de la preuve de la capacité du réseau.
Dossier
almazcloud.network : l'opérateur invisible sur son propre réseau
Le résumé de veille almazcloud.network: l'opérateur invisible sur son propre réseau 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…
Histoire d'Internet
Le PATH demandait CBR. Il n’installait aucun ordonnanceur : RFC 3496
Le message RESV revenait sans l’objet de classe. Son succès ne répétait donc jamais la promesse CBR envoyée dans l’autre sens.
IETF
Un inscrit populaire a désigné la victime. Les autres ont fourni le trafic : RFC 5128
Une adresse découverte n’est pas seulement une destination possible. Elle peut devenir un levier: si un inscrit désigne l’adresse d’un tiers, chaque pair qui tente de le joindre ajoute sa propre sonde. RFC 5128 impose alors une frontière de responsabilité nette: avant un échange…
IETF
La réponse faisait autorité. Le résolveur pouvait encore se tromper : RFC 9606
RFC 9606 permet à un résolveur DNS de publier quelques propriétés de confidentialité et de filtrage dans un format commun. L’authenticité de cette déclaration ne garantit pourtant pas l’exécution qu’elle décrit.
Histoire d'Internet
DHCP choisissait le domaine Kerberos avant que Kerberos puisse le juger : RFC 3495
Un certificat parfaitement valable pouvait arriver devant le mauvais KDC. La cryptographie jugeait alors le demandeur, mais pas la décision DHCP qui l’avait conduit jusque-là.
IETF
Le domaine a changé la marque. À la sortie, il devait rendre l’identité du service : RFC 5127
La RFC 5127 autorise un réseau à réunir plusieurs classes Diffserv dans un même traitement, voire à employer un marquage local. Elle lui refuse cependant le droit de perdre l’identité reçue: l’agrégation est une décision de transmission locale, non un transfert de propriété sur…
Histoire d'Internet
L’implémentation conforme n’aurait pas interopéré : RFC 3494
Entre `organizationName` et `o`, il n’y avait qu’une abréviation. En 2003, cette lettre condensait pourtant la rupture entre la norme LDAPv2 et le protocole réellement parlé.
Histoire d'Internet
Un seul bind pouvait occuper deux familles de protocoles : RFC 3493
Deux serveurs devaient partager le même numéro de port, chacun pour une famille. Le premier démarré pouvait pourtant réserver un territoire plus large que son nom ne le laissait entendre.
IETF
Le certificat portait le préfixe, pas l’identité de l’AS : RFC 9582
Dans un ROA, l’absence de l’extension de ressources AS n’est pas une lacune. Le RFC 9582 l’exige, car le certificat et la charge signée n’exercent pas la même autorité.
IETF
Le retour était chiffrable ; le choix du profil restait attaquable : la frontière de la RFC 5124
La RFC 5124 associe le retour RTCP rapide d’AVPF à la protection SRTP/SRTCP de SAVP. Mais la sécurité du paquet ne remonte pas dans le temps pour protéger une négociation vulnérable, et les octets ajoutés consomment le budget qui détermine si le retour reste utile.
Histoire d'Internet
La traîne ASCII encodait la position, pas le sens : RFC 3492
Punycode ne cherchait pas à rendre un mot intelligible. Il conservait, dans un alphabet ASCII étroit, l’arithmétique nécessaire pour reconstruire exactement une suite de points de code.
IETF
Le défi est arrivé. Le client ne devait aucun jeton : RFC 9577
Un serveur peut formuler une demande `PrivateToken` parfaitement conforme sans acquérir le droit d’interpréter le silence. Le RFC 9577 organise précisément cet espace entre invitation, réponse et décision.
Histoire d'Internet
ToUnicode n’échouait jamais. Le nom n’en était pas valide : RFC 3490
En 2003, l’internationalisation des noms de domaine ne consistait pas à rendre le DNS multilingue. Elle consistait à ménager un passage contrôlé entre ce que l’utilisateur pouvait lire et ce que l’infrastructure pouvait accepter.
IETF
Même station de base, liens IPv6 différents : ce que RFC 5121 refuse de confondre
Deux abonnés peuvent partager la même technologie radio, le même site et la même station de base sans appartenir au même lien IPv6. RFC 5121 oblige à regarder au-delà de la proximité physique: le lien utile est celui qui relie une station mobile à son routeur d’accès, avec ses…
Histoire d'Internet
Le type de NAT n’était qu’un instantané. Le pair avait besoin d’un chemin : RFC 3489
Le STUN classique donnait un nom stable à un comportement observé depuis un serveur précis. La révision conserva la mesure, mais retira au nom son pouvoir de verdict.
IETF
Le réplicateur s’annonçait prêt. La feuille attendait encore trois secondes : RFC 9574
Dans RFC 9574, le délai par défaut n’est pas un détail de confort. Il révèle l’intervalle où le plan de contrôle connaît le réplicateur alors que le plan de transfert peut encore ignorer la feuille.
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