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.

Histoire d'Internet
Sans AFI, la politique valait pour « any » : les quatre familles de RFC 4012
RPSLng a ajouté une clause facultative pour préciser la famille d’une politique multiprotocole. Son absence ne laissait pas la portée indéterminée: RFC 4012 lui donnait le sens « any », tandis que les anciens attributs conservaient leur sens IPv4 unicast.

Dossier
Le trafic des racines DNS a doublé ; l’indice venait d’une mise à jour de résolveur
Pendant environ une semaine, le débit de requêtes reçu par le DNS racine est passé d’environ 1,6 à 3,2 millions par seconde. Le trafic était valide et provenait de réseaux de résolveurs récursifs; les opérateurs n’ont constaté aucun effet mesurable sur le service racine.…

IETF
RFC 5416 : la liaison 802.11 a une frontière d’époque
RFC 5416 décrit une liaison CAPWAP précise pour IEEE 802.11. Elle organise les échanges entre le point de terminaison radio et le contrôleur, mais ne transforme pas un champ de capacité en garantie pour toutes les fonctions Wi-Fi ultérieures. Pour une décision de direction, il…

IETF
L’état CAPWAP ne prouve pas le service : RFC 5415
RFC 5415 organise un plan de contrôle WLAN: un Access Controller gère des Wireless Termination Points, établit des sessions protégées, applique des réglages et transporte des données clients. Mais un état de protocole terminé, une session DTLS ou un paquet de données reste une…

IETF
WiCoP est une archive historique, pas une base de déploiement : RFC 5414
RFC 5414 décrit WiCoP, un protocole de contrôle et de provisionnement des grands réseaux WLAN. Le RFC Editor le classe Historic et renvoie à RFC 5415. La distinction est décisive: un contrôleur visible ou un accusé de réception ne prouve ni l’autorité actuelle, ni l’application…

Récits
AS24940 : 91 routes, 63 correspondances et 49 autorisations plus larges
Le résumé de veille AS24940: 91 routes, 63 correspondances et 49 autorisations plus larges explique le développement, les preuves publiques disponibles, les organisations concernées, le contexte régional, l’exposition au marché et les conséquences possibles pour l’infrastructure.…

IETF
La sécurité SLAPP est une frontière historique, pas une preuve de déploiement
Le RFC 5413 conserve Secure Light Access Point Protocol tel qu'il a été soumis aux travaux CAPWAP. Ses idées de découverte, d'authentification et de transport protégé sont utiles pour l'histoire, mais le RFC Editor le publie pour le registre historique et déconseille de…

IETF
LWAPP est une archive historique, pas une base de déploiement
Le RFC 5412 conserve l'état du Lightweight Access Point Protocol au moment où il a été soumis aux travaux CAPWAP. Il éclaire l'architecture contrôleur–point d'accès, mais le RFC Editor le classe Historic et indique qu'il ne doit pas servir de base à un déploiement. Le RFC 5415…

IETF
CATS a choisi le contact du service. Le backend est resté caché : RFC 10053
CATS peut orienter une requête vers un point de contact prometteur à partir de l’état du réseau et des ressources de calcul. Ce choix ne révèle pas nécessairement quelle instance interne traitera la requête, ni si les métriques publiées décrivent cette instance seule.

Histoire d'Internet
Le contrôleur devait d’abord disposer d’un réseau pour le piloter : RFC 7149
En mars 2014, un mémo de l’IETF invitait les opérateurs à dépasser le schéma séduisant du contrôleur central. Comment celui-ci découvre-t-il les équipements, les atteint-il et influence-t-il sans risque le réseau qu’il gouverne ? RFC 7149 place le démarrage, la négociation du…

IETF
Un guide SIP est une carte, pas un certificat de déploiement
Le RFC 5411 aide à s'orienter dans une famille SIP devenue trop vaste pour tenir dans une seule fiche. Il classe les textes, indique leur statut et renvoie vers les sujets voisins. Mais c'est un instantané informatif, pas l'inventaire en temps réel d'un opérateur. Une entrée peut…

Histoire d'Internet
DHCP transportait un identifiant d’abonné stable, sans en définir le sens : RFC 3993
Un client pouvait changer de ligne d’accès alors que le fournisseur souhaitait conserver la même décision de configuration. RFC 3993 a donné au relais DHCP un champ pour transporter un identifiant d’abonné stable, tout en laissant au fournisseur le soin de lui attribuer un sens.

IETF
L'extension transportait un message de clé. Elle ne prouvait pas son installation.
Pour OMA BCAST, MIKEY devait transporter des clés courtes et longues, des rapports et des règles de contrôle parental. Le RFC 5410 ajoute un conteneur General Extension. Ce conteneur atteste un type et des octets; il n'atteste ni la réception utile, ni l'installation d'un…

IETF
CMS a enveloppé la clé. L'identité du destinataire devait encore correspondre.
Le RFC 5409 ne dit pas seulement que l'IBE peut protéger un courrier. Il fixe les conventions CMS qui chiffrent une clé de contenu avec BF ou BB1, encodent l'identité du destinataire et choisissent l'algorithme par OID. Une enveloppe valide n'est pas encore une autorisation.

IETF
Une identité peut calculer une clé publique. Elle n'accorde pas un droit.
Le chiffrement fondé sur l'identité semble supprimer une friction familière: l'expéditeur calcule la clé publique à partir de l'identité du destinataire, puis un service de génération fournit la clé privée au moment utile. Le RFC 5408 décrit cette architecture avec précision. Il…

IETF
Un meilleur site ne suffit pas à déplacer une session : RFC 10054
Un flux peut rejoindre un nouveau site périphérique alors que l’état du service reste attaché à l’ancien. La RFC 10054 permet de raisonner sur la charge de calcul et les conditions réseau, mais exige que l’application indique explicitement si elle autorise CATS à réorienter une…

IETF
Le canal était lié ; l’opération restait une décision distincte.
An SIP gateway showed a verified security context and a clean message check. The dashboard promoted that evidence into “authorised and complete.” RFC 5407 draws a harder line: SIP Version 2 can bind a SIP message to lower-channel information, but the binding does not become local…

Histoire d'Internet
Le niveau 2 appartenait à la session, pas à l’appareil : RFC 7147
Un même système de stockage peut accueillir plusieurs sessions iSCSI. RFC 7147 rattache le niveau de protocole négocié à chacune d’elles: c’est l’accord entre un initiateur et une cible qui est décrit, pas une étiquette globale apposée sur la machine.

IETF
Le canal était lié ; l’opération restait une décision distincte.
An IPsec gateway showed a verified security context and a clean message check. The dashboard promoted that evidence into “authorised and complete.” RFC 5406 draws a harder line: IPsec Version 2 can bind a IPsec message to lower-channel information, but the binding does not become…

IETF
Le canal était lié ; l’opération restait une décision distincte.
An RTP gateway showed a verified security context and a clean message check. The dashboard promoted that evidence into “authorised and complete.” RFC 5404 draws a harder line: G.719 RTP Version 2 can bind a G.719 frame block to lower-channel information, but the binding does not…
