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 732 articles
Histoire d'Internet
L’émetteur voyait la perte, pas sa cause : RFC 3155
Une fenêtre TCP qui se contracte raconte une décision, pas nécessairement un embouteillage. En août 2001, RFC 3155 partait de cette dissociation. Sur une liaison sujette aux erreurs, un segment corrompu pouvait produire, à l’extrémité, le même silence qu’un paquet éliminé dans…
Histoire d'Internet
Le relais ajoutait un en-tête. La fin du message pouvait disparaître : RFC 3164
Dans l’ancien format BSD syslog, un relais pouvait rendre un message plus lisible en lui ajoutant une date et un nom d’hôte. Mais RFC 3164 plafonnait le paquet entier à 1 024 octets: cet en-tête pouvait prendre la place de la fin du message.
IETF
Le domaine autorisait une question, pas une action
Avec `dialogue.txt`, un domaine pourrait indiquer publiquement qu’un lecteur inconnu — humain ou logiciel — peut poser une question. La proposition n’a pourtant rien d’un mandat numérique: la remise d’un message n’ouvre pas le dialogue, la réponse ne confère aucun pouvoir d’agir…
Histoire d'Internet
Le récepteur proposait le multiplexage. L’émetteur décidait encore de l’utiliser : RFC 3153
Un accord de protocole n’est pas toujours une promesse d’action. Dans RFC 3153, le récepteur PPP annonçait qu’il savait décomposer des trames multiplexées; l’émetteur obtenait alors le droit de les produire, sans en recevoir l’ordre. Cette séparation, publiée en août 2001 pour…
Récits
Dans RPKI, une identité plus moderne ne réduit pas automatiquement le pouvoir
Deux lignes du programme RPKI de RIPE NCC doivent être lues ensemble. La première annonce le remplacement progressif des clés d’API par des identifiants fondés sur OpenID Connect. La seconde explique pourquoi une balise de routage n’a pas été déployée: l’API envisagée aurait pu…
Histoire d'Internet
Le serveur avait besoin d’un troisième défi : RFC 3163
Dans le mécanisme mutuel de RFC 3163, une troisième valeur aléatoire n’était pas un ornement. Elle répondait à un décalage d’ordre: le client avait déjà vu le premier défi du serveur lorsqu’il choisissait sa propre valeur aléatoire. La correction reste toutefois limitée, tout…
Histoire d'Internet
Le nouvel arbre inverse existait avant la disparition de l’ancien : RFC 3152
Une migration Internet ne se produit pas au moment précis où un texte normatif change de nom. En août 2001, RFC 3152 plaça la résolution inverse IPv6 sous `IP6.ARPA`, demanda la délégation de ce domaine et déclara `IP6.INT` impropre aux nouvelles implémentations. L’ancien arbre…
IETF
Le système de cartographie ignorait la destination. Il a tout de même indiqué une sortie.
Une proposition LISP permet de choisir dynamiquement une passerelle pour une destination externe absente du système de cartographie. L’idée est utile, mais son vocabulaire peut tromper: trouver une sortie n’est ni identifier l’arrivée, ni démontrer que la route au-delà de la…
IETF
Une mesure en laboratoire ne tranche pas la qualité du réseau réel
À qui appartient la décision de déclarer un service « assez bon » ? Le projet de groupe BPM de l’IETF veut réunir les méthodes d’essai et de mesure, mais sa nouvelle charte distingue les conditions d’observation et laisse la barre d’acceptation à ceux qui exploitent ou achètent…
Histoire d'Internet
L’IPv6 devait attendre l’authentification : RFC 3162
Le serveur d’accès devait autoriser la session avant de savoir quel protocole Internet utiliserait l’hôte. RFC 3162 a permis à un échange RADIUS de transporter les deux possibilités, puis laissé la décision d’applicabilité au bord du réseau.
ICANN
Les 1 616 dossiers de l’ICANN ne sont pas encore 1 616 extensions
Le « Reveal Day » rendra enfin visibles les ambitions déposées pour le prochain cycle des nouveaux gTLD. Cette transparence modifiera les rapports de force, mais elle ne mettra pas les chaînes révélées dans la racine du DNS. Entre l’inventaire public et un espace de noms…
Histoire d'Internet
L’ancien nom est devenu une URN, sans se résoudre tout seul : RFC 3151
XML avait hérité d’identifiants publics capables de survivre à une machine, mais incapables d’entrer tels quels dans toute interface exigeant une URI. RFC 3151 leur donna une transcription précise en `urn:publicid:`. Cette passerelle rendait le nom normalisé comparable et…
IETF
Le DHCP annonce 1 Gbit/s. Il n’a pas déplacé le goulot d’étranglement.
Une nouvelle option DHCP peut transmettre le débit de service que l’opérateur souhaite voir appliqué. Elle rend une politique portable entre plusieurs équipements. Elle ne mesure ni le chemin d’accès, ni la file réelle, ni le service finalement obtenu.
Histoire d'Internet
Un paquet pouvait faire attendre les autres : RFC 3150
Sur une liaison très lente, la taille d’un paquet détermine aussi combien de temps les autres usagers de l’interface doivent attendre. RFC 3150 a fait de cette durée une contrainte de conception, au-delà de la seule efficacité en octets.
Récits
DFINFRA : le deuxième étage opérationnel — le bloc 193.20.0.0/15 reste routé en direct par AS197909 pendant que la couche enregistrement demeure gelée
Le résumé de veille DFINFRA: le deuxième étage opérationnel — le bloc 193.20.0.0/15 reste routé en direct par AS197909 pendant que la couche enregistrement demeure gelée explique le développement, les preuves publiques disponibles, les organisations concernées, le contexte…
Histoire d'Internet
L’agent d’appel contrôlait les fonctions. Le bouton muet restait local : RFC 3149
MGCP plaçait l’intelligence d’appel hors du téléphone, mais RFC 3149 ne fit pas de chaque geste un aller-retour réseau. L’agent distant interprétait les touches numérotées et pilotait l’écran; le volume, le passage immédiat du combiné au haut-parleur et la coupure du microphone…
Histoire d'Internet
Un même chemin pouvait produire deux mesures de capacité valides : RFC 3148
Une mesure de transfert massif sur un seul flux semblait tenir dans un chiffre. RFC 3148 montre pourquoi les choix de transport pouvaient rendre ce chiffre dépendant de la méthode — et pourquoi la trace qui l’accompagne comptait.
IETF
Huit réponses STAMP ne font toujours pas une mesure de l’application
Avec le RFC 10052, un seul paquet de test peut demander une rafale de réponses asymétriques. Le mécanisme rapproche la forme d’une sonde de certains trafics applicatifs; il ne transforme ni la sonde en application, ni le bit C en verdict de capacité, ni la réception d’une rafale…
Histoire d'Internet
Le nouveau réseau de gestion devait traverser l’ancien : RFC 3147
Le mot « migration » suggère qu’une infrastructure en remplace une autre d’un seul mouvement. RFC 3147 conserva une image moins nette: un équipement récent, géré par IP, pouvait se trouver derrière un réseau CLNS que l’exploitant ne pouvait pas encore retirer. Transporter GRE…
IETF
Le lien figurait comme endormi. Personne n’avait prouvé son réveil.
Conserver dans IS-IS la mémoire d’une ressource mise en veille est une bonne idée: le calculateur sait qu’elle existe encore. Le danger commence lorsque cette mémoire devient, sur un tableau de bord, la preuve que le matériel dort réellement, qu’un chemin de réveil subsiste et…
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