Horizon temporel
Pluriannuel
Dans la facette Horizon temporel, les analyses à horizon temporel Pluriannuel sont organisées selon la période pendant laquelle un signal devrait rester pertinent. La page aide à distinguer les changements opérationnels immédiats des évolutions à plus long cycle — gouvernance, investissements, normes et infrastructures — qui peuvent s’étendre sur plusieurs trimestres ou années. Elle relie les hypothèses de calendrier aux preuves publiques, aux acteurs concernés, au contexte de marché, à l’exposition des clients, à la pression réglementaire et à la planification des infrastructures, afin que le lecteur puisse déterminer si un développement est urgent, stratégique ou encore en attente d’éléments de confirmation. Elle explique aussi comment l’horizon temporel modifie le sens d’un signal, quelles organisations peuvent être exposées et quelles décisions d’infrastructure appellent une action à court terme ou un suivi à long terme.
Tendances mondiales des FAI régionaux
Un deuxième service de peering distant n’est pas un deuxième chemin
Le peering distant rapproche logiquement un réseau d’un point d’échange. Il ne démontre pas que deux services empruntent deux chaînes physiques et opérationnelles indépendantes.
Histoire d'Internet
La session est morte. La mémoire des routes est devenue une exception explicite : RFC 1267
Un UPDATE vide peut constituer une preuve. Dans le redémarrage gracieux de BGP, ce message ne dit pas qu’une route fonctionne; il ferme l’incertitude sur la fin de la table initiale d’une famille d’adresses. Cette ponctuation tardive éclaire le principe posé dès RFC 1267: une…
Dossier
La clé de route n’a pas changé. Son sens, si : RFC 9871
Dans un domaine, le faible délai porte la couleur C2; dans l’autre, C1. RFC 9871 ne force pas les deux opérateurs à adopter le même dictionnaire. Il maintient la clé `(E2,C2)` et confie la traduction locale à une communauté étendue distincte, LCM-EC.
Histoire d'Internet
Le RFC disait VAR pour zéro ; le code en service y lisait VALUE : RFC 1408
Une erreur de protocole n’est pas toujours un paquet rejeté. Elle peut produire deux messages parfaitement plausibles, selon la table que possède le lecteur. Avec l’option Telnet ENVIRON, l’octet zéro désignait le début d’un nom de variable dans RFC 1408, tandis que…
Dossier
Le préfixe était juste, mais le paquet a pris le mauvais accès : RFC 9872
Deux fournisseurs peuvent donner à un même terminal deux chemins IPv6 valides, sans rendre leurs traducteurs NAT64 interchangeables. RFC 9872 replace ainsi le PREF64 dans son véritable contexte: une valeur n'est exploitable que si le terminal sait quel routeur l'a annoncée.
Histoire d'Internet
Le rapport comptait 56 routeurs. Il refusa de faire du cas extrême la norme : RFC 1266
Sept routeurs disparaissent lorsqu’on passe d’une phrase à la suivante. La RFC 1266 en recense d’abord 56 dans sept systèmes autonomes, puis précise que 49, répartis dans six systèmes, appartiennent à l’Internet en exploitation. Les sept autres sont ceux du réseau d’essai T3…
Histoire d'Internet
Le graphe pouvait voyager, à condition d’emporter son histoire de mesure : RFC 1404
Deux centres d’exploitation pouvaient afficher le même mot, « pic », sans avoir mesuré le même phénomène. RFC 1404 répondit moins par un dessin commun que par une discipline de mémoire: conserver l’intervalle réellement observé, la période d’agrégation, la ressource suivie et la…
Dossier
RFC 9873 : une seule règle de divulgation pour deux adresses
Le détail le plus politique de RFC 9873 n'est pas la prise en charge d'une adresse internationalisée. C'est l'interdiction implicite d'en faire une voie latérale moins protégée: la règle de divulgation du contact doit couvrir l'adresse historique et l'adresse supplémentaire…
Histoire d'Internet
La liste de contrôle fut retirée. La question de la preuve changea de lieu : RFC 1264
En 1991, un protocole de routage ne devait pas avancer parce que son texte paraissait achevé. La RFC 1264 demandait des pièces distinctes: code indépendant, essais de chaque fonction, démonstration de la sécurité, expérience d’exploitation et analyse du point de rupture. En 2006…
Histoire d'Internet
Le tag pouvait avouer qu’il avait oublié le chemin : RFC 1403
Un résumé de trente-deux bits peut signaler qu’une histoire existe; il ne peut pas toujours la raconter. RFC 1403 transforma cette limite en règle d’autorité. Lorsqu’OSPF ne conservait plus le chemin dont BGP avait besoin, un routeur de bord ne devait ni le deviner ni le…
Dossier
Un domaine supprimé, le risque transmis aux autres : RFC 9874
Le droit d’un bureau d’enregistrement à supprimer son propre domaine ne contient pas forcément les conséquences. RFC 9874 examine le cas où un hôte subordonné appartient à un client mais dessert encore des domaines parrainés par d’autres.
NPNOG
Deux heures en ligne : ce que l’expérience pandémique de npNOG a changé pour l’accès
Le 9 décembre 2020, npNOG a maintenu un programme technique public en le faisant passer en ligne. Les pages officielles étayent un résultat plus précis que ne le suggère souvent le vocabulaire de l’inclusion numérique: personne n’avait à se déplacer vers un lieu physique désigné…
Histoire d'Internet
Le relais a retouché le message : il était devenu passerelle — RFC 1344
Modifier un seul pixel n’est pas transporter. En juin 1992, RFC 1344 plaça cette différence au centre du courrier multimédia: un intermédiaire pouvait réduire un fichier, déplacer une référence ou protéger des caractères fragiles, mais il ne pouvait plus se décrire comme un tuyau…
Histoire d'Internet
Le banc d’essai pouvait montrer un avenir. Il ne pouvait pas décider du réseau public : RFC 1259
Un quartier pilote peut révéler une rue mal dessinée, un tarif impraticable ou un service que personne n’avait prévu. Il ne représente pas pour autant toute la ville. En 1991, la RFC 1259 plaça le NREN dans cette position: un terrain d’apprentissage pour la technique et les…
IETF
Eric Rescorla et le ClientHello chiffré qui ne pouvait pas nommer le serveur
Chiffrer le premier message TLS retire un indice très visible. Cela ne transforme pas la poignée de main restante en registre d’identité. La RFC 9849, rédigée collectivement par Eric Rescorla, Kazuho Oku, Nick Sullivan et Christopher A. Wood, dessine une enveloppe de…
Histoire d'Internet
Le réseau ne devait pas battre la mesure. Le récepteur la reconstruisait : RFC 1257
Une image vidéo peut parvenir trop tôt, la suivante presque à la limite, puis les deux s’afficher à cadence régulière. En 1991, la RFC 1257 fit de cet écart une question d’architecture: le réseau devait fournir une capacité et une borne de délai, tandis que le récepteur assumait…
Histoire d'Internet
Le compteur survivait. Le paquet, lui, recevait une nouvelle vie : RFC 1326
Un compteur de sauts peut encore exister sans plus limiter le voyage. Il suffit de l’enfermer dans une enveloppe que les routeurs suivants ne lisent pas, puis d’ajouter à cette enveloppe un compteur neuf. RFC 1326 a montré en 1992 comment deux mécanismes d’encapsulation, utiles…
Histoire d'Internet
L’analyse ne pouvait pas remplacer le réseau d’essai : RFC 1245 et RFC 1246
En juillet 1991, le dossier d’OSPF Version 2 fut publié sous trois formes distinctes: une spécification, une analyse et un rapport d’expérience. Cette séparation empêchait une estimation de se faire passer pour une mesure, ou une séance d’interopérabilité pour un déploiement…
Histoire d'Internet
Le centre gardait la question. Il ne commandait pas le réseau : RFC 1302
Un dossier d’assistance peut rester sous la responsabilité d’un centre alors que la réponse, l’expertise et l’action circulent entre plusieurs institutions. En 1992, le RFC 1302 a organisé cette continuité sans inventer une autorité centrale. Le NIC devait accompagner la demande…
IETF
Deborah Brungard et le profil de transport qui ne choisissait pas un réseau
Une exigence de normalisation peut rendre une capacité disponible sans choisir le réseau qui l'emploiera. La RFC 5654, éditée notamment par Deborah Brungard, décrit les exigences d'un profil de transport MPLS. Elle trace surtout une limite: les exigences portent sur le…