An RDAP Extension for Geofeed Data
draft-ietf-regext-rdap-geofeed-08
| Document | Type | Active Internet-Draft (regext WG) | |
|---|---|---|---|
| Authors | Jasdip Singh , Tom Harrison | ||
| Last updated | 2024-12-02 (Latest revision 2024-10-18) | ||
| Replaces | draft-jasdips-regext-rdap-geofeed | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | Proposed Standard | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | Submitted to IESG for Publication | |
| Associated WG milestone |
|
||
| Document shepherd | Gavin Brown | ||
| Shepherd write-up | Show Last changed 2024-11-26 | ||
| IESG | IESG state | Publication Requested | |
| Action Holder | |||
| Consensus boilerplate | Yes | ||
| Telechat date | (None) | ||
| Responsible AD | Orie Steele | ||
| Send notices to | gavin.brown@icann.org |
draft-ietf-regext-rdap-geofeed-08
Registration Protocols Extensions (regext) J. Singh
Internet-Draft ARIN
Intended status: Standards Track T. Harrison
Expires: 21 April 2025 APNIC
18 October 2024
An RDAP Extension for Geofeed Data
draft-ietf-regext-rdap-geofeed-08
Abstract
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.
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 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 April 2025.
Copyright Notice
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.
Singh & Harrison Expires 21 April 2025 [Page 1]
Internet-Draft rdap-geofeed October 2024
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Specification . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Media Type for a Geofeed Link . . . . . . . . . . . . . . 3
2.2. Geofeed Link . . . . . . . . . . . . . . . . . . . . . . 3
2.3. Extension Identifier . . . . . . . . . . . . . . . . . . 4
2.4. Example . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Operational Considerations . . . . . . . . . . . . . . . . . 6
4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6.1. RDAP Extensions Registry . . . . . . . . . . . . . . . . 7
6.2. Link Relations Registry . . . . . . . . . . . . . . . . . 7
6.3. Media Types Registry . . . . . . . . . . . . . . . . . . 7
6.4. Structured Syntax Suffixes Registry . . . . . . . . . . . 8
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 9
7.1. RIPE NCC . . . . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
9. Change History . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Changes from 00 to 01 . . . . . . . . . . . . . . . . . . 10
9.2. Changes from 01 to 02 . . . . . . . . . . . . . . . . . . 10
9.3. Changes from 02 to 03 . . . . . . . . . . . . . . . . . . 10
9.4. Changes from 03 to 04 . . . . . . . . . . . . . . . . . . 10
9.5. Changes from 04 to 05 . . . . . . . . . . . . . . . . . . 10
9.6. Changes from 05 to 06 . . . . . . . . . . . . . . . . . . 10
9.7. Changes from 06 to 07 . . . . . . . . . . . . . . . . . . 11
9.8. Changes from 07 to 08 . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
[RFC8805] and [RFC9632] 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 network objects, as
well as a media type and a link relation type for the associated link
objects.
Singh & Harrison Expires 21 April 2025 [Page 2]
Internet-Draft rdap-geofeed October 2024
1.1. Requirements Language
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
[BCP14] 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.
2. Specification
2.1. Media Type for a Geofeed Link
[RFC9632] 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 6.3), and a
new "+csv" suffix in the IANA Structured Syntax Suffixes Registry
(see Section 6.4).
2.2. Geofeed Link
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]).
Singh & Harrison Expires 21 April 2025 [Page 3]
Internet-Draft rdap-geofeed October 2024
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:
* "rel" -- The link relation type is set to "geo". This is a new
link relation type for geographical data, registered in the IANA
Link Relations Registry (see Section 6.2) by this document.
* "href" -- The target URL is set to the HTTPS URL of the geofeed
file for an IP network.
* "type" -- "application/geofeed+csv" (see Section 2.1).
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 a link object).
2.3. Extension Identifier
This document defines a new extension identifier, "geofeed1", for use
by servers that host geofeed URLs for their IP network objects and
include geofeed URL link objects in their responses to clients in
accordance with Section 2.2. A server that uses this extension
identifier MUST include it 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", ... ],
...
}
An RDAP server may make use of the "application/geofeed+csv" media
type and the "geo" link relation defined in this specification in its
responses without including the "geofeed1" extension identifier in
those responses, because RDAP servers are free to use any registered
media type or link relation in a standard response (without
implementing any particular extension). The additional value of the
extension identifier here is that it signals to the client that the
server hosts geofeed URLs for its IP network objects. This is useful
where a client receives an IP network object without a geofeed link
object, because in that case the client can infer that no geofeed
data is available for that object, since the server would have
provided it if it were available.
Singh & Harrison Expires 21 April 2025 [Page 4]
Internet-Draft rdap-geofeed October 2024
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.
2.4. Example
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"
},
...
],
...
}
Singh & Harrison Expires 21 April 2025 [Page 5]
Internet-Draft rdap-geofeed October 2024
3. Operational Considerations
When an RDAP server is queried for an IP network for a given address
range, it is required to return the most-specific IP network object
that covers the address range. That IP network object may not have
an associated geofeed link, but it is possible that a less-specific
IP network object does have such a link. Clients attempting to
retrieve geofeed data for a given address range via RDAP should
consider whether to retrieve the parent object for the initial
response (and so on, recursively) in the event that the initial
response does not contain geofeed data. Conversely, server operators
should consider interface options for resource holders in order to
support the provisioning of geofeed links for all networks covered by
the associated data.
It is common for a resource holder to maintain a single geofeed file
containing the geofeed data for all of their resources. The resource
holder then updates each of their network object registrations to
refer to that single geofeed file. As with geofeed references in
inetnum objects (per [RFC9632]), clients who find a geofeed link
object within an IP network object MUST ignore geofeed data from that
link that is outside the IP network object's address range.
Section 3.2 of [RFC8805] recommends that consumers of geofeed data
verify that the publisher of the data is authoritative for the
relevant resources. The RDAP bootstrap process ([RFC9224]) helps
clients with this recommendation, since a client following that
process will be directed to the RDAP server that is able to make
authoritative statements about the disposition of the relevant
resources.
4. Privacy Considerations
When including a geofeed file URL in an IP network object, it is
expected that the service provider publishing the geofeed file has
followed the guidance from Section 7 of [RFC9632] 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.
Singh & Harrison Expires 21 April 2025 [Page 6]
Internet-Draft rdap-geofeed October 2024
5. Security Considerations
[RFC9632] 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.
6. IANA Considerations
6.1. RDAP Extensions Registry
IANA is requested to register the following value in the RDAP
Extensions Registry at [RDAP-EXTENSIONS]:
* Extension identifier: geofeed1
* Registry operator: Any
* Published specification: This document.
* Contact: IETF, iesg@ietf.org
* Intended usage: This extension describes version 1 of a method to
access the IP geolocation feed data through RDAP.
6.2. Link Relations Registry
IANA is requested to register the following value in the Link
Relations Registry at [LINK-RELATIONS]:
* Relation Name: geo
* Description: Indicates that the link context has a resource with
geographic information at the link target.
* Reference: This document.
6.3. Media Types Registry
IANA is requested to register the following value in the Media Types
Registry at [MEDIA-TYPES]:
* Type name: application
* Subtype name: geofeed+csv
* Required parameters: N/A
* Optional parameters: N/A
* Encoding considerations: See Section 2 of [RFC9632].
* Security considerations: See Section 5 of this document.
* Interoperability considerations: There are no known
interoperability problems regarding this media format.
* Published specification: This document.
Singh & Harrison Expires 21 April 2025 [Page 7]
Internet-Draft rdap-geofeed October 2024
* Applications that use this media type: Implementations of the
Registration Data Access Protocol (RDAP) Extension for Geofeed
Data. Furthermore, any application that processes the CSV geofeed
data.
* Additional information: This media type is a product of the IETF
REGEXT Working Group. The REGEXT charter, information on the
REGEXT mailing list, and other documents produced by the REGEXT
Working Group can be found at [REGEXT].
* Person & email address to contact for further information: IETF,
iesg@ietf.org
* Intended usage: COMMON
* Restrictions on usage: None
* Authors: Tom Harrison, Jasdip Singh
* Change controller: IETF
* Provisional Registration: No
6.4. Structured Syntax Suffixes Registry
IANA is requested to register the following value in the Structured
Syntax Suffixes Registry at [STRUCTURED-SYNTAX-SUFFIXES]:
* Name: Comma-Separated Values (CSV)
* +suffix: +csv
* References: [RFC4180], [RFC7111]
* Encoding Considerations: Same as "text/csv".
* Interoperability Considerations: Same as "text/csv".
* Fragment Identifier Considerations:
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".
* Security Considerations: Same as "text/csv".
* Contact: IETF, iesg@ietf.org
Singh & Harrison Expires 21 April 2025 [Page 8]
Internet-Draft rdap-geofeed October 2024
7. Implementation Status
NOTE: Please remove this section and the reference to RFC 7942 prior
to publication as an RFC.
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC7942].
The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may
exist.
According to RFC 7942, "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as
they see fit".
7.1. RIPE NCC
* Responsible Organization: RIPE NCC
* Location: https://rdap.db.ripe.net (https://rdap.db.ripe.net)
* Description: An RDAP server returning geofeed data.
* Level of Maturity: This is a production implementation.
* Coverage: This implementation covers all the features described in
this specification.
* Contact Information: Ed Shryane, eshryane@ripe.net
8. Acknowledgements
Mark Kosters provided initial support and encouragement for this
work, along with the [RFC9632] authors. Gavin Brown suggested using
a web link instead of a simple URL string to specify a geofeed file
URL. Andy Newton, James Gould, Scott Hollenbeck, and Mario Loffredo
also provided valuable feedback for this document.
9. Change History
(Remove this section before publication.)
Singh & Harrison Expires 21 April 2025 [Page 9]
Internet-Draft rdap-geofeed October 2024
9.1. Changes from 00 to 01
* Now using a web link instead of a simple URL string to specify a
geofeed file URL.
* Renamed the extension as "geofeed1" instead of "geofeedv1".
* Introduced the new "geo" link relation type.
* Introduced the new "application/geofeed+csv" media type.
9.2. Changes from 01 to 02
* Updated the "Requirements Language" section for examples.
* Added an example for RDAP conformance.
* Updated the rationale for using the new "application/geofeed+csv"
media type.
* Updated the "Applications that use this media type" section for
the "application/geofeed+csv" registration.
9.3. Changes from 02 to 03
* Removed "value" and "hreflang" explanations from the "Geofeed
Link" section. Further, clarified the cardinality of geofeed link
objects.
* Updated extensibility verbiage in the "Media Type for a Geofeed
Link" section.
* In the "Example" section, updated the domain in "href" of the
geofeed link object to contrast with the domain in "value" to
highlight that "href" is for a geofeed file hosted at a network
operator site whereas "value" is for an IP network object from an
RDAP server.
* Removed the "Redaction" section since the geofeed files are public
to start with.
* Added URLs for various IANA registries.
9.4. Changes from 03 to 04
* Updated the criteria for including the extension identifier in
"rdapConformance".
9.5. Changes from 04 to 05
* Made various editorial changes.
9.6. Changes from 05 to 06
* The extension identifier inclusion is now a must.
* Added the "Operational Considerations" section to clarify the
geofeed file and IP networks relationship, as well as how RDAP
Bootstrap helps with a recommendation from RFC 8805.
Singh & Harrison Expires 21 April 2025 [Page 10]
Internet-Draft rdap-geofeed October 2024
* Updated the "Privacy Considerations" section to clarify the
service provider responsibility.
9.7. Changes from 06 to 07
* Updated the extension identifier text so as to clarify that the
media type and link relation can be used independently of that
identifier.
9.8. Changes from 07 to 08
* Added the "Implementation Status" section.
* Updated references.
10. References
10.1. Normative References
[BCP14] Best Current Practice 14,
<https://www.rfc-editor.org/info/bcp14>.
At the time of writing, this BCP comprises the following:
Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC9083] Hollenbeck, S. and A. Newton, "JSON Responses for the
Registration Data Access Protocol (RDAP)", STD 95,
RFC 9083, DOI 10.17487/RFC9083, June 2021,
<https://www.rfc-editor.org/info/rfc9083>.
[RFC9224] Blanchet, M., "Finding the Authoritative Registration Data
Access Protocol (RDAP) Service", STD 95, RFC 9224,
DOI 10.17487/RFC9224, March 2022,
<https://www.rfc-editor.org/info/rfc9224>.
Singh & Harrison Expires 21 April 2025 [Page 11]
Internet-Draft rdap-geofeed October 2024
[RFC9632] Bush, R., Candela, M., Kumari, W., and R. Housley,
"Finding and Using Geofeed Data", RFC 9632,
DOI 10.17487/RFC9632, August 2024,
<https://www.rfc-editor.org/info/rfc9632>.
10.2. Informative References
[I-D.shafranovich-rfc4180-bis]
Shafranovich, Y., "Common Format and MIME Type for Comma-
Separated Values (CSV) Files", Work in Progress, Internet-
Draft, draft-shafranovich-rfc4180-bis-07, 2 August 2024,
<https://datatracker.ietf.org/doc/html/draft-shafranovich-
rfc4180-bis-07>.
[LINK-RELATIONS]
IANA, "Link Relations",
<https://www.iana.org/assignments/link-relations/>.
[MEDIA-TYPES]
IANA, "Media Types",
<https://www.iana.org/assignments/media-types/>.
[RDAP-EXTENSIONS]
IANA, "RDAP Extensions",
<https://www.iana.org/assignments/rdap-extensions/>.
[REGEXT] IETF, "Registration Protocols Extensions",
<https://datatracker.ietf.org/wg/regext/>.
[RFC4180] Shafranovich, Y., "Common Format and MIME Type for Comma-
Separated Values (CSV) Files", RFC 4180,
DOI 10.17487/RFC4180, October 2005,
<https://www.rfc-editor.org/info/rfc4180>.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
February 2012, <https://www.rfc-editor.org/info/rfc6480>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/info/rfc6838>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013,
<https://www.rfc-editor.org/info/rfc6973>.
Singh & Harrison Expires 21 April 2025 [Page 12]
Internet-Draft rdap-geofeed October 2024
[RFC7111] Hausenblas, M., Wilde, E., and J. Tennison, "URI Fragment
Identifiers for the text/csv Media Type", RFC 7111,
DOI 10.17487/RFC7111, January 2014,
<https://www.rfc-editor.org/info/rfc7111>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>.
[RFC8805] Kline, E., Duleba, K., Szamonek, Z., Moser, S., and W.
Kumari, "A Format for Self-Published IP Geolocation
Feeds", RFC 8805, DOI 10.17487/RFC8805, August 2020,
<https://www.rfc-editor.org/info/rfc8805>.
[STRUCTURED-SYNTAX-SUFFIXES]
IANA, "Structured Syntax Suffixes",
<https://www.iana.org/assignments/media-type-structured-
suffix/>.
Authors' Addresses
Jasdip Singh
ARIN
Email: jasdips@arin.net
Tom Harrison
APNIC
Email: tomh@apnic.net
Singh & Harrison Expires 21 April 2025 [Page 13]