<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc [
  <!ENTITY     nbsp    "&#160;">
  <!ENTITY     zwsp    "&#8203;">
  <!ENTITY     nbhy    "&#8209;">
  <!ENTITY     wj      "&#8288;">
]>
<rfc xmlns:xsi="http://w3.org" 
     docName="draft-acosta-deepspace-celestial-bodies-registry-02" 
     category="info" 
     ipr="trust200902" 
     submissionType="IETF" 
     xml:lang="en" 
     version="3">
  <front>
    <title abbrev="Celestial Bodies Reference Framework">Defining a Celestial Bodies Reference Framework for Deep Space Internet Addressing</title>
    <seriesInfo name="Internet-Draft" value="draft-acosta-deepspace-celestial-bodies-registry-02"/>
    <author fullname="Alejandro Acosta" initials="A." surname="Acosta">
      <organization>LACNIC</organization>
      <address>
        <email>alejandro@lacnic.net</email>
      </address>
    </author>
    <date year="2026" month="09" day="08"/>
    <area>Internet</area>
    <workgroup>Taking IP to Other Planets</workgroup>
    <keyword>Deepspace</keyword>
    <keyword>TIPTOP</keyword>
    <keyword>IAU</keyword>
    <keyword>MPC</keyword>
    <abstract>
      <t>This document highlights the architectural requirement within Deepspace/TIPTOP protocols to utilize an external, standardized reference framework for celestial objects, functioning as an equivalent to ISO 3166 for interplanetary networking. To avoid operational overhead and duplication of effort, this framework defers the definitions, naming, and tracking of celestial entities directly to the International Astronomical Union (IAU) and the Minor Planet Center (MPC). This document outlines how these external identifiers guide hierarchical address allocation without requiring IANA to maintain a dedicated astronomical nomenclature registry. The ultimate objective is to establish a clear definition of what constitutes a valid Celestial Body for networking purposes.</t>
    </abstract>
  </front>
  <middle>
    <section>
      <name>Introduction</name>
      <t>Recent architectural discussions within the IETF Taking IP to Other Planets (TIPTOP) working group emphasize that deep space networking protocols require a stable reference framework based on celestial topographies.</t>
      <t>To achieve multi-agency interoperability, deep space networks require a universally recognized taxonomy for celestial objects, serving a purpose analogous to ISO 3166 country codes on Earth. However, neither the IETF nor IANA should bear the operational burden of defining, naming, or cataloging celestial bodies.</t>
      <t>Rather than creating a new standalone registry from scratch, this document establishes that deep space networking protocols MUST defer to the authoritative entities already managing these spaces: the International Astronomical Union (IAU) for major bodies and approved names, and the Minor Planet Center (MPC) for provisional designations and minor body tracking.</t>
    </section>
    <section>
      <name>Requirements Language</name>
      <t>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.</t>
    </section>
    <section>
      <name>Terminology</name>
      <dl>
        <dt>IAU:</dt>
        <dd>International Astronomical Union.</dd>
        <dt>MPC:</dt>
        <dd>Minor Planet Center (hosted at the Harvard-Smithsonian Center for Astrophysics).</dd>
        <dt>Provisional Designation:</dt>
        <dd>The temporary identifier assigned to a celestial body by the MPC upon discovery.</dd>
      </dl>
    </section>
    <section>
      <name>Core Framework and Reference Policy</name>
      <t>Deep space addressing plans requiring celestial identification MUST utilize the data models and standardized outputs managed by the IAU and the MPC.</t>
      <t>Major Planets and Satellites: Addressing protocols SHALL map identifiers to the definitive nomenclatures established by the IAU.</t>
      <t>Minor Planets, Asteroids, and Comets: Protocols requiring allocation for minor or newly discovered bodies SHALL leverage the serial numbers and provisional designations assigned by the MPC.</t>
      <t>By deferring to both bodies, the network architecture accommodates the complete operational lifecycle of a celestial target—from its initial provisional tracking code to its permanent astronomical designation.</t>
      <t>The goal of this document is exactly what happened back with RFC 1591 where in section 4 point 2, the author (Jon Postel) mentions:</t>
      <blockquote>
        <t>The IANA is not in the business of deciding what is and what is not a country. The selection of the ISO 3166 list as a basis for country code top-level domain names was made with the knowledge that ISO has a procedure for determining which entities should be and should not be on that list.</t>
      </blockquote>
      <t>In the same way we could say:</t>
      <blockquote>
        <t>The IANA is not in the business of deciding what is and what is not a celestial body. The selection of IAU and MPC lists as a basis for celestial body names was made with the knowledge that those entities have a procedure for determining which entities should be and should not be on those lists.</t>
      </blockquote>
    </section>
    <section>
      <name>IANA Considerations</name>
      <t>This document requires no immediate or active registration actions from IANA.</t>
    </section>
    <section>
      <name>Security Considerations</name>
      <t>This document does not define any protocol architecture, data models, or operational mechanisms. However, establishing a strict taxonomic baseline introduces significant security and operational benefits.</t>
      <t>Specifically, referencing external authoritative lists (IAU and MPC) prevents a class of operational exploits where malicious or erroneous actors could request networking prefixes or resources for non-existent celestial bodies. Defining strictly what constitutes a valid celestial entity ensures resource integrity and prevents spatial address space pollution or exhaustion.</t>
      <t>Consequently, this document introduces no new security or privacy vulnerabilities to network infrastructures.</t>
    </section>
    <section>
      <name>Acknowledgments</name>
      <t>The author would like to thank Erik Kline for his critical structural feedback regarding IANA overhead, and Marshall Eubanks for providing the necessary astronomical context regarding the Minor Planet Center (MPC) and celestial body naming lifecycles. Their insights directly shaped the reference framework proposed in this document.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>Normative References</name>
      <reference anchor="RFC2119" target="https://rfc-editor.org">
        <front>
          <title>Key words for use in RFCs to Indicate Requirement Levels</title>
          <author initials="S." surname="Bradner"/>
          <date month="March" year="1997"/>
        </front>
        <seriesInfo name="RFC" value="2119"/>
      </reference>
      <reference anchor="RFC8174" target="https://rfc-editor.org">
        <front>
          <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
          <author initials="B." surname="Leiba"/>
          <date month="May" year="2017"/>
        </front>
        <seriesInfo name="RFC" value="8174"/>
      </reference>
      <reference anchor="RFC8126" target="https://rfc-editor.org">
        <front>
          <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
          <author initials="M." surname="Cotton"/>
          <author initials="B." surname="Leiba"/>
          <author initials="T." surname="Narten"/>
          <date month="June" year="2017"/>
        </front>
        <seriesInfo name="RFC" value="8126"/>
      </reference>
    </references>
  </back>
</rfc>

