Skip to main content

An RDAP Extension for Geofeed Data
draft-ietf-regext-rdap-geofeed-05

Document Type Active Internet-Draft (regext WG)
Authors Jasdip Singh , Tom Harrison
Last updated 2024-04-19
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 WG Document
Document shepherd Gavin Brown
IESG IESG state I-D Exists
Consensus boilerplate Yes
Telechat date (None)
Responsible AD (None)
Send notices to gavin.brown@icann.org
draft-ietf-regext-rdap-geofeed-05
Registration Protocols Extensions (regext)                      J. Singh
Internet-Draft                                                      ARIN
Intended status: Standards Track                             T. Harrison
Expires: 21 October 2024                                           APNIC
                                                           19 April 2024

                   An RDAP Extension for Geofeed Data
                   draft-ietf-regext-rdap-geofeed-05

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 October 2024.

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 October 2024                [Page 1]
Internet-Draft                rdap-geofeed                    April 2024

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   2
   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 . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   5
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
     5.1.  RDAP Extensions Registry  . . . . . . . . . . . . . . . .   6
     5.2.  Link Relations Registry . . . . . . . . . . . . . . . . .   6
     5.3.  Media Types Registry  . . . . . . . . . . . . . . . . . .   6
     5.4.  Structured Syntax Suffixes Registry . . . . . . . . . . .   7
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   7.  Change History  . . . . . . . . . . . . . . . . . . . . . . .   8
     7.1.  Changes from 00 to 01 . . . . . . . . . . . . . . . . . .   8
     7.2.  Changes from 01 to 02 . . . . . . . . . . . . . . . . . .   8
     7.3.  Changes from 02 to 03 . . . . . . . . . . . . . . . . . .   8
     7.4.  Changes from 03 to 04 . . . . . . . . . . . . . . . . . .   8
     7.5.  Changes from 04 to 05 . . . . . . . . . . . . . . . . . .   9
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

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

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 BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

Singh & Harrison         Expires 21 October 2024                [Page 2]
Internet-Draft                rdap-geofeed                    April 2024

   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

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

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 "geo".  This is a new
      link relation type for geographical data, registered in the IANA
      Link Relations Registry (see Section 5.2) by this document.

Singh & Harrison         Expires 21 October 2024                [Page 3]
Internet-Draft                rdap-geofeed                    April 2024

   *  "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 the link object).

2.3.  Extension Identifier

   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.

2.4.  Example

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

Singh & Harrison         Expires 21 October 2024                [Page 4]
Internet-Draft                rdap-geofeed                    April 2024

   {
       "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"
           },
           ...
       ],
       ...
   }

3.  Privacy Considerations

   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.

Singh & Harrison         Expires 21 October 2024                [Page 5]
Internet-Draft                rdap-geofeed                    April 2024

4.  Security Considerations

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

5.  IANA Considerations

5.1.  RDAP Extensions Registry

   IANA is requested to register the following value in the RDAP
   Extensions Registry at https://www.iana.org/assignments/rdap-
   extensions/: (https://www.iana.org/assignments/rdap-extensions/:)

   *  Extension identifier: geofeed1
   *  Registry operator: Any
   *  Published specification: This document.
   *  Contact: IETF iesg@ietf.org (mailto:iesg@ietf.org)
   *  Intended usage: This extension describes version 1 of a method to
      access the IP geolocation feed data through RDAP.

5.2.  Link Relations Registry

   IANA is requested to register the following value in the Link
   Relations Registry at https://www.iana.org/assignments/link-
   relations/: (https://www.iana.org/assignments/link-relations/:)

   *  Relation Name: geo
   *  Description: Indicates that the link context has a resource with
      geographic information at the link target.
   *  Reference: This document.

5.3.  Media Types Registry

   IANA is requested to register the following value in the Media Types
   Registry at https://www.iana.org/assignments/media-types/:
   (https://www.iana.org/assignments/media-types/:)

   *  Type name: application
   *  Subtype name: geofeed+csv
   *  Required parameters: N/A
   *  Optional parameters: N/A
   *  Encoding considerations: See Section 2 of
      [I-D.ietf-opsawg-9092-update].
   *  Security considerations: See Section 4 of this document.

Singh & Harrison         Expires 21 October 2024                [Page 6]
Internet-Draft                rdap-geofeed                    April 2024

   *  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 https://datatracker.ietf.org/wg/
      regext/ (https://datatracker.ietf.org/wg/regext/).
   *  Person & email address to contact for further information: IETF
      iesg@ietf.org (mailto:iesg@ietf.org)
   *  Intended usage: COMMON
   *  Restrictions on usage: None
   *  Authors: Tom Harrison, Jasdip Singh
   *  Change controller: IETF
   *  Provisional Registration: No

5.4.  Structured Syntax Suffixes Registry

   IANA is requested to register the following value in the Structured
   Syntax Suffixes Registry at https://www.iana.org/assignments/media-
   type-structured-suffix/: (https://www.iana.org/assignments/media-
   type-structured-suffix/:)

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

Singh & Harrison         Expires 21 October 2024                [Page 7]
Internet-Draft                rdap-geofeed                    April 2024

   *  Security Considerations: Same as "text/csv".
   *  Contact: IETF iesg@ietf.org (mailto:iesg@ietf.org)

6.  Acknowledgements

   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.

7.  Change History

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

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

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

7.4.  Changes from 03 to 04

Singh & Harrison         Expires 21 October 2024                [Page 8]
Internet-Draft                rdap-geofeed                    April 2024

   *  Updated the criteria for including the extension identifier in
      "rdapConformance".

7.5.  Changes from 04 to 05

   *  Made various editorial changes.

8.  References

8.1.  Normative References

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

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

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

Singh & Harrison         Expires 21 October 2024                [Page 9]
Internet-Draft                rdap-geofeed                    April 2024

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

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

   [RFC9092]  Bush, R., Candela, M., Kumari, W., and R. Housley,
              "Finding and Using Geofeed Data", RFC 9092,
              DOI 10.17487/RFC9092, July 2021,
              <https://www.rfc-editor.org/info/rfc9092>.

8.2.  Informative References

   [I-D.ietf-opsawg-9092-update]
              Bush, R., Candela, M., Kumari, W. A., and R. Housley,
              "Finding and Using Geofeed Data", Work in Progress,
              Internet-Draft, draft-ietf-opsawg-9092-update-11, 22
              February 2024, <https://datatracker.ietf.org/doc/html/
              draft-ietf-opsawg-9092-update-11>.

   [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-06, 31 January 2024,
              <https://datatracker.ietf.org/doc/html/draft-shafranovich-
              rfc4180-bis-06>.

Authors' Addresses

   Jasdip Singh
   ARIN
   Email: jasdips@arin.net

   Tom Harrison
   APNIC
   Email: tomh@apnic.net

Singh & Harrison         Expires 21 October 2024               [Page 10]