Time Horizon
Multi-year
Within the Time Horizon facet, Multi-year time-horizon intelligence organises articles by the period over which a signal is expected to matter. The page helps readers distinguish immediate operational changes from longer-cycle governance, investment, standards, and infrastructure shifts that may unfold across quarters or years. It connects timing assumptions with public evidence, related actors, market context, customer exposure, policy pressure, and infrastructure planning so readers can judge whether a development is urgent, strategic, or still waiting on confirming evidence. The page also explains how time horizon changes the meaning of a signal, which organisations may be exposed, and which infrastructure decisions require short-term action or long-cycle monitoring.
Global Datacenter Trends
Amazon Has First Call on X-energy's 2031–2039 Reactor Queue
Amazon did not need to place a conventional reactor order to acquire leverage over X-energy's future factory sequence. X-energy's securities filings say Amazon holds first-priority manufacturing allocation across 2031–2039, a right of first refusal over part of scheduled…
History
The NAK Rejected the Port, Not the Packet: RFC 938 and the Boundary Between Delivery and Dispatch
In an experimental 1985 Internet protocol, a receiver could say two things at once: the next packet number had been received in sequence, and the local port named in that packet was not known. RFC 938 called that reply `PORT NAK`. Its precision is a useful warning against…
IETF
Bas Westerbaan and the Hybrid TLS Handshake That Did Not Make the Certificate Post-Quantum
A browser can report `X25519MLKEM768`, derive a session secret from classical and post-quantum components, and still authenticate the server with a classical certificate signature. Both observations can be true in the same TLS 1.3 connection. Calling the whole service…
History
The UUID Crossed the Connection. Authority Stayed Put: RFC 927 and the Double-Login Bargain
A TAC could check a name and password once, then send a four-octet user number to the next host. RFC 927's useful restraint lay in what did not travel with that number: the target still decided whether the first host's authentication was good enough for its own service.
IETF
Daniel Fett and the QR Context That MFA Never Authenticated
The password was right, the second factor was real and the authorization server behaved as designed. The attacker still received the session, because the ceremony proved who the user was without proving whose request the user had approved.
Global Datacenter Trends
Marvell Added US$5.76bn of Supplier Commitments. Customer Orders Stay Cancellable
Marvell has made one side of its AI-capacity wager much harder than the other. In thirteen weeks, unconditional purchase commitments to foundries and test-and-assembly partners rose from US$2.7568 billion to US$8.5189 billion. The new schedule reaches deep into fiscal 2030. Yet…
History
The Keystroke Cost Four Octets: How RFC 916 Let State Replace Repetition
One typed character once faced a seven-octet packet around it. RFC 916 cut that packet to four octets by moving the character into the header position that would otherwise say how long the data was. The saving worked only because the connection had already made the missing facts…
History
The Name That Did Not Report a Reading: RFC 1065 and the Shape of Manageable Things
In 1988, Internet management needed a way to describe what could be observed without pretending that a description was already an observation. RFC 1065 supplied that restraint: a managed entity type could have a stable name, syntax, encoding and access category, while the live…
History
The Byte That Meant “Start Over”: SLIP, RFC 1055, and the Cost of Recovering a Serial Frame
On a quiet serial line, the difference between a valid packet and yesterday’s noise could be one byte. RFC 1055’s SLIP convention used `END` to finish an IP datagram, but it also recommended an `END` before the next datagram. That extra byte did not repair the wire or certify the…
IETF
Mike McBride and the Multicast Registry That Prevented One Kind of Collision
Two IPv6 multicast allocation methods had been told to draw identifiers from the same box. RFC 10028 divided the box before a future host protocol and an old server protocol could make the same choice—and left operators with the harder job of proving that their networks had…
History
The Cutover Was Not One Cutover: How RFC 897 Separated Renaming from DNS Resolution
On 14 March 1984 a host could acquire an official name ending in `.ARPA` while the program using that name still consulted a local copy of a centrally maintained table. The new namespace could arrive through the old lookup machinery. RFC 897 made that apparent contradiction a…
History
The LANs the Host Was Not Meant to See: RFC 925 and the Cost of Hiding a Topology
An early Internet site could either expose every cable to the wider network or arrange its cables so that a host believed it lived on one large local network. RFC 925 chose the second illusion. It kept the host's ARP unchanged and made an intermediary discover, remember and…
History
The Carrier Was Not the Connection: How RFC 892 Separated Transport State from the Network Path
One network connection could carry several transport conversations. One transport conversation could, in the most capable class, ride several network connections. RFC 892 treated those as inverse mappings rather than a contradiction: the carrier moved protocol units, while peer…
IETF
Gavin Brown and the Successful Create That Did Not Yet Register a Domain
The server said the command had completed successfully. In the same breath, it said the action was still pending. RFC 8334 makes that apparent contradiction useful: an accepted application is evidence, but it is not yet a registered domain.
IETF
Russ Housley and the MAC Address a Certificate Could Name but Not Make Unique
Six bytes can fit cleanly inside a certificate. The difficult part begins after they leave it: who assigned them, what interface is using them now, who observed that use, and why a local network should permit an action.
History
The Fastest Path Carried the Clock. It Did Not Choose the Master: How RFC 891 Bound Routing and Time to One HELLO
In the Fuzzball network, one HELLO could change both the route to a host and the clock offset associated with that route. The economy was deliberate, but authority remained divided: measured delay selected a path, configuration named the master, and the local clock decided…
History
The Frame Was Longer Than the Datagram: How RFC 894 Kept Ethernet Padding Out of IP
An Ethernet interface could deliver 46 data octets even when the IPv4 datagram inside it ended sooner. RFC 894 did not resolve the mismatch by stretching IP. It assigned two rulers to two layers: Ethernet supplied enough zeroes to satisfy its physical minimum, while the IP Total…
IETF
Benoît Claise and the Augment the Base Module Could Not Name
A YANG module can list the modules it imports. It cannot, by reading itself, identify every external module that later inserts nodes into its schema tree. RFC 10035 makes that hidden direction reportable—one direct edge at a time.
History
The First Answer Was Not the Last Word: How RFC 887 Separated Discovery from Confirmation
A host in 1983 could ask an entire local network who provided a service. Yet RFC 887 refused to treat the first name it heard as final truth. Broadcast discovery, an explicit negative answer, a third-party hint and a provider’s own confirmation were four different kinds of…
IETF
Kazuho Oku and the Header That Makes Refusal Legible but Cannot Promise Streaming
An HTTP field can require a proxy that understands it to reject instead of quietly buffering. It cannot command a proxy that has never learned the field. RFC 10036 improves the evidence around incremental delivery precisely by preserving that distinction.