Systems and Protocol Aspects for Circumstellar Environments J. A. Fraire Internet-Draft Inria Intended status: Informational D. York Expires: 7 February 2027 Internet Society 6 August 2026 A Registry of Announced, Filed and Deployed Satellite Constellations draft-fraire-spacerg-constellation-registry-00 Abstract Aggregate figures for the number of satellites planned for low Earth orbit are widely quoted and rarely traceable. They mix quantities that are not comparable: satellites already in orbit, satellites a national regulator has authorised, satellites applied for and not yet granted, and satellites that exist only in an announcement. For a single system these can differ by orders of magnitude. Which one a headline figure refers to decides whether it describes infrastructure or intent. This document describes a community-maintained registry that keeps the four apart and requires every number in it to carry a citation and an evidence grade. It sets out the data model, the taxonomy of regulatory commitment, the rules that separate primary regulatory sources from secondary reporting, and the criteria for inclusion. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-fraire-spacerg-constellation- registry/. Discussion of this document takes place on the Systems and Protocol Aspects for Circumstellar Environments Research Group mailing list (mailto:space@irtf.org), which is archived at https://mailarchive.ietf.org/arch/browse/space/. Subscribe at https://www.ietf.org/mailman/listinfo/space/. Source for this draft and an issue tracker can be found at https://github.com/irtf-spacerg/id-leo-constellations. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Fraire & York Expires 7 February 2027 [Page 1] Internet-Draft Constellation Registry August 2026 Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 7 February 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. The four quantities . . . . . . . . . . . . . . . . . . . 3 1.2. Why a filing is not a plan . . . . . . . . . . . . . . . 4 2. The registry . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. One record, one authorisation . . . . . . . . . . . . . . 4 2.2. Evidence grading . . . . . . . . . . . . . . . . . . . . 4 2.3. Regulatory commitment as a ladder . . . . . . . . . . . . 5 2.4. Orbital geometry . . . . . . . . . . . . . . . . . . . . 5 2.5. Point-in-time observations . . . . . . . . . . . . . . . 6 2.6. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Relationship to other SPACERG work . . . . . . . . . . . . . 6 4. Conventions and Definitions . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . 7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Fraire & York Expires 7 February 2027 [Page 2] Internet-Draft Constellation Registry August 2026 1. Introduction Research on satellite networking rests on assumptions about scale. How large will future constellations be, how many operators will share the spectrum, and how much coordination load will land on national regulators and on the International Telecommunication Union (ITU)? Those assumptions usually come from press coverage and from aggregate trackers. The problem runs deeper than careless reporting. The quantities underneath are genuinely different, and they are all published under one label. A constellation may have satellites in orbit, a national licence for a larger number, an application pending for a larger number still, an ITU filing declaring more again, and a press release describing something else entirely. All five are true statements. However, presented as a single figure for "planned satellites", four of them disappear. This registry exists to keep them apart. It forecasts nothing and predicts nothing about what will eventually fly. What it records is narrower: who filed what, with which authority, at what stage of which process, and every number traceable to a document. 1.1. The four quantities The registry distinguishes: * *launched*, satellites placed in orbit, cumulative and including those since deorbited; * *licensed*, satellites a national regulator has granted authority to operate; * *filed*, satellites requested from a regulator or declared to the ITU, whatever the outcome; * *announced*, satellites described publicly with no filing behind them that can be found. Keeping these four apart is the registry's main design constraint. Most of the schema follows from it. Fraire & York Expires 7 February 2027 [Page 3] Internet-Draft Constellation Registry August 2026 1.2. Why a filing is not a plan A filing is a claim on spectrum priority, and nothing in it obliges anyone to build. Commitment, where it exists at all, comes from national regulators. Some administrations attach dated deployment milestones to an authorisation, with a financial instrument behind them and a defined consequence for missing them. The ITU process has no equivalent. Its earliest stage, advance publication, confers no coordination priority and costs an administration very little. 2. The registry The registry is maintained in the repository that also hosts this document, and published as a searchable page with JSON and CSV exports [REGISTRY]. It follows the contribution model of the SPACERG research infrastructure registry described in [I-D.sastry-spacerg-space-research-infra-typology]: one machine- readable record per entry, added and corrected by pull request, validated automatically on submission. 2.1. One record, one authorisation A record describes one authorisation. Where an operator holds several authorisations for successive generations of a system, each gets its own record, anchored on its own filing reference, so a reader checking a number has exactly one document to open. Modifications, amendments, waivers and partial grants acting on that same authorisation become dated events inside the record. A family identifier lets a reader roll several records up to the operator level, without the data model having to claim that one licence equals one company. Some systems have no public filing at all, constellations procured under classified government contracts being the obvious case. Those records carry a written statement of why no filing reference exists. An empty field would say the same thing far less usefully. 2.2. Evidence grading Every field that asserts a fact points to a source. Every source carries a grade, and that grade follows from the kind of document it is. Contributors do not choose it. Fraire & York Expires 7 February 2027 [Page 4] Internet-Draft Constellation Registry August 2026 Primary sources are the filing itself or the regulator's own act: ITU records and publications, national regulator orders, applications and dockets, and operator technical documentation submitted to a regulator. Secondary sources are everything else, including operators' own web pages and press releases, trade press, tracker sites, encyclopaedias and conference presentations. Secondary sources are permitted, and for some jurisdictions they are all that exists. What they may not do is stand in for a filing that exists and simply has not been read. Where a primary source exists and nobody has consulted it, the record says so, so the gap stays visible and someone can close it later. The failure mode this guards against is ordinary, and almost invisible once it has happened. A figure originating in a press release is quoted by a tracker, the tracker is cited by an encyclopaedia, the encyclopaedia is cited by a paper, and the number arrives in the literature indistinguishable from one that was authorised. 2.3. Regulatory commitment as a ladder Each record sits at the strongest rung of regulatory commitment it has demonstrably reached: satellites in orbit; authorisation by a national regulator; an application pending before one; notification to the ITU; an ITU coordination request; ITU advance publication; and a public announcement with no filing identified. The ladder is what makes an aggregate safe to publish. Totals are given per rung, and the shape of that distribution usually says more than the sum does. 2.4. Orbital geometry Where a system's orbital geometry is known, each shell is recorded with the parameters given in the filing, together with the notation defined in [I-D.piraux-space-constellation-code] where the geometry can be expressed in it. Each code also records how much of it came from the cited source and what was assumed, so a consumer gets the value and the grounds for it together. Applying that notation to real filings turned out to be informative in both directions. Several classes of authorised geometry cannot be expressed in it: orbital parameters given as ranges or as envelopes instead of fixed values; elliptical orbits with station-keeping tolerances; shells whose satellite count is not divisible by their plane count; distinct plane groups sharing an altitude and inclination; and orbits whose defining property is a sun-synchronous Fraire & York Expires 7 February 2027 [Page 5] Internet-Draft Constellation Registry August 2026 local time, a repeating ground track, or formation flying. Those cases are flagged as unrepresentable. Forcing them into a code would only misdescribe them. 2.5. Point-in-time observations Registry entries are observations at a date. Regulatory states move, applications are granted in part or deferred, licences are modified, ITU filings are suppressed, and operators are acquired. Each record therefore carries a last-verified date. A record nobody has re- checked in a long time is flagged, so that staleness shows on the page instead of being quietly trusted. Corrections are as welcome as additions. The most valuable contribution is a provenance upgrade: taking a record that rests on secondary reporting, reading the filing it refers to, and replacing the source. 2.6. Scope The registry covers constellations providing Internet access or Internet-related services, including orbital data centres. Systems flown for imaging, remote sensing, navigation, or purely as sensor networks are outside its scope, although general satellite trackers include them. Totals from this registry therefore will not match a general tracker's totals, which is why the scope statement is published alongside them. 3. Relationship to other SPACERG work This registry is complementary to the research infrastructure typology and registry of [I-D.sastry-spacerg-space-research-infra-typology]. That work catalogues what researchers can experiment with; this one catalogues what is being built and what has been claimed. The two share a contribution model, a validation approach and the publication mechanics, and they are meant to be used together. The orbital geometry recorded here is expressed, where possible, in the notation of [I-D.piraux-space-constellation-code], so that entries can be consumed directly by tooling that accepts it. Fraire & York Expires 7 February 2027 [Page 6] Internet-Draft Constellation Registry August 2026 4. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 5. Security Considerations This document describes a registry of public information about satellite systems and introduces no protocol mechanisms. Records are compiled from public regulatory filings and public reporting. 6. IANA Considerations This document has no IANA actions. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 7.2. Informative References [I-D.piraux-space-constellation-code] Piraux, M. and J. A. Fraire, "A code to describe satellite constellations", Work in Progress, Internet-Draft, draft- piraux-space-constellation-code-02, 6 July 2026, . [I-D.sastry-spacerg-space-research-infra-typology] Sastry, N. and J. A. Fraire, "A typology of Space Research Infrastructures", Work in Progress, Internet-Draft, draft- sastry-spacerg-space-research-infra-typology-00, 19 July 2026, . Fraire & York Expires 7 February 2027 [Page 7] Internet-Draft Constellation Registry August 2026 [REGISTRY] "SPACERG Satellite Constellation Registry", 2026, . Acknowledgments This registry grew out of a survey of announced and filed constellations presented to the SPACE Research Group at IETF 126 in Vienna, and the discussion that followed it. The initial data set was compiled with the assistance of an AI coding assistant, working under the direction of the maintainers. The registry's provenance and validation rules are partly a response to that fact: every claim resolves to a declared source, grades are fixed by document type, and the automated checks reject any record that breaks either rule. The repository documents this in full. TODO: acknowledge IETF 126 discussion participants by name once confirmed. Authors' Addresses Juan A. Fraire Inria Email: juan.fraire@inria.fr Dan York Internet Society Email: york@isoc.org Fraire & York Expires 7 February 2027 [Page 8]