Registration Data Access Protocol (RDAP) Extension for Geofeed Data
draft-ietf-regext-rdap-geofeed-14

Registration Protocols Extensions (regext)                      J. Singh
Internet-Draft                                                      ARIN
Intended status: Standards Track                             T. Harrison
Expires: 7 December 2025                                           APNIC
                                                             5 June 2025

  Registration Data Access Protocol (RDAP) Extension for Geofeed Data
                   draft-ietf-regext-rdap-geofeed-14

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 a new 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 7 December 2025.

Copyright Notice

   Copyright (c) 2025 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 7 December 2025                [Page 1]
Internet-Draft                rdap-geofeed                     June 2025

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Specification . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Media Type for a Geofeed Link . . . . . . . . . . . . . .   3
     2.2.  Geofeed Link  . . . . . . . . . . . . . . . . . . . . . .   4
     2.3.  Extension Identifier  . . . . . . . . . . . . . . . . . .   4
     2.4.  Example . . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Operational Considerations  . . . . . . . . . . . . . . . . .   6
   4.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
     6.1.  RDAP Extensions Registry  . . . . . . . . . . . . . . . .   8
     6.2.  Link Relations Registry . . . . . . . . . . . . . . . . .   8
     6.3.  Media Types Registry  . . . . . . . . . . . . . . . . . .   8
     6.4.  Structured Syntax Suffixes Registry . . . . . . . . . . .   9
   7.  Implementation Status . . . . . . . . . . . . . . . . . . . .   9
     7.1.  RIPE NCC  . . . . . . . . . . . . . . . . . . . . . . . .  10
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   9.  Change History  . . . . . . . . . . . . . . . . . . . . . . .  10
     9.1.  Changes from 00 to 01 . . . . . . . . . . . . . . . . . .  11
     9.2.  Changes from 01 to 02 . . . . . . . . . . . . . . . . . .  11
     9.3.  Changes from 02 to 03 . . . . . . . . . . . . . . . . . .  11
     9.4.  Changes from 03 to 04 . . . . . . . . . . . . . . . . . .  11
     9.5.  Changes from 04 to 05 . . . . . . . . . . . . . . . . . .  11
     9.6.  Changes from 05 to 06 . . . . . . . . . . . . . . . . . .  11
     9.7.  Changes from 06 to 07 . . . . . . . . . . . . . . . . . .  12
     9.8.  Changes from 07 to 08 . . . . . . . . . . . . . . . . . .  12
     9.9.  Changes from 08 to 09 . . . . . . . . . . . . . . . . . .  12
     9.10. Changes from 09 to 10 . . . . . . . . . . . . . . . . . .  12
     9.11. Changes from 10 to 11 . . . . . . . . . . . . . . . . . .  12
     9.12. Changes from 11 to 12 . . . . . . . . . . . . . . . . . .  12
     9.13. Changes from 12 to 13 . . . . . . . . . . . . . . . . . .  12
     9.14. Changes from 13 to 14 . . . . . . . . . . . . . . . . . .  12
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  12
     10.2.  Informative References . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   [RFC8805] and [RFC9632] detail the IP geolocation feed (commonly
   known as 'geofeed') file format and associated access mechanisms.
   While [RFC9632] describes how a registry can make geofeed URLs
   available by way of a Routing Policy Specification Language (RPSL)
   [RFC2622] service, the Regional Internet Registries (RIRs) have
   deployed Registration Data Access Protocol (RDAP) ([RFC7480],
   [RFC7481], [RFC9082], [RFC9083]) services as successors to RPSL for

Singh & Harrison         Expires 7 December 2025                [Page 2]
Internet-Draft                rdap-geofeed                     June 2025

   Internet number resource registrations, and maintaining feature
   parity between the two services supports client transition from RPSL
   to RDAP in this context.  To that end, 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 new media type
   and a new link relation type for the associated link objects.

   Fetching and making use of geofeed data is out of scope for the
   purposes of this document.  See [RFC8805] and [RFC9632] for further
   details.

   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.

   Indentation and whitespace in examples are provided only to
   illustrate element relationships, and are not a required feature of
   this specification.

   "..." 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 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 IP 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).

