Internet-Draft Abbreviated Title October 2022
Blanchet Expires 27 April 2023 [Page]
Internet Engineering Task Force
Intended Status:
Standards Track
MB. Blanchet

RDAP Query and Response for Space Objects and Networks


Objects and networks in space are owned by entities, have locations and have identity or network address. This document describes Registration Data Access Protocol(RDAP) queries and response for these space objects and networks.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

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

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 27 April 2023.

Table of Contents

1. Introduction

Objects and networks in space are owned by entities, have locations and have identity or network address. The space community through the Consultative Committee for Space Data Systems[ccsds] has setup registres[sana] and its related policies. These registries are managed by the Space Assigned Numbers Authority (SANA) that documents those properties for space objects and networks. Instead of reinventing another access protocol for registration data access, this document extends the Internet Registration Data Access Protocol(RDAP) (STD95) used for domain names, IP addresses and AS numbers by defining new queries and responses for the space objects and networks.

Except if explicitly specified or not relevant, all considerations of [RFC9082], [RFC9083] are herein inherited.

1.1. Requirements Language

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.

2. Queries

This section is inspired and somewhat supplements [RFC9082] by adding new queries.

In order to avoid any future name collision when an RDAP server may be answering both Internet domain names and IP addresses queries as well as this specification queries, the "space" keyword is prefixed in the path for the queries in this specification.

Examples in this section use "" as the URL prefix before the specified query path segment.

2.1. OID Path Segment

Syntax: space/oid/<oid>

Space objects, assets, organizations and networks are managed using unique identifiers based on the ISO Object Identifier hierarchy (OID). Therefore, any object may be queried using its OID. The OID must be provided from the ISO root. The OID is specified in its native form, which is number.number.number.number ... Response format for each kind of object is specified in the Response section in this document.


2.2. CBHE Node Numbers Path Segment

Syntax: space/cbhe/<number-range>

Bundle protocol CBHE node numbers[RFC5050] are specified by a range of two unsigned integers separated by '-'. In case of a single node number, only the number is specified.


2.3. Others TBD: assets, service sites, ...


3. JSON Responses

As JSON is liberal for adding new properties that receivers should ignore when they are unknown, it is forseen that some space RDAP registries may add more properties in their response than those specified in this document.

This section inherits all considerations of [RFC9083] except noted.

3.1. ObjectClassName: entity

Use JSContact instead of jCard as in RFC9083

3.2. Node Id

3.3. ObjectClassName: serviceSite

  "objectClassName": "serviceSite",
  "OID": "",
  "Name": "Svalbard",
  "Abbreviation": "SVLBRD",
  "Aliases": [],
  "Location Type": "Surface",
  "Planetary Body": "Earth",
  "Country": "Norway",
  "City": "Svalbard",
  "Latitude": "-02.996090",
  "Longitude": "+040.194663",
  "Elevation": 456.01,
  "Trajectory": null,
  "Orbit": null,
  "Spacecraft": null,
  "Requestor": "",
  "Affiliation": "",
  "Apertures": [
  "Owner": "",
  "CreatedBy": "",
  "Creation date": "2018-11-01T14:21:19.891375+00:00",
  "UpdatedBy": "",
  "Update date": "2018-11-01T15:00:00.255626+00:00"

TBD: explain the syntax of all properties

3.4. Aperture

    "OID": "",
    "Name": "SDA5",
    "Aliases": [],
    "Forward Links": [],
    "Return Links": [
    "Location Type": "Surface",
    "Planetary Body": "Earth",
    "Latitude": "+781339.72",
    "Longitude": "+0152531.8",
    "Elevation": 460.68,
    "Diameter": null,
    "Aperture Type": null,
    "Pointing Constraints": [],
    "Available Services": [],
    "Created By": "",
    "Creation date": "2018-11-01T14:58:33+00:00",
    "Updated By": "",
    "Update date": "2018-11-01T17:54:58.889530+00:00"

TBD: explain the syntax of all properties

4. Transport

This document assumes that queries about space objects and networks are done on the regular Internet to servers located on Earth, therefore the transport of such queries would use the same transport as specified by standard RDAP queries for domain names or IP addresses. It should be possible to carry those queries in space over an appropriate transport, such as DTN. However, this specification does not describe such transport.

5. Finding Authoritative Servers

The space community runs a service similar (and in fact inspired by) to IANA, named Space Assigned Numbers Authority (SANA) [sana]. Similar to [RFC9224], this document specifies the bootstrap registry located at IANA with initial values.

5.1. OID Bootstrap Registry

IANA will setup a new bootstrap registry for OIDs. The keys are the root of the OID subtree delegated to a specific RDAP server. The registry will be initially populated with a single entry: [""], [""]

6. IANA Considerations


7. Security Considerations

All security considerations of STD95 are herein inherited. While space assets and objects may have higher security risks than Earth equivalents, nothing in this specification add more security risks as the information of such assets is public. As with Internet RDAP, some information may be redacted (see TODO: internet draft redacted) when confidentiality is required. Moreover, authentication and authorization mechanisms such as TODO: openid-draft may be used to access more confidential data.

8. References

8.1. Normative References

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <>.
Hollenbeck, S. and A. Newton, "Registration Data Access Protocol (RDAP) Query Format", STD 95, RFC 9082, DOI 10.17487/RFC9082, , <>.
Hollenbeck, S. and A. Newton, "JSON Responses for the Registration Data Access Protocol (RDAP)", STD 95, RFC 9083, DOI 10.17487/RFC9083, , <>.
Blanchet, M., "Finding the Authoritative Registration Data Access Protocol (RDAP) Service", STD 95, RFC 9224, DOI 10.17487/RFC9224, , <>.
Scott, K. and S. Burleigh, "Bundle Protocol Specification", RFC 5050, DOI 10.17487/RFC5050, , <>.

8.2. Informative References

SANA, "Space Assigned Numbers Authority (SANA)", <>.
CCSDS, "Consultative Committee on Space Data Systems (CCSDS)", <>.


This work is based on a discussion with Peter Shames of Jet Propulsion Laboratory on how to provide information of space objects and networks.

Author's Address

Marc Blanchet