Profil
Research
Research rassemble les profils des personnes, entreprises, institutions et autres entités couvertes par BTW.MEDIA, afin que les lecteurs puissent comparer les sujets derrière ses reportages. La page permet de comparer les profils publics, les événements associés, les dossiers de preuves, les changements de responsabilités, l’ampleur des activités, l’exposition aux instances de gouvernance, les liens organisationnels et la pertinence sur le marché, tout en distinguant les fiches des organisations et des personnes de la simple chronologie de l’actualité. Les lecteurs peuvent comprendre qui ou ce que représente le profil, sur quelles sources publiques il s’appuie, comment il se relie aux entreprises, aux infrastructures, aux marchés, aux instances de gouvernance ou aux événements, et quels changements méritent une attention continue à mesure que le sujet évolue.
IETF
Le nom persistait. Son statut, lui, avait changé.
Le RFC 5165 a créé un espace mondial pour les noms OGC, tout en laissant l’autorité de nommage gérer les sous-arbres et tolérer des valeurs expérimentales non enregistrées. La leçon durable n’est pas qu’une URN ne change jamais, mais qu’un nom n’est fiable que si son autorité…
Dossier
DFINFRA : la couche contact face au miroir, à la fusion et au déficit de responsabilité
Le résumé de veille DFINFRA: la couche contact face au miroir, à la fusion et au déficit de responsabilité 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…
IETF
Le canal était digne de confiance. L’ordre restait opaque.
Le RFC 5164 imaginait une couche de transport commune pour plusieurs services de mobilité. Elle pouvait découvrir un interlocuteur, protéger l’échange et transporter des octets; elle ne pouvait pas, précisément parce que la charge utile restait opaque, décider seule de la…
IETF
Cinq paquets, une seule enveloppe : le coût caché de PDU-Concat
Le RFC 5163 traite l’agrégation comme une économie comptable: un type, une destination et une enveloppe remplacent plusieurs répétitions. Mais la somme doit tomber juste, faute de quoi l’efficacité devient une perte commune.
IETF
La responsabilité s’arrêtait au prochain domaine. La preuve du trajet, elle, devait continuer.
En limitant chaque garantie QoS au domaine que l’opérateur maîtrise, la RFC 5160 rend la responsabilité bilatérale praticable. Elle ne fait toutefois pas disparaître la performance de bout en bout: elle déplace sur le vendeur du service la charge de composer et de conserver la…
IETF
Le média a changé de flux de clés. Rien ne prouvait que le terminal l’avait vu.
Dans RFC 5159, une association `stkmstream` placée au niveau d’un média remplaçait celle annoncée pour toute la session. Cette règle était précise et utile: deux pistes d’un même service pouvaient dépendre de flux de messages de clés différents. Elle créait aussi un point de…
IETF
Les serveurs étaient prêts. Ils ne certifiaient pas la vérité du PTR.
RFC 5158 cherchait à rendre exploitable la délégation DNS inverse d'un site 6to4. Le service pouvait vérifier que les serveurs proposés répondaient, faisaient autorité et présentaient le même SOA ainsi que les mêmes NS. C'était un contrôle de préparation sérieux. Ce n'était ni…
IETF
Le modèle est arrivé trente et une minutes plus tard. Les données avaient déjà cessé d’exister.
Le collecteur avait reçu les octets, réservé de la mémoire et attendu leur définition. À l’expiration du délai, il les a journalisés puis supprimés. Une minute plus tard, le Template est arrivé. Le réseau venait de livrer les deux pièces nécessaires, mais la politique de durée…
IETF
La frontière était joignable. Elle condamnait pourtant la paire de chemins.
Le prochain ASBR répondait, le segment local respectait les contraintes et le premier LSP atteignait sa destination. Rien, dans ces reçus pris séparément, ne disait que cette sortie préservait assez de liberté pour un second chemin diversifié. RFC 5152 montre pourquoi une…
IETF
L’erreur a été retenue. L’ingress n’a jamais vu le détour qui l’avait effacée.
Un routeur de frontière peut suspendre un PathErr pendant qu’il tente un autre chemin. Si ce nouvel essai réussit, il doit jeter l’erreur retenue. Ce silence est une bonne nouvelle pour l’établissement du LSP; il n’est pourtant ni le journal des essais, ni la preuve que la cause…
IETF
Le relevé montrait un seul saut. Le segment cachait cinq nœuds.
Dans le RRO de bout en bout, le segment GMPLS tenait dans un identifiant de lien TE. Les routeurs intermédiaires ne devaient pas y apparaître. L’abstraction était conforme à la RFC 5150, mais elle ne prouvait ni l’état de ces nœuds, ni la diversité physique, ni le chemin…
IETF
Le service privé s’est ouvert. L’accès public s’est refermé.
Un terminal mobile a demandé un service d’entreprise et reçu une inscription positive. Le tunnel privé fonctionnait, mais le domaine externe appliquait un filtrage qui coupait l’accès simultané à l’Internet public. La sélection avait produit un contexte de service; elle n’avait…
IETF
L’alerte avait réveillé tous les routeurs. Le hasard n’a fait que séparer leurs réponses.
Une rupture de voisinage a déclenché le même message de contrôle sur plusieurs nœuds mobiles. Sans délai, ils auraient parlé ensemble. Avec une attente aléatoire, leurs émissions se sont écartées. Cette séparation répond exactement au problème traité par la RFC 5148. Elle ne dit…
IETF
L’archive avait conservé le texte. Le transcodage avait déplacé la référence.
Une archive a restitué le bon fichier, sous le bon URI, mais dans un autre encodage de caractères. Le passage visé par une position `char` s’est décalé tandis que l’écran continuait d’afficher une sélection nette. RFC 5147 rend l’adressage du texte brut explicite; il révèle…
Histoire d'Internet
La page avait passé son contrôle. Le média n’était pas encore entier : RFC 3533
Dans Ogg, la somme de contrôle n’était pas un verdict sur l’œuvre. Elle attestait une page précise; le paquet, le temps du codec, l’authenticité et l’écoute restaient à établir par d’autres preuves.
Histoire d'Internet
La réponse BEEP était positive. L’appel XML-RPC avait échoué : RFC 3529
Le canal avait reconnu la ressource, la session était protégée et une réponse `RPY` était revenue. Aucun de ces faits n’obligeait pourtant la procédure XML-RPC à réussir.
IETF
Le renvoi était exact. L’autorité avait changé en chemin.
Le service public a répondu proprement, puis a indiqué où poursuivre la recherche. L’utilisateur a suivi le renvoi et cru transporter avec lui la certitude du premier serveur. Or RFC 5144 organise précisément une séparation: le contrôle DCHK peut être léger, le registre détaillé…
IETF
RFC 9835 : le circuit était référencé, pas encore livré
Un identifiant peut relier la commande du client à un objet de réseau sans démontrer que le service circule. RFC 9835 rend cette couture explicite: assez solide pour automatiser, mais assez limitée pour obliger l’opérateur à chercher la preuve au-delà de la base de données.
Histoire d'Internet
Les commandes s’exécutaient dans l’ordre. Pas les transactions : RFC 3525
Trois transactions pouvaient voyager dans le même message sans partager la même file d’exécution. La boîte était commune; le temps opérationnel ne l’était pas.
IETF
Le paquet est arrivé. Son heure de passage était déjà révolue.
Dans une émulation de circuit, recevoir n’est pas forcément livrer. Un paquet CEM peut franchir le réseau, présenter un en-tête que l’ECC-6 sait corriger, puis arriver trop tard pour le créneau SONET/SDH qu’il devait alimenter. Le dépaquétiseur le compte, mais le circuit ne peut…