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.
Histoire d'Internet
La connexion qui survécut au changement de système de fichiers : FTP SMNT sépara identité et espace de noms
Dans le FTP de 1985, changer de terrain ne signifiait pas forcément changer de voyageur. Une session déjà authentifiée pouvait demander le montage d’une autre structure de fichiers tout en conservant l’identité, la comptabilité et les paramètres de transfert. Ce petit…
Histoire d'Internet
Le message qui voulait arriver avant la boîte aux lettres : pourquoi SMTP a abandonné la livraison au terminal
Dans le SMTP des débuts, expédier un message pouvait signifier interrompre un utilisateur devant son terminal. Trois commandes permettaient de viser l’écran, de se rabattre sur la boîte aux lettres ou de faire les deux. Cette branche oubliée du protocole liait le transport à une…
Histoire d'Internet
Le feu vert qui ne vous appartenait pas : comment NNTP séparait la règle du groupe du droit de publier
Dans la liste d'un serveur de news, un groupe se termine par `y`: la publication y est normalement admise. Pourtant, le même serveur peut répondre `440 Posting not permitted` à votre commande `POST`. NNTP ne se contredit pas. Il distingue une propriété générale du groupe d'une…
Histoire d'Internet
Le mot de passe accepté ne suffisait pas à ouvrir la session
Dans le dialogue FTP, un mot de passe pouvait être exact sans produire l’état « connecté ». Le serveur répondait `332` et attendait encore `ACCT`. Ce troisième renseignement ne répétait ni le nom d’utilisateur ni son secret: il désignait le contexte local dans lequel la session…
IETF
Brian Carpenter et la frontière qui devait prouver ses membres
Deux réseaux privés peuvent fonctionner sans faute pendant des années, puis cesser de se comprendre le jour où une acquisition les réunit. Le problème ne vient pas forcément des paquets: il vient des sens locaux qu'on leur avait attribués. Avec la RFC 8799, Brian Carpenter et…
Histoire d'Internet
Deux nombres, aucun compromis
Sur une capture, le SYN annonce 1460 et le SYN-ACK répond 1200. L’écart ressemble à un désaccord qu’il faudrait résoudre. TCP n’en résout aucun: chaque nombre appartient à un destinataire différent et limite les données envoyées dans le sens opposé. Le vrai calcul commence après…
Histoire d'Internet
L’article qui devait garder son nom : comment NNTP borna la perte de la réponse finale
Le serveur possède déjà le texte entier. La ligne formée d’un point est passée, puis la liaison tombe avant que le client ne voie le verdict. Chercher l’article ne tranche rien: il peut attendre une modération. NNTP n’a pas effacé cette incertitude; il lui a donné une frontière…
IETF
Le serveur a retardé le coût de la confiance : les défenses TCP contre le SYN flood
Un serveur TCP engageait de la mémoire dès qu’un inconnu frappait à sa porte. Le RFC 4987 montre comment repousser cette dépense jusqu’à ce que le client présumé prouve au moins qu’il a reçu la réponse.
Tendances mondiales des télécoms nationaux
La tranche par défaut peut faire paraître un SLA 5G respecté
Une application peut rester accessible alors que le chemin réseau promis par son contrat 5G a disparu. Le voyant de disponibilité reste vert; il faut encore prouver que le terminal, la session et les paquets ont bien utilisé la tranche convenue.
Histoire d'Internet
La commande que l’authentification ne pouvait pas reprendre : pourquoi NNTP exigeait une nouvelle demande
Le code `281` vient de confirmer l’identité du client. Pourtant, aucun groupe ne s’ouvre et aucun article n’arrive. Pour obtenir la ressource qui avait répondu `480`, le client doit reformuler sa commande. Ce silence après l’authentification n’est pas un oubli: il empêche une…
Histoire d'Internet
Le paquet arrivé trop tard pour être oublié
Le récepteur avait déjà signalé une absence quand le paquet finit par arriver. Puis vint la confirmation que son ancien compte rendu avait bien été reçu. Pouvait-il alors effacer ses notes ? Dans DCCP, ce petit décalage entre deux nouvelles révèle un problème plus profond…
Tendances services cloud Europe et Moyen-Orient
Une partition souveraine n’est pas un chemin de bascule
La séparation de l’AWS European Sovereign Cloud peut rendre une cible admissible. Elle ne rend pas, à elle seule, une application récupérable dans le délai promis.
Histoire d'Internet
L’acte de naissance qui survécut au groupe : ACTIVE.TIMES sépara la provenance de la disponibilité
Un groupe figure dans le catalogue utilisable, mais son origine a disparu de l’archive. Un autre n’est plus sélectionnable, alors que sa trace de création demeure. Le même serveur NNTP pouvait répondre ainsi sans se contredire: l’une de ses listes décrivait le présent, l’autre la…
Histoire d'Internet
L’écriture revenue avant d’être à l’abri
Le serveur avait répondu que l’écriture avait réussi. Pourtant le client ne pouvait pas encore libérer son tampon: les octets pouvaient n’exister que dans une mémoire que le prochain redémarrage effacerait. NFS version 3 a rendu ce décalage explicite, puis lui a donné une preuve…
IETF
Le premier numéro de séquence ne pouvait pas être une simple horloge : la défense ISN de TCP
Toute connexion TCP commence par publier un nombre. Quand ce nombre suivait trop clairement une horloge globale, un attaquant incapable de voir la connexion pouvait néanmoins prévoir assez de son état pour usurper un pair.
Histoire d'Internet
La couche qui devait arriver en dernier : quand la compression NNTP imposa l’ordre de sécurité
Sur une même connexion, un lecteur veut chiffrer le transport, prouver son compte et réduire le volume transmis. Il suffit pourtant de commencer par la dernière ambition pour perdre les deux premières: après le succès de `COMPRESS`, ni `STARTTLS` ni `AUTHINFO` ne restent…
Tendances télécoms nationaux Europe et Moyen-Orient
Une facilité accordéon de 800 M£ n’est pas le budget d’une consolidation de la fibre
Le refinancement de CityFibre lui donne une capacité d’acquisition considérable, mais le montant affiché d’une facilité ne dit pas si chaque réseau repris a franchi les étapes opérationnelles et financières nécessaires au service de sa dette.
IETF
Le reset devait faire ses preuves : la défense Challenge ACK de TCP
Un reset forgé devait autrefois seulement tomber quelque part dans une fenêtre de réception mobile. Le RFC 5961 oblige les signaux TCP destructeurs à démontrer qu’ils correspondent à l’état actuel du pair avant qu’un numéro deviné puisse effacer une connexion durable.
Histoire d'Internet
La réservation qui pouvait ne rien réserver
Le client annonçait la taille du fichier avant de l’envoyer. Le serveur répondait positivement: `202`. Pourtant cette réponse pouvait signifier qu’aucune réservation n’avait eu lieu, parce que réserver de l’espace à l’avance était « superflu » sur cette machine. FTP avait ainsi…
IETF
En maintenance BGP, « graceful » doit désigner deux promesses distinctes
Le même mot peut masquer deux ordres opposés. Avant de retirer un lien, il faut détourner le trafic. Pendant le redémarrage du processus BGP, il peut au contraire être nécessaire de conserver les entrées de transfert. Une procédure qui se contente d’annoncer une opération «…