<?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-04" 
     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-04"/>
    
    <author fullname="Alejandro Acosta" initials="A." surname="Acosta">
      <organization>LACNIC</organization>
      <address>
        <email>alejandro@lacnic.net</email>
      </address>
    </author>

    <author fullname="Marshall Eubanks" initials="M." surname="Eubanks">
      <organization>Space Initiatives Inc.</organization>
      <address>
        <email>tme@space-initiatives.com</email>
      </address>
    </author>

    <date year="2026" month="10" day="24"/>
    <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 operational framework 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. From a resource-management perspective, this framework remains identical regardless of whether the target location hosts human colonies, scientific equipment, or autonomous robotic assets; any entity requiring internet and communication access must rely on a stable celestial anchor.</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 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>
        <dt>Permanent Designation:</dt>
        <dd>A unique number given to minor planets, periodic comets, planetary satellites and interstellar objects by the MPC once their orbit is confirmed.</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. Implementers and protocol builders SHALL query the official IAU Gazetteer of Planetary Nomenclature tables (available at https://usgs.gov) to resolve major celestial bodies.</t>
      <t>Minor Planets, Asteroids, and Comets: Protocols requiring allocation for minor or newly discovered bodies SHALL leverage the permanent designations and provisional designations assigned by the MPC. Implementers SHALL reference the official Minor Planet Center database query endpoints (available at https://minorplanetcenter.net) to resolve minor planet parameters and track their operational lifecycles.</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. Special thanks go to S Moonesamy for his precise editorial review and structural recommendations on the mailing list, and to Ran Atkinson for his valuable steering regarding planetary topographies and autonomous robotic asset scenarios. 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>
    </references>
    <references>
      <name>Informative References</name>
      <reference anchor="RFC1591" target="https://rfc-editor.org">
        <front>
          <title>Domain Name System Structure and Delegation</title>
          <author initials="J." surname="Postel"/>
          <date month="March" year="1994"/>
        </front>
        <seriesInfo name="RFC" value="1591"/>
      </reference>
      <reference anchor="MPC-Packed" target="https://minorplanetcenter.net">
        <front>
          <title>Packed Provisional and Permanent Designations</title>
          <author>
            <organization>Minor Planet Center</organization>
          </author>
          <date/>
        </front>
      </reference>
    </references>
  </back>
</rfc>

