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.

Le port était le bon. Le serveur ne l’était pas : RFC 5383

IETF

Le port était le bon. Le serveur ne l’était pas : RFC 5383

Le numéro 25 figurait sur la porte, le dialogue ressemblait à SMTP et la connexion avait réussi. Pourtant, dans le cas consigné par la RFC 5383, l’hôtel pouvait avoir remplacé le serveur choisi par l’utilisateur. Un guichet familier ne prouve ni l’identité de l’établissement ni…

8 oct. 2026
Le même utilisateur a reçu deux ressources de principal

IETF

Le même utilisateur a reçu deux ressources de principal

Lundi, le client a mémorisé une URL de principal. Mardi, le même compte authentifié en a reçu une autre. L’équipe a conclu à un doublon d’identité; le serveur avait simplement choisi une autre ressource autorisée. RFC 5397 permet cette pluralité tout en demandant de la cohérence.…

8 oct. 2026
La liste des normes avait une date d’expiration : RFC 1280

Histoire d'Internet

La liste des normes avait une date d’expiration : RFC 1280

En mars 1992, l’Internet Activities Board a publié un état des protocoles accompagné d’un avertissement inhabituel pour un texte normatif: ne plus utiliser cette édition après le 31 juillet. La RFC 1280 pouvait coordonner les décisions, mais elle était déjà appelée à être…

8 oct. 2026
NEXGENET COMPANY LIMITED : la même adresse, deux organisations, une seule boîte de validation — examen de textes APNIC reproduits par des fournisseurs de recherche

Tendances services cloud Asie-Pacifique

NEXGENET COMPANY LIMITED : la même adresse, deux organisations, une seule boîte de validation — examen de textes APNIC reproduits par des fournisseurs de recherche

À Yangon, deux organisation entités APNIC coexistent au 838 Thuzitar Road: l'un au nom de NEXGENET COMPANY LIMITED, l'autre au nom de SMART & SHINE COMPANY LIMITED. Tous deux s'appuient sur le même objet de rôle — « NEXGENET COMPANY LIMITED administrator » — pour leurs contacts…

8 oct. 2026
Le port avait deux propriétaires cachés : la limite posée par la RFC 5382

IETF

Le port avait deux propriétaires cachés : la limite posée par la RFC 5382

Un port public ressemble à une adresse précise. Dans une table de traduction trop ambitieuse, il peut pourtant devenir un titre de propriété partagé, dont les copropriétaires ne sont distingués que par la destination qu’ils appellent. Tant que leurs chemins divergent, l’illusion…

8 oct. 2026
Un champ vide n’avait pas un seul sens : RFC 3982 a intégré l’absence au protocole

Histoire d'Internet

Un champ vide n’avait pas un seul sens : RFC 3982 a intégré l’absence au protocole

Une enquêtrice authentifiée peut recevoir une coordonnée tout en restant tenue de ne pas la transmettre. RFC 3982 avait compris cette dissociation essentielle: le droit de voir une donnée et le droit de la faire circuler ne sont pas la même autorisation.

8 oct. 2026
L’adresse OSI devait transporter plus qu’une route : RFC 1277

Histoire d'Internet

L’adresse OSI devait transporter plus qu’une route : RFC 1277

En 1991, des applications OSI fonctionnaient déjà à l’essai sur des réseaux TCP/IP et X.25 qui ne fournissaient pas le service réseau OSI. La RFC 1277 a placé dans une adresse de l’annuaire les indications de couche inférieure que celui-ci savait déjà renvoyer. Un client pouvait…

8 oct. 2026
Le nombre 16 a produit deux diagnostics différents

IETF

Le nombre 16 a produit deux diagnostics différents

Un écran d’exploitation reçoit `16` et annonce une erreur de version. Un autre, lisant le même nombre dans un TSIG, conclut à une signature invalide. Aucun compteur n’est faux; c’est le contexte qui manque. RFC 5395 rappelle ainsi une discipline élémentaire et souvent perdue dans…

8 oct. 2026
Les adresses aux deux bouts ne nommaient pas le réseau traversé : RFC 1272

Histoire d'Internet

Les adresses aux deux bouts ne nommaient pas le réseau traversé : RFC 1272

En 1991, un fournisseur Internet pouvait voir les adresses source et destination d’un paquet sans savoir quelle administration voisine l’avait acheminé au-delà d’une frontière. La RFC 1272 a fait de cet écart le problème central de la comptabilité réseau: pour rapprocher l’usage…

8 oct. 2026
Le cookie est devenu un second registre de session : RFC 5381

IETF

Le cookie est devenu un second registre de session : RFC 5381

Un identifiant peut être exact et pourtant désigner la mauvaise autorité. Dans l’expérience NETCONF sur SOAP consignée par la RFC 5381, la session existait dans le message NETCONF, dans un cookie HTTP et, selon la norme citée, dans la connexion persistante. Le client et le…

