research: establish global network address book baseline

docs/01-scope-and-method.md

@@ -0,0 +1,47 @@
+# Scope and method
+
+## Research question
+
+Who coordinates, standardizes, operates, measures, interconnects, and protects the global Internet, and where can authoritative information about those actors be found?
+
+## Round 1 boundary
+
+This round establishes an ecosystem-level address book. It does **not** claim to catalog:
+
+- every autonomous system, ISP, carrier, cloud, CDN, IXP, cable, landing station, or data center;
+- every national regulator or ministry;
+- private individuals or non-public incident contacts;
+- commercial rankings or market share.
+
+## Method
+
+1. Define a functional taxonomy rather than a single organizational hierarchy.
+2. Select globally or regionally significant coordinating bodies and public directories.
+3. Prefer official homepages, registries, and operator-maintained datasets.
+4. Check that listed URLs resolve on the verification date.
+5. Capture scope, category, region, relevance, and provenance in `data/entities.csv`.
+6. Mark limitations and queue deeper enumeration as explicit future work.
+
+## Evidence levels
+
+| Status | Meaning |
+|---|---|
+| `verified` | Official source was reachable and the entity/category relationship is established by its public role. |
+| `partial` | Core identity is established, but contacts, coverage, or details need more work. |
+| `lead` | Candidate for investigation; not yet suitable for the canonical address book. |
+| `stale` | Previously valid entry whose source or role can no longer be confirmed. |
+
+Round 1 canonical entries are `verified`; this does not mean their datasets are complete or independently audited.
+
+## Contact policy
+
+This address book stores institutional links and public, role-based directories. It avoids personal phone numbers, personal email addresses, credentials, member-only data, and inferred contacts.
+
+## Update policy
+
+Every material change should include:
+
+- a primary source URL;
+- a UTC verification date;
+- a concise explanation in the commit message;
+- a move to `partial` or `stale` if the claim can no longer be verified.

docs/02-first-round-investigation.md

@@ -0,0 +1,67 @@
+# First-round investigation
+
+**Investigation date:** 2026-07-20
+**Canonical dataset:** 25 verified ecosystem-level entries in [`data/entities.csv`](../data/entities.csv)
+
+## Executive view
+
+The global Internet should not be modeled as one organization or one centrally owned network. It is better understood as several interdependent layers:
+
+1. **Identifiers and registries** — IANA, ICANN-related processes, the NRO, and five RIRs coordinate globally unique names, numbers, and protocol parameters.
+2. **Open technical standards** — IETF and W3C publish core protocol and Web standards, while ITU provides intergovernmental telecommunications standardization and coordination.
+3. **Distributed operations** — thousands of autonomous networks interconnect through private links and IXPs; PeeringDB, Euro-IX, and IX-F expose useful but participant-dependent views.
+4. **Naming infrastructure** — the DNS root is a globally distributed service with multiple independent operators; DNS-OARC provides an operational research community.
+5. **Physical transport** — terrestrial fiber, submarine cables, landing stations, facilities, spectrum, and power form a changing physical substrate. Round 1 identifies a discovery source, not a complete asset register.
+6. **Security and resilience** — routing norms, BGP collectors, RPKI/IRR systems, CSIRT communities, and operator groups provide overlapping coordination rather than a single control center.
+
+## Round-1 findings
+
+### 1. Build an “address book of authoritative directories” first
+
+Trying to list every network directly would become stale immediately. The scalable foundation is to map authoritative registries and maintained community datasets, then ingest or link to their records with provenance. The RIRs, PeeringDB, IX-F, FIRST, Root Server System, Route Views, and RIPE RIS are key anchor points.
+
+### 2. Governance, standards, ownership, and operation are different axes
+
+An organization can define a standard without operating infrastructure; register a resource without owning the underlying network; or operate a service without governing the global policy around it. Records therefore need functional categories and relationships, not a simplistic parent/child tree.
+
+### 3. Public datasets represent different kinds of truth
+
+- RIR registration data identifies registered resource holders and contacts, not necessarily current traffic operators or beneficial owners.
+- BGP collectors observe selected vantage points, not every path.
+- PeeringDB is maintained by participants and may be incomplete or temporarily stale.
+- Cable maps are discovery tools; ownership, operational state, and route details require corroboration.
+- CSIRT directories establish public identity and trust context, not permission to share sensitive data.
+
+### 4. Geographic language must describe service scope
+
+Headquarters location is often misleading. RIR regions, IXP associations, operator groups, and incident-response communities have specific service or membership boundaries. The dataset records service/community region separately from global/regional scope.
+
+### 5. The next useful unit is a relationship
+
+Future analysis should connect:
+
+- organization → autonomous system;
+- autonomous system → IP prefixes and RPKI objects;
+- network → IXP/facility/peering presence;
+- cable system → owner/operator/landing station/country;
+- DNS root identity → operator → sites;
+- CSIRT → constituency → country/sector;
+- source → claim → verification date.
+
+This graph should be derived from versioned source records rather than manually asserted as fact without evidence.
+
+## URL verification notes
+
+The official/canonical URLs in the dataset were checked with automated HTTP requests on 2026-07-20. Most returned successful responses. ICANN and NANOG returned HTTP 403 to the automated client while remaining canonical official links; this is recorded as a transport caveat. Packet Clearing House timed out during this pass and remains a round-2 lead rather than a canonical record.
+
+## Current limits
+
+- No country-by-country regulator or ministry directory yet.
+- No exhaustive ASN, ISP, cloud, CDN, carrier, IXP, facility, or cable inventory.
+- No graph database or automated ingestion yet.
+- No assessment of market concentration, dependency, geopolitical exposure, or outage risk.
+- No independent audit of every third-party dataset's completeness.
+
+## Conclusion
+
+Round 1 establishes a defensible navigation layer: 25 organizations, systems, and public directories spanning identifiers, standards, regional registries, DNS, interconnection, routing, physical transport, operator communities, and incident response. It is intentionally a map of where trustworthy investigation begins—not a claim that the world network has been fully enumerated.

docs/03-taxonomy.md

@@ -0,0 +1,23 @@
+# Taxonomy
+
+The Internet is decentralized, so this repository classifies entities by function rather than pretending there is one chain of command.
+
+| Category | Definition | Typical examples |
+|---|---|---|
+| `governance-identifiers` | Coordination of names, protocol parameters, IP/AS number systems, or multistakeholder policy | ICANN, IANA, NRO |
+| `standards` | Open technical or telecommunications standards development | IETF, W3C, ITU |
+| `registry` | Regional allocation/registration of IP addresses and autonomous-system numbers | AFRINIC, APNIC, ARIN, LACNIC, RIPE NCC |
+| `dns` | DNS root operations, research, and operational coordination | Root Server System, DNS-OARC |
+| `interconnection` | Public directories or associations for peering and Internet exchanges | PeeringDB, Euro-IX, IX-F |
+| `routing-security` | Routing hygiene, routing visibility, or routing-security coordination | MANRS, Route Views, RIPE RIS |
+| `incident-response` | Trusted communities and directories for CSIRT/CERT coordination | FIRST, Trusted Introducer |
+| `physical-infrastructure` | Public sources describing long-haul physical connectivity | TeleGeography Submarine Cable Map |
+| `operator-community` | Communities where network operators exchange operational practice | NANOG and future regional NOGs |
+
+## Geographic scope
+
+Use `global`, a named service region, or `regional-community`. Regional scope describes service responsibility, not headquarters location.
+
+## Stable identifiers
+
+`id` values are lowercase kebab-case and should survive branding changes where practical. Names and URLs may change; IDs should not be recycled.