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 716 articles
Histoire d'Internet
L’explication humaine et le rapport machine partageaient une enveloppe : RFC 3462
Un avis d’échec devait parler à deux lecteurs qui n’attendaient pas la même chose. L’expéditeur voulait comprendre; le logiciel voulait des champs stables. RFC 3462 les a réunis dans un même contenant sans confondre explication, constat structuré et message retourné.
Histoire d'Internet
La partie facultative a disparu. La livraison pouvait réussir : RFC 3459
RFC 3459 a traité une situation que le courrier ordinaire préférait éviter: une passerelle pouvait ne livrer qu’une partie d’un message multipart, faute de capacité du système destinataire. Il revenait alors à l’expéditeur de déclarer quelle perte invalidait la livraison entière.
IETF
Les bits ont rendu la perte visible, pas la conclusion : RFC 9506
La RFC 9506 ouvre une fenêtre minuscule dans les transports chiffrés: quelques bits exposent délai, perte ou congestion à un observateur sur le chemin. Cette fenêtre est utile, mais elle ne remplace ni le contrat de mesure, ni l’attribution de la cause, ni la preuve du service…
IETF
L’archive était accessible. La mémoire institutionnelle ne l’était pas encore
Le RFC 5005 distingue un flux complet, une pagination instable et une archive reconstructible. Pour une direction, cette distinction impose une règle simple: le chemin vers les documents anciens ne prouve ni leur collecte intégrale, ni leur conservation, ni ce que le lecteur a…
Histoire d'Internet
L’en-tête disait voix. Le message devait encore être lu : RFC 3458
RFC 3458 a offert aux messageries mêlant texte, fax et voix un indice compact sur l’usage attendu d’un message. Sa règle décisive était cependant une limite: l’indice ne pouvait jamais prendre la place du contenu effectivement reçu.
Histoire d'Internet
Le tunnel était protégé. L’adresse attribuée n’était pas un titre d’accès : RFC 3456
RFC 3456 réutilisait DHCPv4 pour donner à une machine distante une présence virtuelle dans le réseau de l’entreprise. Son avertissement décisif reste actuel: une adresse remise par un échange protégé configure l’hôte, mais ne lui confère pas à elle seule un droit d’accès.
Dossier
DFINFRA : quand la source faisant autorité devient illisible, que prouve encore une affirmation d'enregistrement ?
Le résumé de veille DFINFRA: quand la source faisant autorité devient illisible, que prouve encore une affirmation d'enregistrement ? explique le développement, les preuves publiques disponibles, les organisations concernées, le contexte régional, l’exposition au marché et les…
IETF
Le MOVE a réussi. L’ordre de lecture pouvait pourtant changer : RFC 3648
Un responsable éditorial déplace un document dans un recueil ordonné sans modifier son contenu. Tous les fichiers sont là, mais le parcours pédagogique n’est plus le même. Pour un MOVE au sein du même parent sans `Position`, RFC 3648 autorise la conservation de la place comme…
IETF
La requête portait sa preuve. Elle ne pouvait toujours pas délivrer le certificat : RFC 9733
Avec RFC 9733, une demande de certificat conserve la preuve cryptographique de son origine malgré l’attente et les relais. Cette continuité rend l’enrôlement industriel plus robuste; elle ne remplace ni le consentement du registrar, ni la décision de l’AR, ni l’émission par l’AC…
Histoire d'Internet
Les chaînes correspondaient. L’identité restait à prouver : RFC 3454
Stringprep a donné aux protocoles Internet une méthode reproductible pour comparer des chaînes internationalisées. Ses opérations pouvaient effacer, transformer, normaliser ou refuser des points de code jusqu’à produire deux sorties identiques. Cette égalité était utile, mais…
IETF
La pratique était déclarée. Son exécution restait à prouver : RFC 3647
Deux autorités de certification présentent des documents construits selon les mêmes rubriques. L’équipe d’interopérabilité peut enfin comparer leurs engagements sans réinventer le vocabulaire. Mais l’alignement des titres ne dit pas si les cérémonies, les contrôles et les délais…
Histoire d'Internet
Assez de symboles reconstruisaient l’objet. L’émetteur ignorait encore qui avait terminé : RFC 3450
ALC a rendu la multidiffusion fiable extensible en supprimant la conversation de réparation avec chaque destinataire. Chaque récepteur pouvait reconstruire l’objet à partir de son propre ensemble de symboles. Cette réussite n’était pourtant pas un registre de livraison…
Histoire d'Internet
Le récepteur annonçait un débit. L’émetteur devait encore imposer ses propres limites : RFC 3448
Dans TFRC, le récepteur détenait une vue privilégiée des paquets arrivés, mais pas un droit sur la capacité future. RFC 3448 transforma ses observations en données d’entrée et conserva chez l’émetteur la responsabilité du calcul, du rythme et du repli.
Récits
La chaîne d'identité d'almazcloud.network : chaque maillon vérifiable, aucune preuve qui les relie
Le site almazcloud.network, opéré sous la marque DIAMOND (« ALMAZ » en russe), vend cinq produits à prix affichés et promet une « connexion physique de peering directe » vers Yandex, Sberbank et Rostelecom. Indépendamment, le registre et les collecteurs de routage décrivent une…
IETF
Le signal OAM est revenu, pas la preuve du service : RFC 9772
Un aller-retour réussi dans un tunnel Geneve peut innocenter un segment précis sans répondre à la plainte d’un locataire. RFC 9772 vaut surtout par cette discipline: rattacher chaque mesure au VNI, au traitement et au point de terminaison réellement parcourus, puis refuser que…
Histoire d'Internet
Une adresse partagée exigeait des identités uniques en coulisses : RFC 3446
Anycast permettait à plusieurs points de rendez-vous multicast de présenter une même entrée proche. Il ne les transformait pas en une seule machine. RFC 3446 tenait parce que l’adresse offerte aux sources était commune, tandis que les identités utilisées entre répliques restaient…
IETF
Le réseau a proposé un DNS. La machine gardait encore le choix : RFC 3646
Dans une gouvernance saine de la configuration, une annonce n’est jamais confondue avec un ordre exécuté. RFC 3646 fournit au client DHCPv6 une liste préférentielle de résolveurs et une liste de recherche, mais laisse à la politique locale, au résolveur et à l’application les…
Histoire d'Internet
Un seul enregistrement DNS portait des clés qui ne partageaient pas la même confiance : RFC 3445
Le premier enregistrement `KEY` promettait un annuaire commun à plusieurs cryptographies. L’expérience montra une facture cachée: le DNS ne pouvait demander qu’un type entier, et la signature couvrait tout le RRset. Des clés administrées, validées et compromises de façons…
IETF
Le message s’est déchiffré. L’expéditeur restait à prouver : RFC 9750
Un audit d’acquisition peut valider une promesse de chiffrement tout en laissant intacte la question décisive: quelle preuve désigne réellement un client précis ? L’architecture MLS de la RFC 9750 oblige à séparer le secret partagé du groupe, la signature individuelle…
IETF
La signature était valide. L’autorisation restait à établir
Dans une console d’exploitation, un contrôle cryptographique vert ressemble facilement à une décision complète. Pourtant, RFC 3645 ne confond pas les rôles: GSS-TSIG peut établir un contexte de sécurité et authentifier un message DNS, mais le texte exclut expressément…
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