Domaine principal
Infrastructure
Au sein de la facette Domaine principal, l'analyse Infrastructure regroupe les articles par domaine principal afin que les lecteurs puissent suivre un périmètre précis de l'infrastructure Internet, de la gouvernance, des marchés de connectivité ou du capital numérique. Cette page rassemble les articles associés, les preuves publiques, les institutions, les entreprises, les personnes, l'exposition régionale, les dépendances opérationnelles et le contexte de marché qui pourraient sinon être répartis entre différentes pages de catégories. Elle explique le domaine, la classe d'acteurs probable, le contexte de marché ou de gouvernance, ainsi que les sources que les lecteurs devraient utiliser pour comparer les signaux. Opérateurs, analystes et lecteurs de gouvernance peuvent voir comment un même domaine se manifeste à travers les événements, les profils, les évolutions de marché, les preuves issues de sources publiques, les dépendances régionales et les décisions d'infrastructure à plus long cycle au fil du temps.

Histoire d'Internet
Le registre et le RFC divergeaient. Le réseau avait déjà tranché : RFC 3115
Deux mois après RFC 3025, RFC 3115 dut corriger deux numéros d’extension Mobile IP. Le choix n’était pas arbitraire: les implémentations utilisaient déjà les valeurs inscrites chez IANA.

Histoire d'Internet
Le mot de passe correspondait. L’utilisateur n’était pas encore authentifié : RFC 3112
RFC 3112 permettait à LDAP de comparer un secret à une valeur dérivée conservée dans l’annuaire. Mais la réponse vraie restait volontairement étroite: elle ne transformait pas la connexion en association authentifiée.

Histoire d'Internet
Les deux couches disaient « vers l’avant », mais regardaient en sens opposés : RFC 3108
Dans RFC 3108, un paramètre pouvait être exact, bien formé et pourtant appliqué au mauvais flux. La commande d’appel et la signalisation du support ATM employaient toutes deux « avant », mais ne plaçaient pas l’origine au même endroit.

Histoire d'Internet
La passerelle prêtait l’adresse, la localité devenait un protocole : RFC 3102
Avec Realm Specific IP, l’hôte privé ne subissait plus une traduction invisible: il empruntait des paramètres publics et les plaçait lui-même dans ses paquets. Cette transparence ne supprimait pourtant pas la passerelle; elle rendait visibles son allocation, son bail et son…

Histoire d'Internet
L’authentification DHCP restait dans le domaine de confiance : RFC 3118
RFC 3118 a ajouté l’authentification à DHCP, mais pas une identité valable sur tout le réseau. Son échange différé supposait qu’un client et un serveur reçoivent hors bande un secret partagé dans un même domaine administratif; la politique locale gardait le dernier mot sur…

Histoire d'Internet
Avant que le consentement ne devienne une case à cocher : RFC 3098
RFC 3098 ne demandait pas seulement aux annonceurs d'être courtois. Il transformait la responsabilité en dispositif: ne pas inscrire par défaut, expliquer l'usage des données, confirmer la demande avec sa provenance, offrir une sortie et laisser à l'annonceur le coût d'entretien…

Histoire d'Internet
ROHC a commencé sans voie de retour : RFC 3095
Avant de pouvoir croire un accusé de réception, ROHC devait fonctionner là où aucune réponse ne pouvait revenir. RFC 3095 imposait donc un départ en mode unidirectionnel, puis donnait au décompresseur le pouvoir de demander un mode fondé sur le retour d'information.

Histoire d'Internet
TALI ne pouvait présumer que son pair était en version 2 : RFC 3094
Avant d’envoyer une nouvelle opération de gestion, une passerelle TALI 2.0 devait déterminer ce que le pair distant savait comprendre. La RFC 3094 transforme cette négociation en règle de protocole, tout en publiant la proposition du fournisseur avec un avertissement…

Histoire d'Internet
« Foo » était déjà dans les RFC quand son explication est arrivée : RFC 3092
En 1971, RFC 269 demandait de renommer `FOO` en `BAR` sans dire pourquoi ces deux mots pouvaient remplacer n’importe quel fichier. En 2001, RFC 3092 constatait que près de 7 % de la série employaient déjà cette langue d’initiés. Le glossaire venait après l’usage.

