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 586 articles
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…
IETF
Le cookie était authentique. Il ne disait pas si la transaction était terminée.
Après la panne, le nouvel élément du pool a reçu le dernier cookie conservé par l’utilisateur. La signature était valide. Pourtant, ce reçu ne disait ni si l’ancienne requête avait été validée, ni si l’état représenté était encore le plus récent, ni si la nouvelle version du…
IETF
Une séquence relue par le groupe de travail ne devient pas l’unique architecture
RFC 5359 présente des scénarios SIP soigneusement vérifiés et relus collectivement. Cette qualité éditoriale en fait une référence de conception solide. Le même texte précise pourtant que les RFC de protocole restent normatives et que les services peuvent être réalisés autrement…
Histoire d'Internet
L’identifiant d’objet était temporaire. L’application devait se souvenir de ce qu’était le contenu : RFC 3940
RFC 3940 savait livrer un objet à un groupe et réparer les pertes, mais refusait d’en faire un objet durable par le seul pouvoir d’un numéro. Son compteur de transport sur 16 bits appartenait à un émetteur et à un instant de transmission; le souvenir du contenu restait à la…
Histoire d'Internet
Le nom semblait identique. Les octets ont tranché : RFC 3722
Un nom iSCSI devait rester saisissable par une personne sans obliger de petits équipements de stockage à comparer des chaînes « à peu près ». Le RFC 3722 a fixé une préparation commune pour rendre la comparaison reproductible, sans prétendre que les caractères qui se ressemblent…
IETF
La valeur était enregistrée. Le routeur n’avait toujours pas consenti à l’examiner.
Le registre paraissait complet: un numéro, une description, une référence normative et une procédure d’attribution. Pourtant, sur le chemin réel, le routeur pouvait ignorer l’option, transmettre le paquet comme un datagramme ordinaire ou le filtrer avant tout traitement de…
Histoire d'Internet
Le numéro de rappel entra dans l’e-mail. Son sens ne voyagea pas avec lui : RFC 3939
En 2004, conserver un numéro dans un message vocal semblait résoudre un problème de mémoire. RFC 3939 montra pourtant que la copie fidèle d’une chaîne ne transportait ni le plan de numérotation qui la rendait utile, ni la preuve de l’identité humaine qu’on pouvait être tenté de…
IETF
Soustraire le temps du réflecteur améliore la mesure, pas son autorité
RFC 5357 fait inscrire au réflecteur l’heure d’arrivée puis l’heure de départ de chaque paquet TWAMP. Leur différence permet d’isoler le séjour dans le réflecteur. Cette correction rend le calcul plus précis; elle ne transforme pas la valeur obtenue en verdict sur le service, le…
Histoire d'Internet
L’alias disait « Disque local ». La connexion exigeait un autre nom : RFC 3721
Un opérateur peut reconnaître une cible de stockage grâce à un libellé familier, mais le protocole ne peut pas confondre ce libellé avec une identité. RFC 3721 distingue le nom qui dure, l’adresse qui localise, l’identifiant qui authentifie et la règle qui autorise — puis précise…
Histoire d'Internet
Le nom promettait de durer. Son résolveur n’existait pas encore : RFC 3937
RFC 3937 a donné à l’IPTC un espace mondial de noms persistants, mais il a aussi laissé apparaître une distinction décisive: le mot `current` pouvait rester stable tandis que le document désigné changeait. La permanence du nom ne garantissait ni l’immuabilité du contenu, ni même…
IETF
Une nouvelle tentative a réussi. Elle n’a pas authentifié la liste du KDC.
Un client PKINIT peut refuser ses premiers paramètres ECDH, recevoir du KDC une liste ordonnée de solutions de rechange, puis réussir avec l’une d’elles. Cette réussite établit une compatibilité cryptographique à la seconde tentative. Elle ne prouve pas que la liste reçue dans…
IETF
La liste était classée par préférence. Personne n’avait authentifié son ordre.
Le message semblait offrir une sortie propre à un désaccord cryptographique: le KDC refusait la courbe du client, puis renvoyait une liste ordonnée de paramètres acceptables. Il suffisait de reprendre le premier choix commun. Le RFC 5349 révèle la faiblesse de ce raisonnement: le…
Histoire d'Internet
L’objet de localisation pouvait porter des règles, pas seulement des coordonnées : RFC 3693
En février 2004, le groupe GEOPRIV a cessé de traiter la confidentialité comme un simple réglage attaché à une épingle sur une carte. La RFC 3693 a décrit une chaîne d’acteurs et de décisions: qui est localisé, qui fixe les règles, qui conserve la position, qui les applique et…
Histoire d'Internet
Le code était privé. Ses bits de tête commandaient encore chaque routeur ignorant : RFC 3936
Un numéro réservé à un fournisseur ne restait pas enfermé chez lui. Dans RSVP, les premiers bits du numéro de classe indiquaient déjà à un ancien nœud s’il devait refuser tout le message, supprimer seulement l’objet inconnu ou le transmettre intact.
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