How to change the Internet itself?#

Job Snijders

• Why: Part retrospective on routing-security wins (Large Communities, RPKI ROV, ASPA design), part forward look at a genuinely new piece of RPKI infrastructure — Erik Synchronisation — from someone who ships RPKI validator code. The process lessons for effecting protocol change are a bonus for anyone who has to drive standards adoption.
• What: Four case studies: how BGP Large Communities finally solved a problem IETF discussion had failed to close for 15+ years; how RPKI ROV deployment snowballed from the Netherlands; why ASPA deliberately unified IPv4/IPv6 upstream handling against academic objections; and why rsync and RRDP are both poor fits for RPKI repository distribution and what replaces them. The recurring thesis: minimum viable solutions, implementer preferences over academic elegance, and relentless evangelization.
• How: Erik Synchronisation combines Merkle trees, content-addressable storage, and concurrency control to take the best of rsync (stateless, jump-to-latest, delta-only) and RRDP (pre-calculated static content over HTTP). The key differentiator: anyone can run an "Erik Relay" mirroring all global RPKI data, and clients can rotate between relays for robustness — solving the "you can't force the origin to sit behind a good CDN" problem of RRDP.
• Where applicable: The RPKI/Erik material matters to every RPKI publisher and validator operator, and permissionless incremental deployment is the design goal. The case-study methodology (pick a problem, find who owns the solution space, build a PoC, teach it) is general. No org-specific constraints.