Singh & Harrison         Expires 7 December 2025                [Page 3]
Internet-Draft                rdap-geofeed                     June 2025

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]).

   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 "geofeed".  This is a
      new link relation type for IP geolocation feed 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 (Section 6 of [RFC9632]) for an IP network.
   *  "type" -- "application/geofeed+csv" (see Section 2.1).

   An IP network object returned by an RDAP server MAY contain zero or
   more geofeed link objects, though typically an IP network will have
   either no such link objects or only one.  The scenario where more
   than one geofeed link object could be returned is when the server is
   able to represent that data in multiple languages.  In such a case,
   the server SHOULD provide "hreflang" members for the geofeed link
   objects.  Except for the multiple-languages scenario, the server
   SHOULD NOT return more than one geofeed 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
   (Section 4.1 of [RFC9083]) 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", ... ],
       ...
   }

Singh & Harrison         Expires 7 December 2025                [Page 4]
Internet-Draft                rdap-geofeed                     June 2025

   If the server includes "geofeed1" in the "rdapConformance" array,
   then for any response concerning a particular IP network object for
   which the server possesses a geofeed URL and is able to return it to
   the client (i.e. is not compelled to omit it due to regulatory
   constraints or similar), the server MUST include a corresponding
   geofeed link object in the response.

   An RDAP server may make use of the "application/geofeed+csv" media
   type and the "geofeed" 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
   including the extension identifier in the "rdapConformance" array 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.

   Although a server may use registered media types in its link objects
   without any restrictions, it is 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 "1" in "geofeed1" denotes that this is version 1 of the geofeed
   extension.  New versions of the geofeed extension will use different
   extension identifiers.

2.4.  Example

   The following is an elided example of an IP network object with a
   geofeed link object:

Singh & Harrison         Expires 7 December 2025                [Page 5]
Internet-Draft                rdap-geofeed                     June 2025

   {
       "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": "geofeed",
               "href": "https://example.com/geofeed",
               "type": "application/geofeed+csv"
           },
           ...
       ],
       ...
   }

3.  Operational Considerations

   When an RDAP client performs an IP network lookup, per Section 3.1.1
   of [RFC9082], the RDAP server is required to return the most-specific
   IP network object that covers the IP address range provided by the
   client.  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 IP 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

Singh & Harrison         Expires 7 December 2025                [Page 6]
Internet-Draft                rdap-geofeed                     June 2025

   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 and opt to retrieve the data from
   the associated link MUST ignore any entry where the entry's IP
   address range 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.

   To prevent undue load on RDAP and geofeed servers, clients fetching
   geofeed data using these mechanisms MUST NOT do frequent real-time
   lookups.  See Section 6 of [RFC9632] for further details.

4.  Privacy Considerations

   All the privacy considerations from Section 7 of [RFC9632] apply to
   this document.  In particular, the service provider publishing the
   geofeed file MUST take care not to expose the location of any
   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.

5.  Security Considerations

   Section 6 of [RFC9632] documents several security considerations that
   are equally relevant in the RDAP context.

   A geofeed file MUST be referenced with an HTTPS URL, per Section 6 of
   [RFC9632].  The geofeed file may also contain an RPKI signature, per
   Section 5 of [RFC9632].

   Besides that, this document does not introduce any new security
   considerations past those already discussed in the RDAP protocol
   specifications ([RFC7481], [RFC9560]).

6.  IANA Considerations

Singh & Harrison         Expires 7 December 2025                [Page 7]
Internet-Draft                rdap-geofeed                     June 2025

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: geofeed
   *  Description: Refers to a resource with IP geofeed location
      information related to the link context.
   *  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: "charset" is an optional parameter for "text/
      csv", but it is not used for "application/geofeed+csv" because the
      geofeed content is always in UTF-8 (Section 2.1 of [RFC8805]).
   *  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.
   *  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: REGEXT
      Working Group, regext@ietf.org

Singh & Harrison         Expires 7 December 2025                [Page 8]
Internet-Draft                rdap-geofeed                     June 2025

   *  Intended usage: COMMON
   *  Restrictions on usage: None
   *  Authors: Tom Harrison, Jasdip Singh
   *  Author/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 for +csv.

      For cases defined in +csv, where the fragment identifier does not
      resolve per the +csv rules, then as specified for "xxx/yyy+csv".

      For cases not defined in +csv, then as specified for "xxx/
      yyy+csv".

   *  Security Considerations: Same as "text/csv".

   *  Contact: IETF, iesg@ietf.org

   *  Author/Change controller: IETF

