Aller au contenu principal

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.

SAVNET : le dernier appel porte sur les limites du diagnostic

IETF

SAVNET : le dernier appel porte sur les limites du diagnostic

Avant de filtrer une adresse source, il faut savoir ce que la route observée permet réellement de déduire. L’IESG demande jusqu’au 1er octobre des observations sur un texte qui définit ce problème entre réseaux. Il ne soumet pas à approbation un filtre prêt à installer.

21 sept. 2026
Le même paquet DHCP ne racontait pas la même identité quatre fois

Histoire d'Internet

Le même paquet DHCP ne racontait pas la même identité quatre fois

Dans RFC 2132, une classe de fournisseur, une clé de bail et une liste de paramètres demandés peuvent voyager ensemble. Leur voisinage dans la trame n'en fait ni un certificat d'origine ni le portrait fidèle d'une machine en service.

21 sept. 2026
Le serveur comprenait la commande, pas nécessairement son lecteur : RFC 2130

Histoire d'Internet

Le serveur comprenait la commande, pas nécessairement son lecteur : RFC 2130

Un protocole peut recevoir exactement les octets attendus et produire malgré tout un texte mal identifié ou inutilisable pour la personne à qui il s'adresse. Le rapport de l'atelier IAB sur les jeux de caractères, publié sous le numéro RFC 2130, a séparé ces réussites au lieu de…

21 sept. 2026
RFC 2129 : le circuit était reconnu, pas encore le flux

Histoire d'Internet

RFC 2129 : le circuit était reconnu, pas encore le flux

Le raccourci pouvait être prêt sur le papier et inutilisable pour le paquet qui l’avait motivé. Dans FANP, la proposition de Toshiba publiée en 1997, un voisin accusait d’abord réception d’un circuit virtuel; il fallait une seconde réponse pour y faire passer un flux IP précis.…

21 sept. 2026
RFC 2127 : débrancher une interface ne prouvait pas la fin de l’appel

Histoire d'Internet

RFC 2127 : débrancher une interface ne prouvait pas la fin de l’appel

Pour raccrocher, le modèle de la RFC 2127 demandait de supprimer une relation dans `ifStack`. Ce geste très précis révèle toute l’architecture: l’accès physique, la signalisation, le canal porteur et l’interface supérieure formaient des états distincts, dont aucun ne suffisait à…

21 sept. 2026
RFC 10040 abandonne le type LCAF 5, mais Experimental n’est pas un plan de migration

IETF

RFC 10040 abandonne le type LCAF 5, mais Experimental n’est pas un plan de migration

RFC 10040 attribue à LISP un nouvel encodage Geo-Location et déprécie l’ancien type Geo-Coordinates. Cette publication établit une nouvelle référence commune; elle ne prouve ni l’adoption du code, ni l’interopérabilité, ni l’achèvement d’une migration.

21 sept. 2026
RFC 2169 : une route HTTP n’est pas une autorité sur la ressource

Histoire d'Internet

RFC 2169 : une route HTTP n’est pas une autorité sur la ressource

En 1997, RFC 2169 proposait une idée volontairement étroite: employer HTTP pour interroger un résolveur au sujet d’un URN. La convention rendait une question transportable; elle ne donnait ni propriété ni pouvoir sur la ressource à l’hôte qui répondait.

21 sept. 2026
La version 3 est restée ; le service a changé : le pari de RFC 2126

Histoire d'Internet

La version 3 est restée ; le service a changé : le pari de RFC 2126

Conserver un numéro rassure: le pair reconnaît l’enveloppe. RFC 2126 montre pourtant le prix de cette continuité. Deux extrémités pouvaient lire « version 3 » sans partager la même classe de transport, les mêmes canaux ni le même contrat de fermeture.

21 sept. 2026
RFC 9647 : une route Babel « sélectionnée » ne suffit pas à prouver le service

Dossier

RFC 9647 : une route Babel « sélectionnée » ne suffit pas à prouver le service

Une ligne de route Babel peut afficher `selected = true` alors que la chaîne de preuves reste incomplète entre le datastore YANG, la politique effectivement appliquée à l’interface, l’échange authentifié avec le voisin, l’installation dans le plan de transfert, la reprise après…

21 sept. 2026
L’accord précédait l’appel : la décision en deux temps de RFC 2125

Histoire d'Internet

L’accord précédait l’appel : la décision en deux temps de RFC 2125

Dans RFC 2125, un pair pouvait accepter l’ajout d’une ligne sans que cette ligne existe encore. Le protocole conservait cet écart: une réponse autorisait l’action, puis un message distinct rapportait le résultat de l’appel réel.

21 sept. 2026
Le FAS a rendu son verdict ; le commutateur devait encore l’exécuter

Histoire d'Internet

