Time Horizon
NEAR TERM
Within the Time Horizon facet, NEAR TERM 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.
Europe and Middle East Institutional Trends
The Pass Is Not the Prize: CADA’s Two Procurement Decisions
The European Commission’s proposed Cloud and AI Development Act does not create one undifferentiated “European sovereignty” preference. It builds two different procurement mechanisms for different jobs: Articles 29–30 would determine which recognised cloud services may enter…
Story
RIPE’s space-address draft names the NRO. Who sets the policy?
A September Internet-Draft requests IPv6 space for use beyond Earth and gives the NRO a role in structuring and distributing it. The institutional handoff remains unspecified: how would that coordination connect to the separate policy processes of five RIR communities, including…
Story
APNIC’s 70% KSK signal does not count the users at risk
APNIC Labs’ sentinel tests and Verisign’s resolver reports both tracked readiness for the 2026 root KSK rollover, but they sampled different populations from different vantage points. Neither percentage is a headcount of people who could lose DNS service.
Story
AFRINIC’s election results disclose rank, not the vote margins
The June 2026 results show who received longer terms in two ballot contests, but not how many votes separated the candidates or how many eligible voters took part. The guidelines say the Nomination Committee should publish final results and statistics; the pages reviewed show the…
IETF
IETF’s Newcomer Course Won’t Track Learners. Its Impact Still Needs a Record
The IETF is commissioning a self-paced course to help new entities enter a technical process that can take years to learn. Its decision not to assess or track individual learners protects a useful boundary. It also leaves a governance question: how can the organisation show that…
IETF
RFC 9019: A Signed Firmware Manifest Is Not Installation Authority
The release pipeline turns green when a firmware manifest verifies. The payload digest matches, the signer is known, and the sequence number is acceptable. Only then does the neglected question become visible: what was this signer actually allowed to change on this device, at…
IETF
RFC 9608: No Revocation Route Is Not Permanent Trust
A validator skips one line because a certificate carries `noRevAvail`. The dashboard then paints the whole credential green. That colour has silently combined two different findings: the certificate asked for no revocation lookup, and the relying service has decided to keep…
IETF
RFC 9810: The Certificate Was Granted, but Not as Requested
A certificate-enrollment dashboard turns green. The protected response is valid, the transaction identifier matches and the CA has issued a certificate. Yet the status is `grantedWithMods`, not `accepted`. The protocol has completed a successful exchange while leaving the…
IETF
RFC 9775: The Rule Is Shared, but the Authority Changes with the Forum
The same disruptive message appears first on a research-group mailing list and then on an IRTF-wide list. The standard of conduct does not change, but the person entitled to act does. RFC 9775 is most useful when read not as one large prohibition but as a map of forum, moderator…
IETF
RFC 9797: A Randomized MAC Address Can Reduce Linkability Without Becoming Device Identity
A support desk can see the same laptop twice: once under yesterday’s MAC address and once under today’s. That does not mean there are two devices, and seeing one address twice does not prove there is only one. RFC 9797 makes this mundane ambiguity a governance problem: privacy…
IETF
RFC 9818: A Delegated Prefix Is Not Usable Capacity Until the Lease, Route and Filter Agree
A provider may hand an IPv6 CE router more address space than one LAN needs. RFC 9818 shows why that allocation is only the first claim in a longer chain: a downstream lease, a next-hop route, a matching filter decision and a lifetime bounded by the parent delegation must remain…
IETF
RFC 9862: The Drop Flag Lives on a Candidate Path, but the Consequence Belongs to the Whole SR Policy
RFC 9862 carries a drop instruction on one Candidate Path even though the resulting decision belongs to the entire Segment Routing Policy. That mismatch between signaling scope and consequence scope is exactly where an operational status can be correct yet still fail to explain…
IETF
RFC 9867: A Created Security Association Is Not Proof That the PPK Was Mixed
An IKEv2 exchange can finish and a new Security Association can appear even when the preshared key intended to strengthen it was never incorporated. RFC 9867 makes that outcome legitimate under optional policy. It also makes a creation-only security dashboard dangerously…
IETF
RFC 9707: Being Connected Is Not Access—and a Workshop Report Is Not a Mandate
An Internet link can be live while the service a person needs remains unaffordable, unreadable, blocked, fragile or unsafe. RFC 9707 makes that failure visible. It also marks the limit of its own authority: the document records a workshop, not a consensus verdict. Governance…
IETF
RFC 9812: A Stricter Review Gate Does Not Allocate IPv6 Space
Most of the IPv6 address space remains marked “Reserved by IETF.” RFC 9812 changed the rule for any major future release of that reserve from IESG Approval to IETF Review. That is a consequential transfer from an exceptional gate to a public, documented process. It is not an…
IETF
RFC 9998: A Failed Age Check Is Not Consent to a More Intrusive One
Age checks are often presented as a door: prove the required range and it opens; fail and it stays shut. The harder governance problem begins when the first check produces no reliable answer. A system may then ask for a document, a face scan, a phone number or a longer behavioral…
IETF
RFC 9876: A CoAP Registry Number Is Not an Interoperability Verdict
The smallest number in a protocol can carry the largest institutional misunderstanding. A CoAP Content-Format identifier lets a constrained device say, compactly, what representation it is sending. RFC 9876 makes the allocation of that number much harder to get wrong. It does not…
IETF
RFC 9874: A Successful EPP Delete Can Break Another Client’s DNS
The dangerous EPP deletion is not necessarily the one that fails. It is the one that succeeds for the requesting client while changing name-server state relied on by domains sponsored by somebody else. RFC 9874 turns that hidden dependency into an operational question. The…
IETF
The Network Agreed the Root Was Down. It Did Not Prove a Crash: RFC 9866
RFC 9866 lets a low-power network reach a coordinated decision that its current routing root is no longer usable. The decision can be operationally correct even when the root is still powered and the physical cause is unknown. Treating `GLOBALLY DOWN` as a forensic verdict would…
IETF
Babel’s Hidden Key and the Authority Behind a Boolean Answer
An operator barred from reading a Babel MAC key may still, with effective authorisation, ask the device to use it in a local comparison. That separation can support maintenance without distributing secret material. It also requires a decision about who controls the test and how…