| Internet-Draft | Abbreviated Title | October 2022 |
| Blanchet | Expires 27 April 2023 | [Page] |
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.¶
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 https://datatracker.ietf.org/drafts/current/.¶
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.¶
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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.¶
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.¶
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 "https://examplespacerdapserver.org/rdap" as the URL prefix before the specified query 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:¶
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.¶
Examples:¶
TBD¶
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.¶
Use JSContact instead of jCard as in RFC9083¶
{
"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¶
{
"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¶
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.¶
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.¶
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/"]¶
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.¶
This work is based on a discussion with Peter Shames of Jet Propulsion Laboratory on how to provide information of space objects and networks.¶