Summary

  • A current individual draft proposes an IANA registry of celestial bodies, but its author has accepted a public challenge that astronomical naming should remain with the IAU and Minor Planet Center.
  • The correction reveals a deeper design rule: astronomical identity, stable network identifier, address allocation, route state and delivered result require separate authorities and evidence.
  • TIPTOP can coordinate a small versioned crosswalk without turning a human-readable name, a draft or a registry row into routing or mission truth.

The argument began with a five-page Internet-Draft. Revision 01 of Defining a Celestial Bodies Registry for Deep Space Internet Addressing proposes a Celestial Body Identifier, official IAU name, body type and parent body in an IANA registry. It describes that registry as a single authoritative source for a taxonomy used by hierarchical deep-space addressing.

That is a proposal, not an IETF decision. The Datatracker record identifies an individual submission intended as Informational. The TIPTOP charter covers IP architecture, QUIC and security profiles, and DNS considerations for long-delay, disrupted space networks. It does not place this draft in the Working Group or create an IANA registry.

The public review improved the boundary before any such step. Erik Kline asked whether IANA needed to do this at all and pointed to RFC 9179. Its YANG location model already defines astronomical-body as a string named by the International Astronomical Union. The draft author agreed: IANA should not carry a taxonomic burden that another authority already carries, and a future revision should remove the unnecessary overhead.

The next messages made the apparent simplification more precise. Marshall Eubanks added the Minor Planet Center and described several stages in the life of a minor body's identity: discovery tag, provisional designation, permanent number and approved name. On 7 September, the author said he would use the IAU-and-MPC framework in revision 02. Revision 02 is an intention in a mailing-list message, not yet a source document.

Naming authority is not one database field

The IAU account of astronomical naming explains that different categories follow different processes. The Minor Planet Center's designation guide shows why a provisional designation is structured identification, not a permanent popular name.

A new observation can be uncertain. Several observations can later prove to be one body. A provisional designation can persist. A permanent number can precede a name. A name can contain punctuation that is harmless in astronomy and troublesome in software. Classification can change without the physical object moving; a human-facing name can change without creating a new object.

These are not defects to be erased by a networking registry. They are lineage. A network crosswalk must preserve the issuing authority, designation state, aliases, effective interval and supersession link. If it copies only the latest display name, a rename looks like a new destination. If it treats every provisional label as permanent, later linkage can leave two network identities for one object.

RFC 9179 solves a narrower problem. A coordinate needs a reference frame, and the astronomical-body value says which body gives those coordinates meaning. The field defaults to Earth and refers naming to the IAU. It does not allocate an IP prefix. It does not authenticate an endpoint on that body. It does not prove a route exists.

A registry policy cannot inherit someone else's authority

Revision 01 proposes Expert Review. RFC 8126 defines that registration policy: a designated expert evaluates requests using documented criteria. The label is a governance mechanism, not a source of astronomical truth. An IANA expert can check that a networking entry cites the right external record. The expert cannot make an observation real, merge aliases on behalf of the MPC or confer an IAU name.

The correct design is therefore a cross-authority mapping, not a copied celestial catalogue. One field identifies the astronomical authority and its durable record. Another carries a networking identifier whose stability rules are defined by the networking specification. Further records allocate addresses, bind them to an operator or mission and record an effective epoch.

The separation matters when facts move at different speeds. A minor body's orbit can be refined while its network identifier stays stable. A network prefix can be retired while its astronomical name remains valid. A mission endpoint can change keys without the target body changing. A cached mapping can be authentic but stale.

A destination label still stops before delivery

Hierarchical aggregation is a routing technique. It can reduce table size by collecting reachable space beneath a common prefix. It does not decide who may allocate that prefix, which system advertised it, whether the path is current or what lies at its end.

The evidence chain must continue. Record the mapping version and external astronomical reference. Record the allocation authority, holder, prefix, valid interval and transfer history. Record the origin that advertises the route, the validation state and the path actually selected. Authenticate the endpoint and mission role separately. Finally, observe receipt, application commit and mission outcome.

This is the practical force of Heng Lu's reality-layer discipline. A name, registry projection, allocation, routing-table entry, running implementation and delivered command are related facts. None acquires the authority of the next layer merely by being upstream.

Minimum Initial Specification points toward a modest common object: enough fields to join authoritative astronomical identity to a stable network identifier, while leaving address policy and operational choices to accountable actors. Running-Code Primacy supplies the last constraint. A beautiful registry row is not a route, and a route is not a delivered result.

The mailing-list correction is therefore valuable before the code exists. It removes a duplicate claim of authority and exposes the joins the real design must make explicit. Deep-space distance makes recovery slow. That is a reason to preserve provenance, not a reason to let one memorable celestial name carry every decision.

Sources

  1. Datatracker — celestial-bodies registry draft
  2. TIPTOP charter
  3. Heng Lu — Minimum Initial Specification
  4. Heng Lu — On Reality Layers
  5. Heng Lu — Running-Code Primacy
  6. IAU — Naming Astronomical Objects
  7. Erik Kline — existing IAU reference
  8. Alejandro Acosta — remove unnecessary IANA overhead
  9. Marshall Eubanks — IAU/MPC designation stages
  10. Alejandro Acosta — notes for revision 02
  11. Individual Internet-Draft revision 01
  12. Minor Planet Center — designation conventions
  13. RFC 8126 — IANA registration policies
  14. RFC 9179 — astronomical-body reference frame