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 579 articles
IETF
Le 202 est arrivé avant les trois BYE. Il ne pouvait donc pas raconter leur résultat.
Le serveur de conférence a accepté une demande unique, puis seulement ensuite a produit trois transactions distinctes. Cette chronologie, dessinée dans la RFC 5368 elle-même, interdit une conclusion pourtant tentante: la réponse au REFER n’est pas le reçu collectif des opérations…
Récits
Le calendrier IPv4 d’ARIN tient en un trimestre et une date
Dans son annonce du 7 octobre, ARIN situe la prochaine distribution IPv4 de la liste d’attente à la fin du quatrième trimestre 2026. La page d’état en cours indique, elle, le 4 janvier 2027 environ. Aucune de ces formulations ne promet une date de livraison à un demandeur; leur…
Histoire d'Internet
Le tunnel acceptait le paquet. La décapsulation effaçait sa trace la plus proche : RFC 3964
Le danger historique de 6to4 ne tient pas seulement à l'usurpation d'adresse. Il tient au moment précis où une machine accomplit correctement son travail: elle retire l'enveloppe IPv4, livre le paquet IPv6 à l'étape suivante et peut, ce faisant, faire disparaître l'indice qui…
Histoire d'Internet
Répondre à tous pouvait réutiliser l’autorisation de fax : RFC 3965
Une passerelle fax pouvait apparaître comme un simple destinataire de courriel. La RFC 3965 souligne pourtant qu’elle pouvait transformer ce message en appel téléphonique payant — et qu’une réponse collective, même innocente, risquait de réemployer l’autorisation d’un expéditeur…
IETF
Le serveur avait accepté l’abonnement. Il n’avait encore prouvé l’état d’aucune ressource.
La réponse positive concernait un dialogue entre le client et le serveur de listes. Derrière ce dialogue, trois URI exigeaient encore trois observations. La RFC 5367 refuse de faire parler le premier statut au nom de ces ressources: ce sont les notifications qui indiquent si le…
IETF
Le 200 OK a ouvert la conférence. Aucun invité n’avait encore rejoint.
La réponse paraissait clore l’opération: la conférence existait, l’organisateur y était entré et le serveur avait compris la liste jointe à l’INVITE. La RFC 5366 refuse pourtant d’en déduire davantage. Le 200 ne dit pas qu’un seul des invités a été appelé, admis, connecté aux…
Histoire d'Internet
Le projet est devenu une référence, mais la norme différait : RFC 7142
RFC 1142 a rendu un projet ISO facile à citer par les lecteurs d’Internet. En 2014, RFC 7142 a tenté de réorienter ces références: le texte reproduit n’était pas la norme finalement publiée.
Histoire d'Internet
Le téléphone annonçait une sonnerie. L’appelant devait encore écouter les paquets : RFC 3960
Dans un appel SIP, le correspondant pouvait être alerté sans qu’aucune tonalité ne traverse le réseau. Le poste de l’appelant comblait alors le silence, puis cédait la place aux médias reçus: une continuité sonore construite avec deux autorités différentes.
IETF
Le nom de l’expéditeur est resté. Son autorité, elle, a changé de mains.
Bob a vu Alice dans le champ From. Pourtant, le message qu’il recevait n’était pas la continuation transparente de la transaction d’Alice. Le service de liste avait terminé un premier échange, appliqué une règle de confidentialité, puis créé une nouvelle requête. Préserver un nom…
Histoire d'Internet
L’adresse de groupe nommait son point de rendez-vous. Elle ne prouvait pas son existence : RFC 3956
Avec la RFC 3956, une adresse multicast IPv6 devenait aussi une instruction de calcul: elle indiquait quel RP essayer. La même formule donnait le même candidat partout, sans transformer ce candidat en route, service ou preuve de livraison.
Histoire d'Internet
Pourquoi marquer par paquet, mais interpréter par octet : RFC 7141
En 2014, l’IETF a séparé la production d’un signal de congestion de l’interprétation de son poids. Le réseau ne devrait pas avantager les petits paquets au moment du marquage; le transport peut, lui, tenir compte du nombre d’octets signalé.
IETF
La liste reçue n’était pas la liste d’origine : le relais avait construit une vue pour ce destinataire
La RFC 5364 ne demande pas au relais de recopier une liste maîtresse dans chaque requête SIP. Elle lui demande d’en produire une projection adaptée au destinataire: certains URI restent visibles, les copies cachées disparaissent, et des entrées anonymisées peuvent ne laisser…
Récits
Quand une liste TLS autorisée qualifie l’avenir de non conforme
Une étude de 50,7 millions de poignées de main TLS observe que quatre référentiels nationaux peuvent classer de 14 % à 80 % du même trafic institutionnel comme non conforme. Cet écart ne mesure pas directement l’insécurité: il montre ce qui se joue lorsqu’une liste datée devient…
Histoire d'Internet
Le paquet ne portait aucun compte de trames. Le récepteur devait diviser : RFC 3952
La RFC 3952 n’a pas mis le nombre de trames iLBC dans la charge RTP. Elle a préféré une économie conditionnelle: la longueur devenait un compte seulement si le récepteur possédait encore le mode négocié.
Histoire d'Internet
Le pair pouvait invalider le STag ; la couche locale devait quand même vérifier : RFC 7145
Une commande de stockage RDMA peut être terminée sans que l’autorisation mémoire qu’elle a exposée ait disparu. RFC 7145 confie donc la vérification finale à l’initiateur: la réponse distante peut contribuer à invalider le STag, mais elle ne prouve pas à elle seule que l’état…
Récits
AFRINIC ratifie trois politiques, mais leur mise en œuvre suivra des calendriers distincts
Les décisions du 25 septembre portent sur les adresses IPv4 récupérées, les exceptions d’utilisation et les nouveaux noms d’AS-SET. Les documents d’AFRINIC montrent aussi pourquoi « ratifié » ne signifie pas « déjà en vigueur ».
IETF
Un destinataire n’avait pas consenti. Aucun envoi ne devait partir.
Neuf autorisations étaient valides. La dixième manquait. Le service n’avait donc pas neuf messages à envoyer et un cas à écarter: il avait une opération indivisible qui ne pouvait pas commencer. La règle de la RFC 5363 est plus exigeante que le filtrage opportuniste.…
IETF
La permission réside au relais, pas dans le carnet d’adresses de l’administrateur
Dans RFC 5360, le gestionnaire d’une liste peut proposer une nouvelle adresse, mais cette modification ne donne pas au relais le droit d’y envoyer du trafic. Le destinataire doit consentir à une traduction précise, puis le relais doit conserver et appliquer cette permission.…
Histoire d'Internet
Quatre octets nuls séparaient IKE d’ESP. Ils n’authentifiaient ni l’un ni l’autre : RFC 3948
Une seule règle de pare-feu et une seule association NAT pouvaient laisser passer la négociation IKE, les données ESP protégées et l’entretien du chemin. Pour rendre ce partage possible, la RFC 3948 réservait quatre octets nuls à l’aiguillage vers IKE. Ce choix disait quel…
Histoire d'Internet
Le chiffrement atteignait sa limite avant la fin de session : RFC 7146
Dans le stockage en blocs, une association de sécurité peut encore servir une session utile alors que le volume chiffré sous sa clé approche déjà une limite importante. RFC 7146 a intégré ce décalage au contrat d’interopérabilité: un algorithme autrefois obligatoire à implémenter…
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