Le FAS a rendu son verdict ; le commutateur devait encore l’exécuter

RFC 2124 centralisait la décision d’admission sans confondre cette décision avec l’état obtenu dans le commutateur. Son échange de messages racontait quatre histoires distinctes: autoriser, exécuter, réconcilier et compter.

21 sept. 2026
RFC 2123 : le relevé de flux était le produit d’un jeu de règles

Histoire d'Internet

RFC 2123 : le relevé de flux était le produit d’un jeu de règles

Le compteur NeTraMet ne conservait pas « le trafic ». Il répondait à une question choisie: quels protocoles examiner, quels attributs garder, dans quel sens lire une conversation et quelle finesse accepter quand la mémoire se raréfiait. RFC 2123 a rendu visible cette fabrication…

21 sept. 2026
Le lien ouvrait une session, pas un objet : la frontière VEMMI de la RFC 2122

Histoire d'Internet

Le lien ouvrait une session, pas un objet : la frontière VEMMI de la RFC 2122

Un lien `vemmi` ressemblait à une adresse Web, mais il ne promettait aucun fichier à récupérer. La RFC 2122 se servait du navigateur comme d’un point d’aiguillage vers un client distinct, une connexion continue et un dialogue d’accès. Le clic désignait l’entrée; il ne prouvait ni…

21 sept. 2026
RFC 9815 : le statut 2 doit survivre au redémarrage

IETF

RFC 9815 : le statut 2 doit survivre au redémarrage

Au passage de relais après un redémarrage, le premier voyant repasse au vert: le nœud répond et ses services restent joignables. Pourtant, dans l’état nouvellement généré, la contrainte négative qui interdisait son emploi comme nœud de transit a disparu. C’est précisément là que…

20 sept. 2026
La racine coordonnait les accords, elle ne gouvernait pas l’annuaire mondial : RFC 2120

Histoire d'Internet

La racine coordonnait les accords, elle ne gouvernait pas l’annuaire mondial : RFC 2120

À première vue, la racine de l’arbre X.500 semblait déjà résoudre le problème. En pratique, la norme laissait ses administrateurs face à une tâche qui croissait plus vite que l’arbre: chaque DSA de premier niveau devait conclure des accords bilatéraux avec tous les autres. RFC…

20 sept. 2026
La remise à zéro était dans le paquet suivant : la reprise MPPC de la RFC 2118

Histoire d'Internet

La remise à zéro était dans le paquet suivant : la reprise MPPC de la RFC 2118

La RFC 2118 a donné à Microsoft Point-to-Point Compression une mémoire continue et un signal de reprise remarquablement bref. Quand une perte rompait l’historique partagé, le récepteur demandait une remise à zéro; pourtant, c’était le paquet de données suivant, marqué `FLUSHED`…

20 sept. 2026
Le Join n’avait aucun reçu : l’arbre survivait par rafraîchissement — RFC 2117

Histoire d'Internet

Le Join n’avait aucun reçu : l’arbre survivait par rafraîchissement — RFC 2117

Dans RFC 2117, un arbre multicast clairsemé n’apparaissait jamais comme une transaction achevée. Une indication locale créait un état, des Join/Prune le renouvelaient routeur par routeur, un nouveau flux passait d’abord par des Register, puis certaines branches rejoignaient…

20 sept. 2026
Le navigateur se souvenait de la session, pas de la personne : RFC 2109

Histoire d'Internet

Le navigateur se souvenait de la session, pas de la personne : RFC 2109

En 1997, un serveur pouvait déposer `Customer="WILE_E_COYOTE"` dans un navigateur puis retrouver cette valeur au fil d’un panier et d’un choix de livraison. La RFC 2109 donnait ainsi une mémoire logique à HTTP. Mais le nom choisi par l’application ne transformait ni le cookie en…

20 sept. 2026
La carte semblait précise, mais le répéteur ne lisait toujours aucun paquet

Histoire d'Internet

La carte semblait précise, mais le répéteur ne lisait toujours aucun paquet

En 1997, une console de gestion pouvait situer une adresse source, classer les ports les plus actifs et reconstituer la topologie de plusieurs concentrateurs. RFC 2108 rendait cette carte exploitable en fixant les conditions de l’observation — pas en attribuant une intelligence…

20 sept. 2026
L’adresse disait « chez soi ». La ligne commutée disait « ailleurs » : RFC 2107

Histoire d'Internet

L’adresse disait « chez soi ». La ligne commutée disait « ailleurs » : RFC 2107

Le RFC 2107 donnait à un client distant l’apparence d’une présence sur son réseau d’origine. Cette illusion reposait sur un agent étranger, un agent mère, un secret partagé, un identifiant de tunnel et un état qu’il fallait créer puis supprimer dans le bon ordre.

20 sept. 2026