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 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 564 articles

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…

Histoire d'Internet
Une baisse ne pouvait pas attendre; une hausse, si : RFC 3988
Le routeur d’entrée continuait d’annoncer une capacité confortable. Plus loin, un nouveau tunnel avait pourtant retiré quatre octets à chaque paquet. Entre les deux vivait un chiffre encore valide hier, mais déjà dangereux aujourd’hui.

IETF
La page était conforme, pas encore la preuve : RFC 5385
Une mise en page peut réussir son contrôle visuel et échouer à établir l’identité du document. RFC 5385 le montre avec une précision presque matérielle: le modèle Word rapprochait l’écran du texte RFC, mais un fichier d’impression et un post-traitement restaient nécessaires. La…

IETF
Un NACK entendu peut faire taire mille récepteurs sans en réparer un seul
Un bloc disparaît pour une partie du groupe. Un premier récepteur réclame la réparation; les autres entendent sa demande et renoncent à envoyer la leur. Vu du serveur, le calme revient presque aussitôt. Ce calme prouve que la suppression fonctionne. Il ne prouve ni que la…

Histoire d'Internet
L’adresse était lisible; sa forme originale devait pourtant survivre : RFC 3987
Le copier-coller promettait de transporter une adresse, mais il pouvait remettre au logiciel des caractères, des octets ou une version déjà transformée. Sans trace de départ, l’adresse familière devenait une preuve impossible à rejouer.

Histoire d'Internet
L’horaire avait un indicatif. La RFC ne prouvait pas la diffusion : KRFC 1313
En avril 1992, une RFC met en scène une radio de la baie de San Francisco pour le public d’Internet: grille des programmes, commanditaires, invités et moyens d’écoute. La trace historique la plus solide est peut-être le texte lui-même, pas l’émission qu’il raconte.

IETF
L’adresse la plus basse a tranché, sans recevoir de mandat : RFC 5384
Dans un arbre multicast, deux voisins aval peuvent demander des traitements incompatibles. RFC 5384 donne au routeur amont un moyen de sortir du conflit: à défaut de règle propre au type d’attribut, il retient la valeur fournie par l’adjacence dont l’adresse IP est numériquement…

Histoire d'Internet
Le réseau transportait l’essentiel du circuit, pas le circuit lui-même : RFC 3985
L’équipement client voit un circuit non partagé; sous cette apparence, plusieurs pseudowires traversent pourtant un réseau de paquets commun dont les pertes et les délais restent bien réels.

IETF
Un ASN privé pouvait déjà avoir un métier : il fallait un espace distinct pour les exemples
Le résumé de veille Un ASN privé pouvait déjà avoir un métier: il fallait un espace distinct pour les exemples explique le développement, les preuves publiques disponibles, les organisations concernées, le contexte régional, l’exposition au marché et les conséquences possibles…

Histoire d'Internet
Le pont de gestion ne promettait pas la compatibilité : RFC 1285
En janvier 1992, la RFC 1285 a cherché à rendre la gestion FDDI accessible par SNMP sans changer le sens de ses objets. En septembre 1993, la RFC 1512 avertissait que la révision du modèle ANSI avait déplacé les objets dans une autre branche de l’arbre MIB et qu’il ne fallait pas…

ICANN
Une lettre, pas une étiquette : la question des administrateurs « non affiliés » d’ICANN
Le comité de gouvernance du conseil d’ICANN s’oriente vers un texte dans la lettre annuelle sur les compétences adressée au comité de nomination. L’instrument évolue, mais les documents examinés ne montrent pas encore de décision finale du conseil.

Histoire d'Internet
Les paquets d’image sont arrivés. Les règles du décodeur suivaient une autre chronologie : RFC 3984
Lorsqu’un encodeur change de résolution en direct, le risque décisif n’est pas seulement de perdre une image: l’ancien sens d’un identifiant peut encore circuler alors que le décodeur vient d’en installer un nouveau.

IETF
Le port était le bon. Le serveur ne l’était pas : RFC 5383
Le numéro 25 figurait sur la porte, le dialogue ressemblait à SMTP et la connexion avait réussi. Pourtant, dans le cas consigné par la RFC 5383, l’hôtel pouvait avoir remplacé le serveur choisi par l’utilisateur. Un guichet familier ne prouve ni l’identité de l’établissement ni…

IETF
Le même utilisateur a reçu deux ressources de principal
Lundi, le client a mémorisé une URL de principal. Mardi, le même compte authentifié en a reçu une autre. L’équipe a conclu à un doublon d’identité; le serveur avait simplement choisi une autre ressource autorisée. RFC 5397 permet cette pluralité tout en demandant de la cohérence.…

Histoire d'Internet
La liste des normes avait une date d’expiration : RFC 1280
En mars 1992, l’Internet Activities Board a publié un état des protocoles accompagné d’un avertissement inhabituel pour un texte normatif: ne plus utiliser cette édition après le 31 juillet. La RFC 1280 pouvait coordonner les décisions, mais elle était déjà appelée à être…

IETF
Le port avait deux propriétaires cachés : la limite posée par la RFC 5382
Un port public ressemble à une adresse précise. Dans une table de traduction trop ambitieuse, il peut pourtant devenir un titre de propriété partagé, dont les copropriétaires ne sont distingués que par la destination qu’ils appellent. Tant que leurs chemins divergent, l’illusion…

Histoire d'Internet
Un champ vide n’avait pas un seul sens : RFC 3982 a intégré l’absence au protocole
Une enquêtrice authentifiée peut recevoir une coordonnée tout en restant tenue de ne pas la transmettre. RFC 3982 avait compris cette dissociation essentielle: le droit de voir une donnée et le droit de la faire circuler ne sont pas la même autorisation.

Histoire d'Internet
L’adresse OSI devait transporter plus qu’une route : RFC 1277
En 1991, des applications OSI fonctionnaient déjà à l’essai sur des réseaux TCP/IP et X.25 qui ne fournissaient pas le service réseau OSI. La RFC 1277 a placé dans une adresse de l’annuaire les indications de couche inférieure que celui-ci savait déjà renvoyer. Un client pouvait…
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