| Internet-Draft | rdap-geofeed | April 2024 |
| Singh & Harrison | Expires 21 October 2024 | [Page] |
This document defines a new Registration Data Access Protocol (RDAP) extension, "geofeed1", for indicating that an RDAP server hosts geofeed URLs for its IP network objects. It also defines a new media type and link relation type for the associated link objects included in responses.¶
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 21 October 2024.¶
Copyright (c) 2024 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.¶
[RFC8805] and [I-D.ietf-opsawg-9092-update] (obsoletes [RFC9092]) detail the IP geolocation feed (commonly known as 'geofeed') file format and associated access mechanisms. This document specifies how geofeed URLs can be accessed through RDAP. It defines a new RDAP extension, "geofeed1", for indicating that an RDAP server hosts geofeed URLs for its IP networks, as well as a media type and a link relation type for the associated link objects.¶
The keywords "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.¶
Indentation and whitespace in examples are provided only to illustrate element relationships, and are not a REQUIRED feature of this protocol.¶
"..." in examples is used as shorthand for elements defined outside of this document.¶
[I-D.ietf-opsawg-9092-update] requires a geofeed file to be a UTF-8 [RFC3629] comma-separated values (CSV) file, with a series of "#" comments at the end for the optional Resource Public Key Infrastructure (RPKI, [RFC6480]) signature. At first glance, the "text/csv" media type (Section 4 of [I-D.shafranovich-rfc4180-bis]) seems like a good candidate for a geofeed file, since it supports the "#" comments needed for including the RPKI signature.¶
However, although the CSV geofeed data could be viewed directly by a user such that the "text/csv" media type was appropriate, the most common use case will involve it being processed by some sort of application first, in order to facilitate subsequent address lookup operations. Therefore, using a new "application" media type with a "geofeed" subtype (Section 4.2.5 of [RFC6838]) for the geofeed data is preferable to using "text/csv".¶
To that end, this document registers a new "application/geofeed+csv" media type in the IANA Media Types Registry (see Section 5.3), and a new "+csv" suffix in the IANA Structured Syntax Suffixes Registry (see Section 5.4).¶
An RDAP server that hosts geofeed URLs for its IP network objects (Section 5.4 of [RFC9083]) may include link objects for those geofeed URLs in IP network objects in its responses. These link objects are added to the "links" member of each object (Section 4.2 of [RFC9083]).¶
In RDAP, the "value", "rel", and "href" JSON members are REQUIRED for any link object. Additionally, for a geofeed link object, the "type" JSON member is RECOMMENDED. The geofeed-specific components of a link object are like so:¶
An IP network object returned by an RDAP server may contain zero, one, or multiple geofeed link objects. An example scenario where more than one geofeed link object would be returned is where the server is able to represent that data in multiple languages (see the "hreflang" member of the link object).¶
An RDAP server that returns geofeed link objects in accordance with this specification is RECOMMENDED to include the "geofeed1" extension identifier in the "rdapConformance" array for any lookup or search response containing an IP network object, as well as in the help response. Here is an elided example for this inclusion:¶
{
"rdapConformance": [ "rdap_level_0", "geofeed1", ... ],
...
}
¶
Extension identifier inclusion is not mandatory, because RDAP does not require that an extension identifier be included in responses merely to make use of new media types or link relation types. An RDAP server that includes the "geofeed1" identifier is signalling to clients that it hosts geofeed URLs and will return those URLs in accordance with this specification where they are available. The main benefit of including the identifier is that it permits a client to determine that a server does host geofeed URLs, which is useful where a client receives an IP network object without a geofeed URL, for example.¶
Although a server may use registered media types in its link objects without any restrictions, it may be useful to define new RDAP extensions for those media types in order for the server to communicate to clients that it will make data for that type accessible, in the same way that the server does with the "geofeed1" extension identifier.¶
The following is an elided example of an IP network object with a geofeed link object:¶
{
"objectClassName": "ip network",
"handle": "XXXX-RIR",
"startAddress": "2001:db8::",
"endAddress": "2001:db8:0:ffff:ffff:ffff:ffff:ffff",
"ipVersion": "v6",
"name": "NET-RTR-1",
"type": "DIRECT ALLOCATION",
"country": "AU",
"parentHandle": "YYYY-RIR",
"status": [ "active" ],
"links":
[
{
"value": "https://example.net/ip/2001:db8::/48",
"rel": "self",
"href": "https://example.net/ip/2001:db8::/48",
"type": "application/rdap+json"
},
{
"value": "https://example.net/ip/2001:db8::/48",
"rel": "geo",
"href": "https://example.com/geofeed",
"type": "application/geofeed+csv"
},
...
],
...
}
¶
When including a geofeed file URL in an IP Network object, an RDAP server operator SHOULD follow the guidance from Section 7 of [I-D.ietf-opsawg-9092-update] to not accidentally expose the location of an individual.¶
Many jurisdictions have laws or regulations that restrict the use of "personal data", per the definition in [RFC6973]. Given that, registry operators should ascertain whether the regulatory environment in which they operate permits implementation of the functionality defined in this document.¶
[I-D.ietf-opsawg-9092-update] requires an HTTPS URL for a geofeed file. The geofeed file may also contain an RPKI signature. Besides that, this document does not introduce any new security considerations past those already discussed in the RDAP protocol specifications.¶
IANA is requested to register the following value in the RDAP Extensions Registry at https://www.iana.org/assignments/rdap-extensions/:¶
IANA is requested to register the following value in the Link Relations Registry at https://www.iana.org/assignments/link-relations/:¶
IANA is requested to register the following value in the Media Types Registry at https://www.iana.org/assignments/media-types/:¶
IANA is requested to register the following value in the Structured Syntax Suffixes Registry at https://www.iana.org/assignments/media-type-structured-suffix/:¶
The syntax and semantics of fragment identifiers specified for +csv SHOULD be as specified for "text/csv".¶
The syntax and semantics for fragment identifiers for a specific "xxx/yyy+csv" SHOULD be processed as follows:¶
For cases defined in +csv, where the fragment identifier resolves per the +csv rules, then as specified in +csv.¶
For cases defined in +csv, where the fragment identifier does not resolve per the +csv rules, then as specified in "xxx/yyy+csv".¶
For cases not defined in +csv, then as specified in "xxx/yyy+csv".¶
Mark Kosters provided initial support and encouragement for this work, along with the [RFC9092] authors. Gavin Brown suggested using a web link instead of a simple URL string to specify a geofeed file URL. Andy Newton, James Gould, and Scott Hollenbeck also provided valuable feedback for this document.¶