]>

Marc.Blanchet@viagenie.ca

General Internet Engineering Task Force RDAP DTN Space 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.

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 has setup registres 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 , are herein inherited.

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 when, and only when, they appear in all capitals, as shown here.

Queries This section is inspired and somewhat supplements 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 "https://examplespacerdapserver.org/rdap" as the URL prefix before the specified query path segment.

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. Examples:

• https://examplespacerdapserver.org/rdap/space/oid/1.3.112.4.7.84 returns the data for the NASA Mars Reconnaissance Orbiter spacecraft.
• https://examplespacerdapserver.org/rdap/space/oid/1.3.112.4.34.1 returns the data for a range of Bundle Protocol Node numbers belonging to NASA Goddard.

CBHE Node Numbers Path Segment Syntax: space/cbhe/<number-range> Bundle protocol CBHE node numbers are specified by a range of two unsigned integers separated by '-'. In case of a single node number, only the number is specified. Examples:

• https://examplespacerdapserver.org/rdap/space/cbhe/100-256 returns the data for this range.
• https://examplespacerdapserver.org/rdap/space/cbhe/45623 returns the data for this specific node.

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

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 except noted.

ObjectClassName: entity Use JSContact instead of jCard as in RFC9083

Node Id

ObjectClassName: serviceSite { "objectClassName": "serviceSite", "OID": "1.3.112.4.9.76", "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": "1.3.112.4.2.222", "Affiliation": "1.3.112.4.1.37", "Apertures": [ "1.3.112.4.9.76.1", "1.3.112.4.9.76.2", "1.3.112.4.9.76.3" ], "Owner": "1.3.112.4.1.37", "CreatedBy": "1.3.112.4.2.2", "Creation date": "2018-11-01T14:21:19.891375+00:00", "UpdatedBy": "1.3.112.4.2.2", "Update date": "2018-11-01T15:00:00.255626+00:00" } TBD: explain the syntax of all properties

Aperture { "OID": "1.3.112.4.9.76.3", "Name": "SDA5", "Aliases": [], "Forward Links": [], "Return Links": [ "1.3.112.4.9.76.3.1" ], "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": "1.3.112.4.2.2", "Creation date": "2018-11-01T14:58:33+00:00", "Updated By": "1.3.112.4.2.2", "Update date": "2018-11-01T17:54:58.889530+00:00" } TBD: explain the syntax of all properties

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.

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

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: ["1.3.112.4"], ["https://rdap.sanaregistry.org/"]

IANA Considerations TBD

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.

References Normative References Informative References SANA CCSDS

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