7.  Implementation Status

   (Remove this section before publication.)

Singh & Harrison         Expires 7 December 2025                [Page 9]
Internet-Draft                rdap-geofeed                     June 2025

   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://docs.db.ripe.net/Release-Notes/#ripe-database-
      release-1-110 (https://docs.db.ripe.net/Release-Notes/#ripe-
      database-release-1-110)
   *  Description: An RDAP server returning geofeed data.
   *  Level of Maturity: This is a production implementation.
   *  Coverage: This implementation covers all the features described in
      version 01 of 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, Mario Loffredo,
   Orie Steele, Alexey Melnikov, Mark Nottingham, Rifaat Shekh-Yusuf,
   Dale R.  Worley, Dhruv Dhody, Mohamed Boucadair, Mahesh Jethanandani,
   Ketan Talaulikar, and Éric Vyncke provided valuable feedback for this
   document.

9.  Change History

   (Remove this section before publication.)

Singh & Harrison         Expires 7 December 2025               [Page 10]
Internet-Draft                rdap-geofeed                     June 2025

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 7 December 2025               [Page 11]
Internet-Draft                rdap-geofeed                     June 2025

   *  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.

9.9.  Changes from 08 to 09

   *  Incorporated feedback from the AD review.
   *  Incorporated feedback from the media type review.
   *  RFCs 4180, 7111, and 8805 are now normative references.
   *  Made minor editorial changes.

9.10.  Changes from 09 to 10

   *  Incorporated feedback from the IESG review.

9.11.  Changes from 10 to 11

   *  Incorporated feedback from the IESG review.

9.12.  Changes from 11 to 12

   *  Incorporated feedback from the IESG review.

9.13.  Changes from 12 to 13

   *  Incorporated feedback from the IESG review.

9.14.  Changes from 13 to 14

   *  Incorporated feedback from the IESG review.

10.  References

10.1.  Normative References

Singh & Harrison         Expires 7 December 2025               [Page 12]
Internet-Draft                rdap-geofeed                     June 2025

   [RFC2119]  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>.

   [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>.

   [RFC8174]  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>.

   [RFC9082]  Hollenbeck, S. and A. Newton, "Registration Data Access
              Protocol (RDAP) Query Format", STD 95, RFC 9082,
              DOI 10.17487/RFC9082, June 2021,
              <https://www.rfc-editor.org/info/rfc9082>.

   [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>.

   [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

   [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/>.

Singh & Harrison         Expires 7 December 2025               [Page 13]
Internet-Draft                rdap-geofeed                     June 2025

   [REGEXT]   IETF, "Registration Protocols Extensions",
              <https://datatracker.ietf.org/wg/regext/>.

   [RFC2622]  Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D.,
              Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra,
              "Routing Policy Specification Language (RPSL)", RFC 2622,
              DOI 10.17487/RFC2622, June 1999,
              <https://www.rfc-editor.org/info/rfc2622>.

   [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>.

   [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>.

   [RFC7480]  Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the
              Registration Data Access Protocol (RDAP)", STD 95,
              RFC 7480, DOI 10.17487/RFC7480, March 2015,
              <https://www.rfc-editor.org/info/rfc7480>.

   [RFC7481]  Hollenbeck, S. and N. Kong, "Security Services for the
              Registration Data Access Protocol (RDAP)", STD 95,
              RFC 7481, DOI 10.17487/RFC7481, March 2015,
              <https://www.rfc-editor.org/info/rfc7481>.

   [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>.

Singh & Harrison         Expires 7 December 2025               [Page 14]
Internet-Draft                rdap-geofeed                     June 2025

   [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>.

   [RFC9560]  Hollenbeck, S., "Federated Authentication for the
              Registration Data Access Protocol (RDAP) Using OpenID
              Connect", RFC 9560, DOI 10.17487/RFC9560, April 2024,
              <https://www.rfc-editor.org/info/rfc9560>.

   [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 7 December 2025               [Page 15]