Histoire d'Internet
Le groupe multicast de PI n’était pas une adresse IPv4 : RFC 3091
Le RFC 3091 imaginait que des clients reconstituent PI à partir d’un flux, de réponses UDP indexées ou du multicast. Mais son groupe multicast n’avait pas de représentation IPv4 valide; ailleurs, ses ports TCP et UDP dépassaient aussi la capacité des champs qui doivent les…

Histoire d'Internet
Le pare-feu autorisait HTTP, pas le paquet caché dedans : RFC 3093
RFC 3093 proposait de placer un datagramme IP complet dans un message HTTP, de franchir l’ouverture réservée au Web puis de le réinjecter derrière le pare-feu. Publié le 1er avril 2001, ce dispositif comique révélait une limite sérieuse: autoriser l’enveloppe ne signifie pas…

Histoire d'Internet
La même zone était sûre ici et non sécurisée ailleurs : RFC 3090
En 2001, demander si une zone DNS était « sûre » ne suffisait déjà plus. Il fallait savoir quel résolveur posait la question, quelle racine de confiance il connaissait et quel chemin il avait suivi. RFC 3090 a donné des mots à cette relativité: une zone signée pouvait former un…

Histoire d'Internet
Le serveur racine indiquait une piste, pas la réponse LDAP : RFC 3088
Dans un annuaire réparti, le premier serveur peut connaître le prochain relais sans détenir la fiche recherchée. En 2001, l’expérience OpenLDAP a rendu cette frontière visible: son service racine consultait DNS et renvoyait des URL LDAP, puis laissait l’annuaire désigné répondre.

Histoire d'Internet
L’URI choisissait le menu vocal, sans authentifier l’appelant : RFC 3087
En 2001, un appel SIP pouvait parvenir à une messagerie sans emporter tous les indices fiables qui guidaient les anciens commutateurs. RFC 3087 a confié au destinataire courant de la requête le choix du premier état de l’application. L’adresse donnait une consigne de service…

Histoire d'Internet
Le serveur avait poussé les règles. La reconnexion devait encore réconcilier ce que l’équipement avait gardé : RFC 3084
RFC 3084 organisait le provisioning de politiques comme une conversation à états partagés: une décision groupée, un accusé d’exécution, un retour à l’état antérieur en cas d’échec. La coupure révélait pourtant la limite du modèle. Le serveur et l’équipement pouvaient tous deux…

Histoire d'Internet
Le numéro de révision ordonnait les NewsItems ; il ne les livrait pas : RFC 3085
Un même NewsItem pouvait être conservé sur plusieurs serveurs. En 2001, RFC 3085 lui a donné un URN unique et un numéro pour ordonner ses versions. Le texte distinguait aussi la mise à jour d’un article du remplacement de ses seules métadonnées de gestion, sans promettre qu’un…

Histoire d'Internet
Le câble chiffrait le trafic. Son plan de gestion pouvait encore désactiver la confidentialité : RFC 3083
RFC 3083 a rendu la confidentialité DOCSIS observable, réglable et réinitialisable par SNMP. Cette visibilité aidait le diagnostic, mais elle ouvrait une seconde frontière de sécurité: l’interface qui regardait les clés pouvait aussi relancer l’autorisation, modifier les délais…

Histoire d'Internet
TCP était fiable. Un canal pouvait encore affamer les autres : RFC 3081
RFC 3081 a placé une session BEEP sur une seule connexion TCP, puis a traité le problème que la fiabilité du transport ne résolvait pas: un canal applicatif lent pouvait retenir la capacité commune et priver ses voisins de progrès. La réponse fut un crédit propre à chaque canal…

Histoire d'Internet
Les notifications ont continué sans le Directory Agent ; de nouveaux services pouvaient rester invisibles : RFC 3082
La RFC 3082 voulait remplacer les interrogations répétées du réseau par des notifications de changement. Son scénario de reprise met en lumière une asymétrie plus fine: les service agents déjà informés peuvent continuer à émettre, tandis qu’un nouvel arrivant peut ne jamais…

Histoire d'Internet
Une connexion n’était pas une conversation : RFC 3080
Dans BEEP, une connexion parfaitement saine pouvait n’abriter encore aucune conversation applicative. RFC 3080 réservait le canal zéro à une fonction étroite: annoncer des profils, ouvrir des canaux et les fermer. Le sens n’apparaissait qu’après l’acceptation d’un profil précis.…
