Topic
Software Lifecycle and Lock-in
Within the Topic facet, Software Lifecycle and Lock-in topic intelligence connects articles that share a specific subject, signal focus, or monitoring theme. The page gives readers a richer path through related reporting, source evidence, market actors, and infrastructure implications, with enough context to understand why the topic matters across company movements, governance decisions, regional exposure, and operational risk. Readers can compare recurring signals, affected organisations, public evidence, market context, service continuity, procurement, competition, compliance, and strategic planning questions behind the subject instead of stopping at a thin list of matching articles. It explains what the topic covers, which infrastructure actors or policies are involved, what evidence supports the coverage, and why the subject may matter for operators, customers, investors, and policy readers.
History
The Offer That Was Not a Negotiation: How TCP MSS Bounded Each Direction
Each side of a TCP connection can place a four-byte option in its opening SYN. The number does not settle a shared packet size. It says how much TCP data the option's sender is prepared to receive in one segment—a directional boundary that the other endpoint must combine with…
History
The Handshake That Had to Remember Its Previous Handshake: How RFC 5746 Bound TLS Renegotiation
A TLS handshake could authenticate its own conclusion while saying nothing cryptographic about the bytes that came before it on the same connection. RFC 5746 repaired that gap by requiring every renegotiation to carry evidence from the immediately previous handshake.
History
The Neighbor That Stayed in the Cache After It Became Unreachable: How RFC 7048 Separated Failover from Forgetting
IPv6 Neighbor Discovery once treated the last unanswered unicast probe as both a warning to seek another path and a reason to erase the path it already knew. RFC 7048 split those decisions: a neighbor could become officially unreachable without its final link-layer address being…
History
The Address That Spoke Before It Was Proven Unique: How Optimistic DAD Bounded Early Use
A newly attached IPv6 host used to wait for a uniqueness test before speaking. RFC 4429 shortened that silence without pretending the test had already passed: the address could carry traffic, but not yet exercise the Neighbor Discovery powers of an uncontested owner.
IETF
The Insecure Middle of a Secure TACACS+ Migration: RFC 9887 and the Cost of Dual-Stack Authentication
A TACACS+ client using TLS must not fall back to non-TLS when TLS negotiation fails. Yet a migration can temporarily keep separate non-TLS TACACS+ servers for devices that cannot move at once. That coexistence is not a secure dual stack: RFC 9887 considers the mixed phase…
CASE FILE
The Notification Arrived. One Backend Still Had Nothing to Serve
The IETF is asking for final comments on a proposed operating guide for RPKI publication services. Its sharpest rule is also the easiest to violate during a routine rollout: do not expose the new notification until every snapshot and delta it names is already available. An index…
CASE FILE
The Candidate Path Reached BGP. The Forwarding Plane Had Not Voted: RFC 9830
A controller advertises two Segment Routing candidate paths to a headend. Both arrive over valid BGP sessions. One wins BGP's comparison for its advertisement; the other remains a distinct route because its Distinguisher differs. Neither fact says which candidate the SR Policy…
History
The Header Described an Archive. It Did Not Authorize the Decoder to Run It: RFC 1505
The line counts agree. The archive expands. The checksum closes. A shell command now waits in a directory created from an email message. In 1993, RFC 1505 drew the most important boundary at exactly this point: successful decoding was not permission to execute.
CASE FILE
The Challenge Released the Message. It Still Had Not Reached the List
The IETF plans to replace the machinery behind its email services on 11 September. The design usefully separates challenges, list handling, identity rewriting, signing and outbound transport. It also makes the central operating question unavoidable: when one component reports…
CASE FILE
The CRL Number Was Higher. RPKI Still Had to Ignore It: RFC 9829
A relying party retrieves two signed revocation lists from one publication point. The first carries the larger CRL Number. The second is the file named by the certificate and hashed on the issuer’s current manifest. A generic PKI instinct says to trust the larger counter. RFC…
History
The Router Saw a New Network. It Was a Shadow of Its Own Mapping: RFC 1504
The route looked newly learned and the number was locally valid. The awkward fact was that no second network had appeared. A number invented at one translation boundary had travelled around a redundant path, lost its lineage and returned as if it belonged to a stranger.
History
The Key That Could Change Mid-Connection: TCP-AO's Rollover Signal
Long-lived routing sessions made a simple operational question unusually dangerous: how can two endpoints replace an authentication key without dropping the TCP connection or guessing the same switching instant? TCP-AO answered with visible key identifiers and directional…
CASE FILE
The Tag List Kept Its Order. It Still Lost Part of the Policy: RFC 9825
Four administrative tags left an OSPF area in the intended order. The next router supported only two. Its log said the list had been preserved; its policy engine therefore looked healthy. Yet the action-bearing tag had occupied the third position. No field was reordered, no…
History
The RFC Published a Straw Poll. It Did Not Create a Constituency: RFC 1501
Two electronic addresses at the end of a two-page RFC offered individual OS/2 users a way to be counted. They were doors into a proposed organisation, not proof that the people behind those doors had already become members, chosen representatives or moved IBM.
History
The Gateway Kept the Message. It Could Not Preserve Every Meaning: RFC 1496
RFC 1496 gave an X.400(84)–MIME gateway an admirably stubborn rule: convert what it can, encapsulate what it cannot, and never discard an entire message merely because one body part is unfamiliar. That discipline protected the carrier. It did not make every heading survive, every…
CASE FILE
The EAP Method Succeeded. The Protected Session Still Needed a Second Witness: RFC 9820
The access controller displayed three green facts: the EAP method had succeeded, the Master Session Key had been exported, and the constrained device had been placed in the security domain. Only the first two facts could be reconstructed. No one could produce the protected…
CASE FILE
The IESG Approved Three ML-KEM Groups. The Registry Recommended None
An approved IETF document can define exactly how three post-quantum groups travel through TLS while leaving the deployment verdict deliberately unresolved. That is not bureaucratic ambiguity. It is a precise boundary between an interoperable mechanism, a registry coordinate and…
History
The Table Moved the Service. It Did Not Rename It: RFC 1498
A 1993 RFC recovered an older lesson: a table can change where a service runs while its name survives. Reaching it still requires separate evidence for the node, attachment point and path—and none of those bindings alone proves identity, authority or delivery.
History
The Code Was Available. The Original Specification Was Not: RFC 1492
The original TACACS specification existed, and the author of RFC 1492 could not obtain it because of copyright issues. What reached the public record in July 1993 was therefore an Informational reconstruction, constrained by running code and candid about the possibility that the…
CASE FILE
All Three Attestations Were True. They Still Did Not Belong to the CSR Key
A certification request can arrive with one valid statement about an HSM, another about corporate ownership and a third about platform health. The dangerous moment comes when a certificate authority treats three successful checks as one joined fact. Revision 29 of an IETF draft…