Sujet
Preuves fondées sur les ressources réseau
Au sein de la facette Sujet, la veille thématique Preuves fondées sur les ressources réseau rassemble des articles qui partagent un même sujet, un même signal ou un même thème de suivi. Cette page offre aux lecteurs un parcours plus riche à travers les reportages associés, les preuves issues de sources publiques, les acteurs du marché et les implications pour l’infrastructure, avec suffisamment de contexte pour comprendre pourquoi le sujet compte pour les mouvements d’entreprises, les décisions de gouvernance, l’exposition régionale et le risque opérationnel. Les lecteurs peuvent comparer les signaux récurrents, les organisations concernées, les preuves publiques, le contexte du marché, la continuité de service, les achats, la concurrence, la conformité et les questions de planification stratégique liées au sujet, au lieu de se contenter d’une liste succincte d’articles correspondants. Elle explique ce que couvre le sujet, quels acteurs ou politiques de l’infrastructure sont impliqués, quelles preuves étayent la couverture et pourquoi le sujet peut être important pour les opérateurs, les clients, les investisseurs et les lecteurs de politiques publiques.

Dossier
Le tunnel a gardé le paquet et perdu la congestion : RFC 9599
Une migration promet moins de pertes: les nouveaux équipements marquent la congestion au lieu de jeter les paquets. Pourtant, un ancien décapsulateur retire l’en-tête marqué sans transmettre l’indication à IP. Le taux de livraison s’améliore tandis que la boucle de contrôle…

Histoire d'Internet
PREPARED a survécu à la panne. La preuve devait survivre aussi : RFC 2372
En juillet 1998, le RFC 2372 a placé une règle de garde derrière deux mots du protocole TIP: avant de dire PREPARED, conserver la preuve qui permettra de retrouver cette promesse; avant de dire COMMIT depuis cet état, conserver la décision qu’il faudra peut-être répéter. La…

Histoire d'Internet
La réservation diminuait. Le grand circuit restait : RFC 2380
La RFC 2380 permettait de considérer comme réussie une réduction de réservation RSVP alors même qu'ATM n'avait pas pu construire le circuit plus petit et conservait l'ancien, surdimensionné. La règle de 1998 séparait ainsi l'intention du protocole, la réponse, l'allocation…

Récits
APNIC représente 3,0 % d’un échantillon de succès geofeed, pas un taux d’adoption
Dans une diapositive d’APNIC 62, la barre APNIC s’arrête à 3,0 %. La note sous le graphique est plus importante que la décimale: l’échantillon part de 200 000 lignes de géolocalisation repérables dans le Whois, les ramène à des netnames distincts et écarte deux RIR. Le chiffre…

Histoire d'Internet
David Tennenhouse et le paquet qui demandait au routeur d’exécuter du code
Un paquet ordinaire présente une destination. La « capsule » imaginée par David Tennenhouse et David Wetherall ajoutait une demande plus délicate: exécuter ce programme ici, dans la machine d’un autre, avant de poursuivre. La promesse était une innovation libérée des cycles de…

Histoire d'Internet
Le circuit garanti commençait par un message sans garantie
En août 1998, la RFC 2379 a assumé une dissymétrie que l'on aurait pu être tenté de masquer: le message RSVP demandant un service réservé devait d'abord emprunter le chemin ordinaire en mode best effort. Ce choix obligeait à distinguer la demande, l'état qu'elle entretenait, le…

Histoire d'Internet
L’enveloppe avait atteint la zone. L’application devait encore la croire : RFC 2370
RFC 2370 a prêté le mécanisme de diffusion d’OSPF à des informations dont OSPF ne définissait pas lui-même le sens. Une LSA opaque pouvait respecter sa portée, être acquittée et entrer dans la base d’état des liens sans devenir pour autant une donnée comprise, une route calculée…

IETF
Un champ QUIC exporté ne raconte pas toute la connexion
La normalisation peut rendre une observation échangeable. Elle ne donne pas à un point de mesure la mémoire de tous les chemins, de tous les identifiants et de toutes les décisions de l’application.

