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 561 articles
IETF
LWAPP est une archive historique, pas une base de déploiement
Le RFC 5412 conserve l'état du Lightweight Access Point Protocol au moment où il a été soumis aux travaux CAPWAP. Il éclaire l'architecture contrôleur–point d'accès, mais le RFC Editor le classe Historic et indique qu'il ne doit pas servir de base à un déploiement. Le RFC 5415…
Dossier
À la PP-26, la parole a sa file ; les décisions ont besoin d’une autre trace
Cent quatre-vingts secondes peuvent suffire à rendre une priorité visible, sans suffire à raconter ce que la Conférence en fera. Avant l’ouverture de la PP-26, l’UIT a déjà fixé une procédure pour les déclarations de politique générale: un intervenant par délégation, des demandes…
IETF
CATS a choisi le contact du service. Le backend est resté caché : RFC 10053
CATS peut orienter une requête vers un point de contact prometteur à partir de l’état du réseau et des ressources de calcul. Ce choix ne révèle pas nécessairement quelle instance interne traitera la requête, ni si les métriques publiées décrivent cette instance seule.
Histoire d'Internet
Le contrôleur devait d’abord disposer d’un réseau pour le piloter : RFC 7149
En mars 2014, un mémo de l’IETF invitait les opérateurs à dépasser le schéma séduisant du contrôleur central. Comment celui-ci découvre-t-il les équipements, les atteint-il et influence-t-il sans risque le réseau qu’il gouverne ? RFC 7149 place le démarrage, la négociation du…
IETF
Un guide SIP est une carte, pas un certificat de déploiement
Le RFC 5411 aide à s'orienter dans une famille SIP devenue trop vaste pour tenir dans une seule fiche. Il classe les textes, indique leur statut et renvoie vers les sujets voisins. Mais c'est un instantané informatif, pas l'inventaire en temps réel d'un opérateur. Une entrée peut…
Histoire d'Internet
DHCP transportait un identifiant d’abonné stable, sans en définir le sens : RFC 3993
Un client pouvait changer de ligne d’accès alors que le fournisseur souhaitait conserver la même décision de configuration. RFC 3993 a donné au relais DHCP un champ pour transporter un identifiant d’abonné stable, tout en laissant au fournisseur le soin de lui attribuer un sens.
IETF
L'extension transportait un message de clé. Elle ne prouvait pas son installation.
Pour OMA BCAST, MIKEY devait transporter des clés courtes et longues, des rapports et des règles de contrôle parental. Le RFC 5410 ajoute un conteneur General Extension. Ce conteneur atteste un type et des octets; il n'atteste ni la réception utile, ni l'installation d'un…
IETF
CMS a enveloppé la clé. L'identité du destinataire devait encore correspondre.
Le RFC 5409 ne dit pas seulement que l'IBE peut protéger un courrier. Il fixe les conventions CMS qui chiffrent une clé de contenu avec BF ou BB1, encodent l'identité du destinataire et choisissent l'algorithme par OID. Une enveloppe valide n'est pas encore une autorisation.
IETF
Une identité peut calculer une clé publique. Elle n'accorde pas un droit.
Le chiffrement fondé sur l'identité semble supprimer une friction familière: l'expéditeur calcule la clé publique à partir de l'identité du destinataire, puis un service de génération fournit la clé privée au moment utile. Le RFC 5408 décrit cette architecture avec précision. Il…
IETF
Un meilleur site ne suffit pas à déplacer une session : RFC 10054
Un flux peut rejoindre un nouveau site périphérique alors que l’état du service reste attaché à l’ancien. La RFC 10054 permet de raisonner sur la charge de calcul et les conditions réseau, mais exige que l’application indique explicitement si elle autorise CATS à réorienter une…
Dossier
Le résultat de 2,07× de la CNCF doit préciser les projets analysés
La CNCF rapporte que les projets dont les mainteneurs représentaient plusieurs organisations à leur entrée en Sandbox obtiennent plus souvent le statut Graduated. Son modèle actuel de revue exige séparément qu’au moins deux organisations soient représentées parmi les mainteneurs…
IETF
Le canal était lié ; l’opération restait une décision distincte.
An SIP gateway showed a verified security context and a clean message check. The dashboard promoted that evidence into “authorised and complete.” RFC 5407 draws a harder line: SIP Version 2 can bind a SIP message to lower-channel information, but the binding does not become local…
Histoire d'Internet
Le niveau 2 appartenait à la session, pas à l’appareil : RFC 7147
Un même système de stockage peut accueillir plusieurs sessions iSCSI. RFC 7147 rattache le niveau de protocole négocié à chacune d’elles: c’est l’accord entre un initiateur et une cible qui est décrit, pas une étiquette globale apposée sur la machine.
IETF
Le canal était lié ; l’opération restait une décision distincte.
An IPsec gateway showed a verified security context and a clean message check. The dashboard promoted that evidence into “authorised and complete.” RFC 5406 draws a harder line: IPsec Version 2 can bind a IPsec message to lower-channel information, but the binding does not become…
IETF
Le canal était lié ; l’opération restait une décision distincte.
An RTP gateway showed a verified security context and a clean message check. The dashboard promoted that evidence into “authorised and complete.” RFC 5404 draws a harder line: G.719 RTP Version 2 can bind a G.719 frame block to lower-channel information, but the binding does not…
IETF
Le canal était lié ; l’opération restait une décision distincte.
An RPC gateway showed a verified security context and a clean message check. The dashboard promoted that evidence into “authorised and complete.” RFC 5403 draws a harder line: RPCSEC_GSS Version 2 can bind a GSS context to lower-channel information, but the binding does not…
IETF
Une seule identité était authentifiée ; les deux extrémités devaient vérifier le canal : RFC 5387
Un service peut légitimement n’authentifier qu’un client ou qu’un serveur. Il ne peut pas en déduire qu’une seule extrémité suffit pour prouver le canal commun. RFC 5387 sépare ces deux décisions: l’authentification peut être asymétrique, tandis que la liaison au canal doit être…
Histoire d'Internet
L’adresse globale pouvait être prêtée, pas définir l’hôte : RFC 1335
En mai 1992, une proposition face aux tensions d’allocation d’IPv4 partait d’une distinction discrète: une machine pouvait garder son adresse dans son réseau tout en empruntant une adresse globalement unique seulement lorsqu’elle devait en sortir.
APRICOT
APNOG cale les mandats du conseil sur mars. La passation doit rester vérifiable.
APNOG a décidé que les mandats de son conseil suivraient un cycle de mars à mars, au lieu de coïncider exactement avec l’assemblée générale annuelle. L’organisation dit vouloir ménager une passation entre les équipes sortante et entrante et laisser aux nouveaux administrateurs le…
IETF
Deux partenaires disaient « compression prise en charge » — ils ne signaient pas les mêmes octets
Les deux passerelles savaient traiter ZLIB. L'une comprimait le document avant de le signer; l'autre attendait un ensemble signé puis le comprimait. Les deux constructions sont prévues par le RFC 5402. Elles ne placent pourtant ni la signature ni le MIC sur la même…
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