Summary

  • On 28 October 2025, Ramakant Pandrangi submitted ARIN suggestion 2025.7 asking for a service-by-service dependency map, advance notice of material changes and recovery objectives for critical registry systems.
  • ARIN replied on 12 November that it was developing a plan for those disclosures and would seek community feedback. The active-suggestions register still calls the item Open on 2 November 2026.

The question arrived from Verisign, which said its own number resources, IRR and RPKI objects depend on ARIN's systems. It asked for the upstream chains behind the member portal, RPKI certificate authority and publishing servers, and IRR servers: DNS, CDN, address space, BGP paths and network providers. This is an operator asking where its fallback plan might share a failure with the registry it relies on.

ARIN's answer accepted the need for transparency and promised a plan to document dependencies, change management and continuity objectives. The promise is dated; the implementation marker has not moved. The open status does not tell us what ARIN has built internally. It tells customers that this public process has no published completion receipt.

A July 2026 maintenance notice shows why service boundaries matter. ARIN said its online portal, RESTful provisioning, RPKI Up/Down and repository publication would be unavailable during a four-hour window; Whois, RDAP, IRR and the RPKI repository would keep running without new updates. That is a clear planned-window split. It supplies neither an external dependency map nor the requested restoration and data-recovery objectives.

A versioned ARIN plan naming each critical service's dependencies, change-notice rule and recovery targets would close the evidentiary gap. Until then the operator can see the maintenance calendar, but not the whole chain that might turn one broken component into several unavailable services.