Sujet
Cycle de vie logiciel et dépendance fournisseur
Au sein de la facette Sujet, la veille thématique Cycle de vie logiciel et dépendance fournisseur 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.

IETF
Un registre exact ne peut corriger un module ASN.1 erroné
La panne tient dans une suite de nombres. Deux équipes mettent en œuvre la même RFC, mais l’une reprend l’identifiant d’objet imprimé dans le texte et l’autre consulte le registre de l’IANA. Chacune peut montrer une source officielle. Leurs logiciels, pourtant, ne se comprennent…

IETF
Le projet sur la préparation post-quantique cite une implémentation, sans fermer ses cinq lacunes
Une implémentation peut prouver qu’un mécanisme fonctionne dans un périmètre donné. Elle ne transforme pas automatiquement ce périmètre en état de préparation post-quantique. La révision 04 d’un projet Internet individuel ajoute un cas concret d’autorité de certification, mais…

Récits
Chez RIPE, la porte d’entrée NRTMv4 lit une réplique avant que le repli puisse agir
Le choix d’épargner la base principale est défendable. Le commit publié par le RIPE NCC montre toutefois que la vérification du nom intervient en amont du mécanisme capable de relire la notification sur la base maîtresse.

Récits
Le client d’IA de LACNIC résout un modèle, puis dialogue sans identifiant de résolution
Avec la version 1.6.0 du client Java de PAI, une application peut d’abord consulter l’affectation d’un usage, puis envoyer sa conversation. Elle connaît le fournisseur et le modèle de la réponse, mais ne reçoit pas la preuve que l’affectation consultée est bien celle qui a été…
Dossier
RFC 9746 : le coût de compatibilité d’un segment EVPN
Le choix de la méthode anti-boucle reste conditionné par les autres entités. L’arrivée d’un équipement utilisant la valeur par défaut peut rendre à nouveau nécessaires les étiquettes que les voisins avaient économisées.

Histoire d'Internet
RFC 2056 : quand une URL ouvre une interaction Z39.50
En 1996, RFC 2056 a inscrit la recherche et la récupération Z39.50 dans la syntaxe des URL sans effacer l’état de session, les choix du client ni l’autorité locale du serveur.

Histoire d'Internet
Le descripteur vide raccourcissait la liaison, pas le contrôle d’accès
Deux échanges pouvaient précéder la première opération NFS utile: découvrir un port RPC, puis demander à MOUNT de convertir un chemin exporté en descripteur. En 1996, le RFC 2054 proposa de commencer par l’hypothèse la plus probable et de réserver les anciens échanges aux cas où…

Histoire d'Internet
Dire « RC5 » ne suffisait pas : la frontière probatoire de la RFC 2040
La RFC 2040 n'a pas inventé RC5 et ne constitue pas un guide de déploiement contemporain. Elle accomplit une tâche plus austère: montrer qu'une famille cryptographique ne devient interopérable qu'une fois son identité complète — paramètres, état CBC et traitement du dernier bloc…

Histoire d'Internet
La configuration disparaît, la session demeure : la leçon du RFC 2051
Le MIB APPC de 1996 décrivait une dissociation rarement aussi nette: l’enregistrement de ce qui devait exister pouvait être supprimé sans effacer la session déjà en fonctionnement.

Histoire d'Internet
Reprendre à la tranche suivante sans prétendre sauver l’image : la frontière MPEG de la RFC 2038
Dans la RFC 2038, le transport ne cherchait pas à deviner où le décodeur pouvait repartir: l’en-tête RTP rendait visible le début et la fin des tranches MPEG, tout en répétant quelques éléments de l’état de l’image. Cette visibilité permettait une reprise locale après une perte…
IETF
Le compteur a bougé. Mais quels octets l’ACL a-t-elle vus ?
RFC 9899 permet de décrire avec précision la recherche d’un motif binaire dans un paquet. Il ne transforme pas pour autant un nœud YANG valide, une ACE programmée, des octets visibles, un compteur en hausse et un résultat applicatif en une preuve unique. L’assurance commence par…

Histoire d'Internet
Le fichier inconnu devait rester opaque : le seuil de la RFC 2049
En 1996, être conforme à MIME ne voulait pas dire comprendre tous les formats. La promesse était plus étroite: décoder les représentations communes, ne pas confondre des octets avec du texte et savoir reculer lorsque le type demeurait inconnu.

Histoire d'Internet
Le fragment connaissait sa place, pas l’intégrité de l’image : la frontière de reconstruction de la RFC 2035
La RFC 2035 a économisé les descriptions JPEG stables et répété dans chaque paquet le minimum nécessaire pour les reconstruire. L’offset et les points de reprise ont rendu les pertes plus observables, sans jamais certifier une image complète, ponctuelle ou réellement vue.
IETF
Le serveur a accepté la vue, pas l’autorité d’écrire
En 2020, un projet NETMOD proposait de choisir un schéma YANG versionné par session NETCONF ou par chemin RESTCONF. Cette sélection circonscrit une interprétation; elle ne transforme pas une réponse valide en preuve de changement du réseau.

IETF
Le substitut OpenPGP voyage. Pas la clé secrète.
Une sauvegarde peut contenir un trousseau OpenPGP parfaitement lisible et rester incapable de signer ou de déchiffrer quoi que ce soit. Ce paradoxe est le point de départ d’un projet soumis à l’adoption du groupe OpenPGP: normaliser le substitut transportable d’une clé dont le…
IETF
Le masque a tranché la liste, pas la vérité du nœud
Une étiquette visible dans l’état opérationnel semble avoir gagné un arbitrage. Dans la révision 11 d’un projet NETMOD désormais expiré, elle n’est pourtant que le résultat d’une composition: apports du module, de l’implémentation et de l’utilisateur, puis soustraction des…

Histoire d'Internet
Les octets ASCII ont gardé leur place ; le sens exigeait un autre contrat : RFC 2044
En 1996, l'obstacle n'était pas seulement la taille d'un alphabet mondial. Il fallait introduire des caractères multioctets dans des logiciels qui traitaient la barre oblique, le zéro ou le signe pour cent comme une syntaxe. RFC 2044 a protégé ces octets ASCII sans prétendre…

Récits
Le standard geofeed est arrivé. ARIN doit documenter son passage au service
Un standard achevé ne déploie aucun produit à lui seul. Il change toutefois la nature de la question. En 2024, ARIN avait rattaché une demande communautaire à l’acceptation d’une extension RDAP commune, puis nommé RDAP, ARIN Online et Reg-RWS comme surfaces à modifier. RFC 9877…
IETF
Un résultat vert ne dit pas quel schéma a parlé
La révision 00 d’un projet NETMOD aujourd’hui expiré proposait deux niveaux de validation pour `anydata`. L’enjeu n’est pas d’ajouter un badge « valide », mais de conserver le contexte YANG Library qui donne un sens limité et reproductible au résultat.

Histoire d'Internet
Un lien PPP, deux autorisations SNA : ce que l’état Opened de RFC 2043 ne prouvait pas
Un câble ne rend pas deux protocoles solidaires. Dans RFC 2043, SNA avec LLC 802.2 et SNA HPR sans LLC empruntaient le même lien PPP, mais franchissaient deux portes de contrôle distinctes. L’ouverture de l’une ne disait rien sur l’autre — et aucune ne pouvait certifier le…
