Content Type
Long Form
Within the Content Type facet, Long Form intelligence gathers BTW.MEDIA articles that share the same editorial format, helping readers compare briefings, profiles, risk notes, market analysis, and event coverage without mixing different kinds of evidence. The page explains how this content type frames internet infrastructure events, company movements, governance decisions, operational signals, and public evidence across the site. Readers can compare which actors or infrastructure systems appear most often, how source quality changes interpretation, and whether the material is a durable profile, a time-sensitive event, a strategic market signal, or a governance development. The result is a useful search page for operators, investors, customers, analysts, and policy stakeholders who need to understand the consequence, timing, and evidence behind similar article formats.
IETF
Corey Bonnell and the CRL Signature Whose Key Was Not Authorized
A certificate revocation list can carry a flawless digital signature and still be signed by the wrong certified key. RFC 10007 closes that uncomfortable gap by requiring a version 3 CRL issuer certificate to say, explicitly, that its key may sign CRLs. The change turns a skipped…
IETF
Kireeti Kompella and the Echo Reply That Did Not Prove the Service
An MPLS Echo Reply can show that one carefully constructed probe reached a router able to account for a particular forwarding equivalence class. That is a precise and valuable result. It does not show that every equal-cost path worked, that a dormant backup was usable, that the…
IETF
Eliot Lear and the Device Policy That Was Never an Attestation
A limited-purpose device can tell a network which communications it needs without proving what the device is, who currently controls it, or whether it will behave as described. RFC 8520 makes that narrow statement useful through Manufacturer Usage Description, then leaves the…
IETF
Tero Kivinen and the New IKE SA That Inherited Live Child SAs
In IKEv2, the word “rekey” can describe two materially different successions. Replacing the protected control association creates a new IKE SA, yet the Child SAs carrying ESP or AH traffic can remain exactly the ones already in service. The distinction documented in RFC 7296…
IETF
Roy Fielding and the Method That Named an Intention, Not a Permission
An HTTP request begins with a compact public word. That word can tell a client, cache or intermediary what kind of result is being sought. It cannot say who is entitled to obtain it, whether the target will comply, or what happened after a connection failed. The architecture…
IETF
Mark Nottingham and the User Agent That Could Not Speak for Every User
The browser can deny a service direct access to a person's machine, carry a narrow preference and make another implementation possible. Those powers make the user agent a valuable intermediary. They do not turn software, its vendor or a standards entity into the authorized voice…
IETF
Dieter Sibold and the Cookie That Let the Time Server Forget
Network Time Security performs its expensive act first: authenticate a key-establishment service, derive two directional keys and close the TLS connection. Later NTP requests carry the missing association state back inside an opaque encrypted cookie. RFC 8915 made forgetting…
IETF
David Lawrence and the DNS Answer That Outlived Its TTL
When a DNS answer reaches the end of its TTL, a recursive resolver normally discards or refreshes it. RFC 8767 allows a narrower choice during failure: preserve the expired copy for a bounded time, return it only after a real refresh attempt cannot produce usable data, and keep…
IETF
Steve Sheng and the Lock That Did Not Stop DNSSEC Maintenance
A domain can display an update lock while its DNSSEC delegation data still changes legitimately. RFC 10026 resolves the apparent contradiction by asking what the lock actually binds: which actor set it, whose command it rejects, and which independently authenticated maintenance…
IETF
Peter Thomassen and the Update That Needed Every Authoritative Server
A child zone can publish a perfectly signed request for its parent to change trust or delegation data. RFC 9975 asks a harder question before the parent acts: did the request come from the delegated authoritative service as a whole, or only from the one server that happened to…
IETF
Paul Hoffman and the Root Copy That Could Answer Only Its Own Host
A recursive resolver can keep the entire DNS root zone close enough that a root query never leaves its machine. RFC 8806 permits that local execution path, then surrounds it with unusual restraints: the service cannot answer the next host, cannot invent a byte of root data…
IETF
Stuart Cheshire and the Half-TTL Rule for Silence
The strangest useful mDNS query is one that already contains answers. A host puts its cached records into the question so nearby responders can decide not to repeat them. RFC 6762 makes that silence conditional: the record must still carry at least half its proper TTL, and nobody…
IETF
Ari Keränen and the Candidate Pair That Won Before Success Could Be Claimed
An ICE log can name the transport path a session selected with millisecond precision. It still cannot tell an operator whether anyone heard a word, whether an application admitted the session or whether permission to keep sending remained fresh. The useful record begins where the…
IETF
Erik Nordmark and the Neighbor That Became Stale Before It Became Unreachable
An IPv6 neighbor can become `STALE` while it is still carrying traffic, and it can enter `UNREACHABLE` while packets are still sent to its cached link-layer address. The apparent contradiction disappears once the cache is read as a record of expiring evidence rather than a…
IETF
Carsten Bormann and the Token That Matched a Reply, Not a Person
A field small enough to fit inside a constrained message can still be asked to carry too much institutional meaning. CoAP’s design offers a better discipline: give each compact identifier one narrow job, preserve the surrounding evidence, and refuse to turn correlation into…
IETF
Fernando Gont and the First Fragment That Had to Name What Came Next
An IPv6 fragment can arrive first without explaining what the completed packet is for. The source address is visible, the destination is visible and the fragment offset says zero, yet the transport header a firewall needs may be hiding in a later piece. RFC 7112, co-authored by…
IETF
Jen Linkova and the Five-Minute Clock That Kept IPv4 on Call
The most revealing part of RFC 8925 is not that a device can decline an IPv4 address. It is that the refusal expires. A client asks for DHCPv4 option 108, a configured server returns a waiting time, and the client pauses DHCPv4 only until that clock runs out or the network…
IETF
Warren Kumari and the Wi-Fi Link That Encrypted Without Knowing Who Was There
A public wireless network need not choose between a shared password and sending every nearby listener a readable copy of the radio exchange. RFC 8110's Opportunistic Wireless Encryption creates a different bargain: derive a fresh secret for each association, encrypt the local…
IETF
Álvaro Retana and the Prefix That Left the RIB but Kept the Link
An OSPF adjacency can remain full, its topology edge can continue to influence SPF, and packets can still cross the link even after the link's numbered prefix has vanished from remote routing tables. RFC 6860 makes that separation an operational tool. For Álvaro Retana, one of…
IETF
Acee Lindem and the LSA That Travelled Unread
In a mixed-version OSPFv3 area, a router can receive a well-formed Extended LSA, store it and relay it within the encoded flooding scope while understanding none of its optional meaning. RFC 8362 makes that behaviour deliberate. Acee Lindem, one of its five co-authors, helps…