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 plan de diagnostic n’est pas une cause : huit reçus pour l’OAM programmé
`draft-ietf-opsawg-scheduling-oam-tests-07` propose d’ordonner et de programmer des tests OAM à l’échelle du réseau. Cette structure est utile, à condition de ne pas confondre le plan enregistré, l’exécution réelle, la mesure obtenue, l’inférence causale, l’autorité de changer le…
IETF
Même couleur, chaîne de preuve incomplète : lire RFC 9832 au-delà du numéro
Un opérateur peut recevoir trois occurrences de la valeur 100 et exécuter trois décisions différentes. RFC 9832 ordonne la sélection d’une classe de transport; il ne transforme ni un entier privé en définition mondiale du service, ni une route résolue en preuve de l’expérience…

Histoire d'Internet
Le droit s’ouvrait sans demande, puis pouvait se refermer : RFC 1988
En 1996, un texte informatif de l’IETF a consigné une permission à la fois simple à activer et difficile à résumer: automatique pour un usage normalisé précis, inexistante pour les MIB propriétaires et révocable de façon définitive par un acte de riposte brevet.

Histoire d'Internet
Le paquet perdu et son ombre : la chaîne interpaquets de RFC 1969
Dans le protocole DESE de 1996, une perte ne s’arrêtait pas au paquet disparu. Elle rendait également indéchiffrable le paquet suivant, tout en laissant dans le chiffrement de celui-ci le point de reprise nécessaire au troisième. Cette asymétrie raconte mieux que tout slogan ce…
IETF
RFC 9845 : les watts baissent, la preuve reste à construire
Une courbe électrique descend vite. Démontrer qu’un réseau a réellement réduit son empreinte, sans déplacer la charge ni dégrader le service, exige une chaîne de preuves beaucoup plus longue.

Histoire d'Internet
Le paquet non compressé qui modifiait encore l’historique : RFC 1967
Le drapeau C/U de LZS-DCP peut annoncer des données non compressées sans annoncer un état immobile. Avec Process-Uncompressed, les octets transmis tels quels alimentent les deux copies de l’historique. RFC 1967 isole en outre ordre, contrôle et remise à zéro par History Number…

IETF
La révision 04 de CMIS ajoute le transfert de contrôle, mais laisse la dernière écriture en suspens
Retirer une page d’une liste d’autorisation prend une ligne de configuration. Restituer sans ambiguïté le contrôle d’un module optique peut demander davantage. Si le contrôleur distant a déjà exécuté deux étapes d’un réglage et que le système hôte récupère la page avant la…

IETF
La révision 04 promet l’identité UUID, mais son schéma énergétique pointe encore vers un nom local
Dans un inventaire local, `psu-1` peut suffire. Dans deux centres d’administration, ce même nom peut désigner deux alimentations sans aucun lien. La révision 04 du modèle YANG énergie de GREEN affirme justement vouloir sortir de cette ambiguïté grâce à l’UUID. Pourtant, le chemin…

Récits
Le renouvellement de K-root par le RIPE NCC exige trois procès-verbaux, pas un statut global
Une ligne de suivi peut être exacte et rester insuffisante. Le RIPE NCC indique que le renouvellement de trois sites centraux de K-root est en cours et qu’Amsterdam a déjà été renouvelé. Ce que l’on peut en conclure s’arrête là: pour savoir si chaque changement est clos, il faut…

IETF
DKIM2 maintient la double signature jusqu’à sa généralisation, sans définir le point de sortie
Un régime transitoire peut rester volontaire tout en étant vérifiable. La révision 01 des bonnes pratiques DKIM2 recommande de conserver DKIM1 et DKIM2 jusqu’à ce que le nouveau mécanisme soit « effectivement omniprésent ». Elle ne précise toutefois ni la population observée, ni…
IETF
Le manifeste accompagne la télémétrie, pas son interprétation
La révision 14 conserve avec les données le contexte de la plateforme, du schéma et de la collecte. Elle rend une mesure plus intelligible, sans certifier que la série est complète, que l’horloge est juste ou que la décision qui en découle est fondée.
IETF
La ligne de journal est lisible. L’autorité sur la connexion ne l’est pas : RFC 9850
RFC 9850 donne aux outils de diagnostic une grammaire commune pour les secrets TLS. Cette lisibilité technique ne dit ni qui pouvait ouvrir la connexion à l’observation, ni quand ce pouvoir a réellement pris fin.
Dossier
Le cookie est revenu, pas encore le service : la limite de la RFC 9853
La RFC 9853 permet à un pair DTLS de vérifier une adresse apparue après qu'un Connection ID a retrouvé le contexte de sécurité existant. Le cookie retourné autorise une décision de liaison à un instant précis; il n'explique ni le changement d'adresse ni la continuité du service.
IETF
Le Vérificateur s’est abonné, pas la décision
Un projet de l’IETF transforme l’attestation des équipements en flux d’événements. Il rapproche la mesure de l’observation, sans abolir les frontières entre preuve reçue, évaluation, autorisation et résultat.
Dossier
Deux chemins appariés ne prouvent pas un aller-retour : RFC 9854
Dans un réseau radio contraint, le trajet qui permet à une requête d'atteindre sa cible peut être inutilisable dans l'autre sens. Le RFC 9854 traite ce problème avec deux instances directionnelles liées; cette liaison protège la cohérence du contrôle, mais elle ne constitue ni…

Histoire d'Internet
Un dictionnaire perdu dans un sens, le trafic continuait dans l’autre : RFC 1962
Sur une liaison PPP, « les deux extrémités sont d’accord » était une formule trop grossière. En 1996, RFC 1962 a séparé deux décisions: ce que chaque récepteur sait décompresser et ce que son pair peut donc lui envoyer. La même séparation limite la panne: un dictionnaire peut…
Dossier
Le contrôleur a reçu l’état. Il lui manquait encore une horloge : RFC 9857
RFC 9857 rend enfin l’état des chemins candidats SR Policy visible hors du routeur de tête. Cette visibilité inverse le sens habituel de l’automatisation, sans résoudre la question décisive: de quand date l’observation et jusqu’où peut-on lui faire confiance ?

Histoire d'Internet
Aucun mémo ne pouvait commander au réseau : RFC 1958 et le droit de changer
Un texte intitulé « Principes architecturaux de l’Internet » aurait pu se prendre pour une constitution. RFC 1958 fit le contraire: avant d’énoncer ses règles, il organisa leur droit à devenir caduques.
IETF
Une entropie nouvelle entre dans la session ; la reprise reste à prouver dans les deux sens
Le KeyUpdate ordinaire de TLS 1.3 prolonge une chaîne de secrets déjà établie. Le projet Extended Key Update propose de refaire un échange de clés dans une session vivante et d'injecter un secret partagé neuf. Cette opération ouvre une possibilité de reprise après compromission…

Histoire d'Internet
L’URL transportait une requête, pas son autorité : RFC 1959
Une adresse que l’on peut copier donne une impression de stabilité. Pourtant, dans le cas de RFC 1959, ce qui voyageait n’était ni une fiche d’annuaire ni une décision d’accès. L’URL rassemblait les éléments nécessaires à la construction d’une recherche LDAP. Le serveur…