8 oct. 2026
Pour gérer les équipements, SNMP devait traverser les routeurs : le choix UDP/IP de la RFC 1270

Histoire d'Internet

Pour gérer les équipements, SNMP devait traverser les routeurs : le choix UDP/IP de la RFC 1270

En octobre 1991, placer la gestion du réseau au niveau réseau d’Internet ne répondait pas seulement à un souci d’économie de code. Les messages des opérateurs devaient souvent franchir des routeurs, des changements de support et des pannes localisées pour atteindre les…

8 oct. 2026
L’accusé de liaison était valide. Le premier paquet utile n’est jamais arrivé

IETF

L’accusé de liaison était valide. Le premier paquet utile n’est jamais arrivé

Dans la RFC 5380, un Mobility Anchor Point peut accepter une nouvelle association entre une adresse régionale stable et l’adresse locale courante. Cet accusé clôt une opération de contrôle précise. Il ne certifie ni le tunnel, ni le MTU utilisable, ni la livraison à…

8 oct. 2026
Quatre branches à la fois, des millions au total

IETF

Quatre branches à la fois, des millions au total

Un tableau de bord peut afficher quatre branches SIP actives et rester vert toute la journée. Un autre compteur, placé juste à côté, peut pourtant approcher dix millions de requêtes terminées. RFC 5393 oblige à lire les deux. `Max-Breadth` borne le travail simultané; il rend le…

7 oct. 2026
Le plan IPv6 du Botswana vise 2026. Que mesure le « 100 % » ?

Récits

Le plan IPv6 du Botswana vise 2026. Que mesure le « 100 % » ?

Le calendrier de BOCRA fixe des objectifs IPv6 jusqu’en 2026, tandis que le programme mené avec AFRINIC documente des ingénieurs formés et des projets préparés. Pour juger l’avancement sans divulguer les dossiers confidentiels des opérateurs, il faut d’abord savoir ce que le…

7 oct. 2026
La compatibilité cachait le coût. La RFC 1263 voulait rendre visible la frontière des versions

Histoire d'Internet

La compatibilité cachait le coût. La RFC 1263 voulait rendre visible la frontière des versions

En 1991, la question n’était pas de savoir si TCP évoluerait, mais où cette évolution prendrait place. La RFC 1263 soutenait qu’une extension rétrocompatible pouvait éviter un déploiement simultané tout en transférant la complexité dans un protocole déjà difficile à faire…

7 oct. 2026
Le serveur a refusé l’appel ; le réseau a multiplié l’effort

IETF

Le serveur a refusé l’appel ; le réseau a multiplié l’effort

Dans le livre de comptes d’un réseau SIP, un refus n’est pas une opération gratuite. Il faut recevoir la requête, la lire, choisir une réponse, l’émettre et parfois répéter tout le dialogue. RFC 5390 a montré qu’un serveur déjà saturé pouvait produire un 503 parfaitement conforme…

7 oct. 2026
Le MX secondaire pouvait recevoir le message sans pouvoir joindre le primaire : RFC 3974

Histoire d'Internet

Le MX secondaire pouvait recevoir le message sans pouvoir joindre le primaire : RFC 3974

Le repli avait fonctionné côté expéditeur: résolution DNS, connexion TCP, remise SMTP au MX secondaire. Pourtant ce relais IPv4 ne disposait d’aucun chemin vers le primaire IPv6 où le domaine voulait rassembler son courrier. RFC 3974 a isolé ce maillon caché entre acceptation et…

7 oct. 2026
Un nom fut réservé pour SIP et SIPS sans s’appliquer aux deux : RFC 3969

Histoire d'Internet

Un nom fut réservé pour SIP et SIPS sans s’appliquer aux deux : RFC 3969

Dans RFC 3969, chaque nom de paramètre occupait une place sous SIP et sous SIPS, même lorsque son mécanisme ne concernait qu’un seul schéma. Ce doublon apparent protégeait l’unicité du sens. Il ne promettait ni applicabilité symétrique, ni implantation, ni réussite d’un appel.

7 oct. 2026
Trente minutes pour oublier un routeur, pas pour basculer

Histoire d'Internet

Trente minutes pour oublier un routeur, pas pour basculer

Un routeur peut avoir disparu du lien alors que son adresse figure encore dans la liste dynamique des routeurs par défaut d’un hôte. La RFC 1256 prévoit l’expiration de cette entrée, mais son horloge par défaut vise la sobriété du réseau, pas la rapidité du rétablissement.

7 oct. 2026
Deux recherches dans la PAD empêchaient une seule chute de confiance

IETF

Deux recherches dans la PAD empêchaient une seule chute de confiance

RFC 5386 n’a pas traité l’anonymat comme une qualité résiduelle accordée après l’échec d’une identité connue. Il a imposé deux recherches logiquement distinctes dans la base d’autorisation des pairs. La première donnait priorité aux relations authentifiées. La seconde n’ouvrait…

7 oct. 2026