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 756 articles
Histoire d'Internet
Le verrou le plus fort était proposé. L’attaquant l’effaça avant le choix : RFC 3329
La première liste de sécurité devait circuler avant que les deux pairs aient choisi le moyen de la protéger. Une suppression suffisait alors à transformer une capacité forte en option prétendument absente. RFC 3329 n’a pas protégé ce premier instant; il a exigé qu’un reçu…
Histoire d'Internet
REGISTER prenait fin ; son chemin servait ensuite : RFC 3327
La liaison répond à « où joindre l’UA ? »; elle ne répond pas à « par quels relais devra passer la prochaine requête ? ». RFC 3327 a donné à ces deux questions des réponses distinctes: le registrar gardait le Contact, tandis qu’un Path ordonné accompagnait cette liaison pour…
Histoire d'Internet
Le registraire connaissait le contact, mais pas encore le chemin pour l’atteindre : RFC 3327
Enregistrer une adresse et savoir lui livrer le prochain appel sont deux opérations différentes. Au début de SIP, une inscription pouvait réussir tout en perdant, dès la réponse envoyée, la chaîne de mandataires indispensable pour revenir vers le terminal. RFC 3327 a donné une…
IETF
Le cache avait mémorisé la réponse, pas le consentement
Un client qui n’a jamais autorisé ECS peut recevoir une réponse adaptée au réseau d’un autre utilisateur si le résolveur conserve les données sans conserver leur provenance.
IETF
Le repli a sauvé la requête. Il a aussi effacé la panne du protocole
Le navigateur a abandonné ECN, refait un SYN ordinaire et chargé la page. La RFC 3360 oblige à conserver l’autre récit: un équipement de chemin avait peut-être transformé son ignorance de deux bits en décision attribuée au serveur.
Récits
Chez RIPE, le flux d’updates de RRC12 s’est grippé après un afflux venu de DE-CIX
RIPE NCC indique qu’un volume inhabituellement élevé de messages BGP envoyé par un pair de DE-CIX a fait expirer à répétition le processus chargé de publier les fichiers de RRC12. Lors de la vérification, l’archive s’arrêtait encore à 01 h UTC le 2 octobre.
Histoire d'Internet
Le téléphone cessa de sonner ; le protocole devait conserver la raison : RFC 3326
Une annulation peut raconter deux histoires opposées tout en produisant exactement le même silence. RFC 3326 a donné à SIP un moyen de transporter l’événement déclencheur sans confondre cette explication avec la commande qui arrêtait l’appel.
IETF
Le résolveur a ignoré le serveur qui répondait encore
La délégation contenait un nouveau type censé remplacer NS, ainsi qu’un ancien enregistrement NS parfaitement joignable. Le résolveur a écarté ce dernier. Ce refus n’était pas une panne de repli: c’était précisément la règle de sécurité choisie par le protocole.
Histoire d'Internet
Le CANCEL portait la cause ; SIP exécutait toujours l’annulation : RFC 3326
Quand une branche répond à un appel forké, le proxy peut interrompre les autres branches et joindre une explication brève. RFC 3326 rend cette explication transportable sans lui confier l’action protocolaire.
Histoire d'Internet
L’utilisateur choisissait une identité préférée ; le proxy devait effacer ce choix : RFC 3325
Une préférence pouvait entrer dans le proxy, influencer sa décision, puis devait disparaître. RFC 3325 ne traitait pas cette disparition comme une optimisation de taille: elle empêchait la parole de l’utilisateur de voyager sous l’apparence d’une preuve produite par le réseau.
IETF
Le port de console portait le bon nom. Le câble allait vers un autre routeur
Une étiquette peut rendre un chemin de secours rassurant sans le rendre vrai. La RFC 3871 demandait déjà une console indépendante des plans IP et de forwarding; l'exploitation doit encore prouver l'identité de l'équipement, l'autorité de l'opérateur et le retour du service.
Histoire d'Internet
Ils partageaient un domaine de confiance sans se faire confiance : RFC 3324
Le dessin de RFC 3324 contient une anomalie volontaire: A et B sont placés dans le même domaine, mais A ne fait pas confiance à B. Le périmètre dit qui est censé suivre les mêmes règles; seule une liaison vérifiée dit ce qu’un récepteur peut croire.
Récits
Le chiffre de LACNIC sur la sécurité de 47 universités manque de dénominateur
Dans son récapitulatif de septembre, LACNIC reprend une amélioration marquée de la part d’universités équatoriennes classées au niveau critique en matière de sécurité. Les sources publiques donnent les pourcentages et décrivent le groupe suivi, mais pas les effectifs qui…
IETF
Le PDF était privé. La référence, elle, était valide
Un service a extrait l’identifiant d’une pièce jointe depuis une réponse JMAP, puis l’a injecté dans un objet partagé avec toute une équipe. Le chemin était juste, le type conforme et l’écriture autorisée. Pourtant, le document venait de franchir une frontière que chacun de ces…
Histoire d'Internet
L’appelant était anonyme pour le destinataire, pas pour le service de confidentialité : RFC 3323
Le mot `critical` transformait une préférence de confidentialité en règle d’échec: si le réseau ne pouvait pas masquer l’identité demandée, il devait refuser la requête plutôt que l’acheminer à découvert.
Histoire d'Internet
Masqué pour les autres, joignable dans le dialogue : RFC 3323
La RFC 3323 ne faisait pas disparaître l’appelant SIP. Elle posait une question plus précise: quelles informations d’identité le destinataire peut-il voir, et quel état un service doit-il conserver pour que l’échange continue ?
IETF
L’adjacence venait de renaître, le LSP appartenait encore au routeur d’avant
Le calcul SPF n’avait reçu aucun objet manifestement faux. Les voisins annonçaient une adjacence qu’ils venaient réellement d’établir; le LSP de l’autre extrémité avait réellement été émis par ce routeur. Pourtant, l’ensemble décrivait deux incarnations différentes et autorisait…
Histoire d'Internet
Les 4,131 secondes n’existaient que dans le modèle : RFC 3322
Le mot le plus important de la RFC 3322 n’est peut-être pas « compression », mais « grossière ». En qualifiant ainsi sa propre approximation, le document protégeait son calcul contre une fausse promotion au rang de mesure universelle.
IETF
Les deux noms étaient valides ensemble, jamais l’un après l’autre
Le serveur refusait de renommer `current.txt` en `previous.txt`, puis refusait l’opération inverse. Chaque étape intermédiaire violait l’unicité alors que l’état final demandé était parfaitement cohérent. Il manquait moins un ordre d’exécution qu’une frontière de décision.
Histoire d'Internet
L’accusé disait que l’état avait existé, pas qu’il existait encore : RFC 3321
Dans SigComp, même le « point de contrôle » le mieux classé pouvait disparaître. La RFC 3321 ne transformait donc pas l’accusé de création en bail perpétuel: elle obligeait le compresseur à faire vieillir sa connaissance de la mémoire distante.
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