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 647 articles
IETF
Le chronomètre a démarré avant le départ du paquet. La relance a aggravé l'attente.
Un enregistrement DTLS attend encore dans la file régulée par DCCP. Pourtant, la couche supérieure ne reçoit pas de réponse, conclut trop tôt à une perte et ajoute une copie derrière l'original. RFC 5238 montre qu'un délai d'expiration n'est crédible que si son point de départ…
Histoire d'Internet
L’adresse était déjà là. DHCPv6 avait encore un rôle : RFC 3736
Un hôte IPv6 pouvait former son adresse sans la demander à DHCPv6 et avoir tout de même besoin des paramètres DNS ou d’autres services du réseau. La RFC 3736 a isolé cette seconde tâche dans un échange bref; l’absence d’horloge de renouvellement a ensuite imposé une question…
IETF
Les paquets sont arrivés dans le désordre. La métrique n’en a pas nommé la cause.
Une mesure peut être exacte dans son périmètre et trompeuse dans le récit qu’on lui fait porter. Les densités RD et RBD de la RFC 5236 décrivent une séquence reçue et un besoin théorique de remise en ordre. Elles ne désignent ni l’équipement responsable, ni le mécanisme du…
IETF
Le filtre a répondu zéro. Rien ne prouvait pourtant que le message avait été contrôlé.
Dans une chaîne de messagerie, le même zéro peut clore deux histoires opposées: un contrôle a conclu à l'absence de spam, ou aucun contrôle exploitable n'a eu lieu. RFC 5235 rend le résultat comparable entre implémentations. Il ne transforme pas cette comparaison en preuve…
IETF
La clarification de l’IETF sur RFC 1602 doit garder sa borne de date
L’IETF LLC indique que le conseil juridique a fait remonter aux règles de RFC 1602 les droits de réutilisation dans les travaux de normalisation. Or ce texte de 1994 fixe une date d’effet au 1er avril et prévoit une démarche distincte pour les documents antérieurs: la future page…
Histoire d'Internet
Le logo pouvait être vérifié. Il ne validait pas le certificat : RFC 3709
En 2004, RFC 3709 a ajouté une fonction graphique à l’écosystème des certificats X.509, tout en refusant d’en faire une preuve de validité. L’image pouvait être comparée à une empreinte inscrite dans le certificat et aider une personne à reconnaître un émetteur, un sujet ou une…
IETF
Un expert figurait au registre. Son mandat restait à écrire.
RFC 5226 a résolu un problème de continuité: confier l’examen des demandes à une personne compétente lorsque le groupe qui avait créé le registre n’existait plus. Mais nommer un expert ne définit ni la preuve exigible, ni les motifs de refus, ni la limite de sa discrétion. Ces…
IETF
Le paquet était valide. L’état qu’il préparait restait à prouver.
RFC 5225 distingue deux réussites que les tableaux de bord confondent volontiers: reconstruire correctement l’en-tête présent et mettre à jour correctement l’état qui servira aux paquets suivants. Dans `co_repair`, ROHCv2 ne confie pas ces deux affirmations au même contrôle.
Histoire d'Internet
Le doublon est arrivé. Le verdict d’absence de perte, non : RFC 3708
Un récepteur peut signaler qu’un segment est arrivé deux fois. En 2004, la RFC 3708 invitait l’émetteur à ne pas transformer ce constat isolé en verdict d’absence de perte pour toute une fenêtre de récupération.
IETF
La décision est revenue. Son exécution n’était pas encore acquise.
Dans RFC 5224, Diameter sait transporter une demande de traitement de politique et sa réponse. Ce trajet ordonne le dialogue entre machines; il ne transforme pas l’accusé de décision en preuve que l’action a été installée, activée et observée.
IETF
Le réseau a fourni un domaine LoST, pas une autorité
RFC 5223 définit une étape de découverte, non un certificat de confiance. Le réseau d’accès peut remettre par DHCP un nom de domaine LoST, mais ce nom doit encore traverser la résolution DNS et U-NAPTR, l’authentification du service et la requête de cartographie. Le pointeur reçu…
IETF
Le réseau a fourni un nom. L’autorité restait à démontrer.
Dans RFC 5223, le DHCP ne livre ni une cartographie d’urgence ni une preuve de confiance. Il transmet un seul nom de domaine à partir duquel le terminal peut commencer une découverte LoST. Toute la gouvernance du risque tient dans ce mot: commencer.
IETF
La politique d’adresses est arrivée. Sa portée, elle, reste à prouver.
RFC 5221 révèle une faiblesse de gouvernance que les tableaux de déploiement masquent facilement: une politique centrale peut être authentique, reçue et installée partout, tout en étant inadaptée au nœud, à l’application, à l’interface ou au prochain saut qui déterminent…
IETF
Le serveur a donné la bonne URI. L’appel n’avait pas encore commencé.
LoST sait répondre avec précision à une question de traduction: quel point de contact correspond à ce service et à cette localisation déclarée ? RFC 5222 devient trompeur seulement lorsqu’une organisation confond cet itinéraire calculé avec l’arrivée effective d’un appel…
Histoire d'Internet
Une liste de contacts vide restait un état : RFC 3680
En SIP, connaître les terminaux enregistrés ne suffisait pas à décrire une adresse. RFC 3680 lui attribua un état même sans contact, puis confia aux abonnés la reconstruction des changements — sans confondre inscription, présence et joignabilité.
IETF
Le prix ANRP ne fait pas du mémoire une contribution de l’IRTF
Le programme 2026 de l’IRTF a retenu six articles parmi 70 candidatures. Avant l’IETF 127, deux lauréats — Mona Wang et Protick Bhowmick — sont annoncés pour la réunion ouverte de l’IRTF. La règle mérite d’être lue au mot près: l’article primé n’est pas une contribution à l’IETF…
IETF
Le protocole a gagné. Son domaine de conception, lui, n’a pas suivi.
Le succès n’est pas un état final. RFC 5218 montre qu’un protocole devenu utile au-delà de sa fonction ou de son échelle d’origine entre dans une nouvelle zone de responsabilité: il faut de nouveau prouver ses invariants, ses limites et le bénéfice réel pour l’utilisateur.
Histoire d'Internet
L’espace marquait la coupure—jusqu’à ce qu’il faille l’effacer : RFC 3676
En texte « flowed », l’espace final d’une ligne peut séparer deux mots d’origine ou signaler seulement que la phrase continue. Le paramètre `DelSp` indique au logiciel destinataire lequel de ces deux cas il doit reconstruire.
IETF
Le certificat était valide. Le commutateur a pourtant gardé le port fermé.
Une authentification EAP-TLS réussie produit une preuve cryptographique solide. Elle ne transforme pas le serveur EAP en contrôleur omniscient du VLAN, du NAS et du service livré. RFC 5216 devient plus utile lorsque chaque équipe respecte cette limite au lieu de la masquer sous…
IETF
Le chemin de certification existait. La politique exigeait pourtant son rejet.
Une chaîne complète et correctement signée peut conduire à la bonne décision: refuser. RFC 5217 montre pourquoi la circulation entre domaines de PKI ne vaut jamais, à elle seule, autorisation de faire confiance.
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