Récits
La maintenance d’APNIC met l’horloge des délégations AS0 à l’épreuve
Une adresse qui répond encore n’est pas nécessairement une assertion qui vient d’être corrigée. APNIC prévoit une intervention réseau le 29 septembre et n’attend aucune interruption de quatre services, dont celui des ROA AS0. La promesse de continuité mérite d’être lue à sa juste…

Dossier
La revendication était visible avant d’être fiable : RFC 9597
RFC 9597 rend certaines revendications CWT accessibles dans l’en-tête COSE avant le déchiffrement ou sans charge utile jointe. Cette avance aide au routage et à la découverte de clés, mais elle ouvre un intervalle où le système agit sur une information qu’il n’a pas encore…

Histoire d'Internet
Le lien avait rédigé le message. L’utilisateur devait encore l’envoyer : RFC 2368
En 1998, RFC 2368 a permis à un lien `mailto:` de préparer le destinataire, l’objet, certains en-têtes et un court corps de message. Il n’a pourtant pas transformé le clic en envoi: le client local filtrait la proposition, puis l’utilisateur pouvait la modifier, l’approuver ou…

Histoire d'Internet
L’identifiant ressemblait à une adresse. Ce n’était pas une boîte aux lettres : RFC 2377
La RFC 2377 voulait rendre le nommage LDAP praticable en réemployant les noms déjà disponibles sur Internet. Son avertissement le plus actuel porte sur une chaîne familière: `uid=mailbox-shaped-identifier` pouvait nommer une entrée sans désigner une boîte aux lettres…

IETF
La fenêtre a grandi sans réserver le prochain passage
Une fenêtre de congestion décrit ce que l’émetteur peut tenter à partir d’observations passées. Ce n’est ni une réservation de bande passante ni une promesse faite par le récepteur.

Dossier
L’en-tête nommait l’objet. Il n’autorisait pas l’action : RFC 9596
Un type protégé peut empêcher qu’un objet COSE soit pris pour un autre. Il ne garantit ni la vérité de la charge utile, ni la compétence du signataire, ni le droit d’exécuter l’opération demandée.

Histoire d'Internet
Craig Partridge et le gigabit qui n’exigeait pas un nouvel Internet
Un chiffre rond peut finir par se comporter comme un verdict. À la fin des années 1980, un gigabit par seconde semblait assez imposant pour condamner les architectures existantes. Craig Partridge a refusé cette mise en scène. Il a réparti le débit entre paquets, instructions…

Histoire d'Internet
Quand l’enveloppe a primé sur le document : RFC 2376
La RFC 2376 a donné à XML deux lieux pour annoncer son encodage: l’enveloppe de transport et le document lui-même. Dans un cas courant, l’absence d’une valeur à l’extérieur neutralisait une déclaration pourtant explicite à l’intérieur. Cette histoire révèle où résidait réellement…

Histoire d'Internet
Le gestionnaire a supprimé la ligne. Le circuit pouvait rester : RFC 2366
Avec RFC 2366, l'exploitation du multicast IP sur ATM entrait dans les tables SNMP. Mais le texte conservait une dissociation décisive: la ligne d'un client, d'un serveur MARS ou d'un MCS pouvait être supprimée alors que les lignes de circuits virtuels associées existaient…

Histoire d'Internet
Le numéro de groupe restait le même. Pas les membres : RFC 2375
En 1998, la RFC 2375 a transporté des noms de services multicast dans plusieurs portées IPv6. Elle a surtout évité un raccourci dangereux: conserver le même identifiant ne créait pas un groupe unique. À chaque portée correspondait une adresse distincte, qu’un nœud devait…

IETF
BTPU peut répéter chaque segment sans savoir si le bundle est arrivé
Sur une liaison à sens unique, la redondance augmente une probabilité. Elle ne crée ni l’observation du récepteur ni le chemin qui permettrait de la rapporter.

Dossier
Le jeton autorisait l’entrée. Le KDC devait encore admettre le membre : RFC 9594
Dans un système distribué, un feu vert peut appartenir au mauvais étage. RFC 9594 montre pourquoi l’autorisation émise par un serveur ACE n’est ni une preuve d’adhésion au groupe, ni la preuve qu’un état cryptographique exploitable a été installé.
