rfc9877.original   rfc9877.txt 
Registration Protocols Extensions (regext) J. Singh Internet Engineering Task Force (IETF) J. Singh
Internet-Draft ARIN Request for Comments: 9877 ARIN
Intended status: Standards Track T. Harrison Category: Standards Track T. Harrison
Expires: 7 December 2025 APNIC ISSN: 2070-1721 APNIC
5 June 2025 October 2025
Registration Data Access Protocol (RDAP) Extension for Geofeed Data Registration Data Access Protocol (RDAP) Extension for Geofeed Data
draft-ietf-regext-rdap-geofeed-14
Abstract Abstract
This document defines a new Registration Data Access Protocol (RDAP) This document defines a new Registration Data Access Protocol (RDAP)
extension, "geofeed1", for indicating that an RDAP server hosts extension, "geofeed1", for indicating that an RDAP server hosts
geofeed URLs for its IP network objects. It also defines a new media 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 type and a new link relation type for the associated link objects
included in responses. included in responses.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 7 December 2025. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9877.
Copyright Notice Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Specification . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Specification
2.1. Media Type for a Geofeed Link . . . . . . . . . . . . . . 3 2.1. Media Type for a Geofeed Link
2.2. Geofeed Link . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Geofeed Link
2.3. Extension Identifier . . . . . . . . . . . . . . . . . . 4 2.3. Extension Identifier
2.4. Example . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.4. Example
3. Operational Considerations . . . . . . . . . . . . . . . . . 6 3. Operational Considerations
4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7 4. Privacy Considerations
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations
6.1. RDAP Extensions Registry . . . . . . . . . . . . . . . . 8 6.1. RDAP Extensions Registry
6.2. Link Relations Registry . . . . . . . . . . . . . . . . . 8 6.2. Link Relations Registry
6.3. Media Types Registry . . . . . . . . . . . . . . . . . . 8 6.3. Media Types Registry
6.4. Structured Syntax Suffixes Registry . . . . . . . . . . . 9 6.4. Structured Syntax Suffixes Registry
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 9 7. References
7.1. RIPE NCC . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Normative References
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 7.2. Informative References
9. Change History . . . . . . . . . . . . . . . . . . . . . . . 10 Acknowledgements
9.1. Changes from 00 to 01 . . . . . . . . . . . . . . . . . . 11 Authors' Addresses
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 1. Introduction
[RFC8805] and [RFC9632] detail the IP geolocation feed (commonly [RFC8805] and [RFC9632] detail the IP geolocation feed (commonly
known as 'geofeed') file format and associated access mechanisms. known as 'geofeed') file format and associated access mechanisms.
While [RFC9632] describes how a registry can make geofeed URLs While [RFC9632] describes how a registry can make geofeed URLs
available by way of a Routing Policy Specification Language (RPSL) available by way of a Routing Policy Specification Language (RPSL)
[RFC2622] service, the Regional Internet Registries (RIRs) have [RFC2622] service, the Regional Internet Registries (RIRs) have
deployed Registration Data Access Protocol (RDAP) ([RFC7480], deployed Registration Data Access Protocol (RDAP) ([RFC7480],
[RFC7481], [RFC9082], [RFC9083]) services as successors to RPSL for [RFC7481], [RFC9082], [RFC9083]) services as successors to RPSL for
skipping to change at page 3, line 18 skipping to change at line 92
extension, "geofeed1", for indicating that an RDAP server hosts extension, "geofeed1", for indicating that an RDAP server hosts
geofeed URLs for its IP network objects, as well as a new media type 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. and a new link relation type for the associated link objects.
Fetching and making use of geofeed data is out of scope for the Fetching and making use of geofeed data is out of scope for the
purposes of this document. See [RFC8805] and [RFC9632] for further purposes of this document. See [RFC8805] and [RFC9632] for further
details. details.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Indentation and whitespace in examples are provided only to Indentation and whitespace in examples are provided only to
illustrate element relationships, and are not a required feature of illustrate element relationships, and they are not a required feature
this specification. of this specification.
"..." in examples is used as shorthand for elements defined outside "..." in examples is used as shorthand for elements defined outside
of this document. of this document.
2. Specification 2. Specification
2.1. Media Type for a Geofeed Link 2.1. Media Type for a Geofeed Link
[RFC9632] requires a geofeed file to be a UTF-8 [RFC3629] comma- [RFC9632] requires a geofeed file to be a UTF-8 [RFC3629] comma-
separated values (CSV) file, with a series of "#" comments at the end separated values (CSV) file, with a series of "#" comments at the end
for the optional Resource Public Key Infrastructure (RPKI, [RFC6480]) for the optional Resource Public Key Infrastructure (RPKI) [RFC6480]
signature. At first glance, the "text/csv" media type seems like a signature. At first glance, the "text/csv" media type seems like a
good candidate for a geofeed file, since it supports the "#" comments good candidate for a geofeed file, since it supports the "#" comments
needed for including the RPKI signature. needed for including the RPKI signature.
However, although the CSV geofeed data could be viewed directly by a However, although the CSV geofeed data could be viewed directly by a
user such that the "text/csv" media type was appropriate, the most user such that the "text/csv" media type was appropriate, the most
common use case will involve it being processed by some sort of common use case will involve it being processed by some sort of
application first, in order to facilitate subsequent IP address application first, in order to facilitate subsequent IP address
lookup operations. Therefore, using a new "application" media type lookup operations. Therefore, using a new "application" media type
with a "geofeed" subtype (Section 4.2.5 of [RFC6838]) for the geofeed with a "geofeed" subtype (Section 4.2.5 of [RFC6838]) for the geofeed
data is preferable to using "text/csv". data is preferable to using "text/csv".
To that end, this document registers a new "application/geofeed+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 media type in the IANA "Media Types" registry (see Section 6.3), and
new "+csv" suffix in the IANA Structured Syntax Suffixes Registry a new "+csv" suffix in the IANA "Structured Syntax Suffixes" registry
(see Section 6.4). (see Section 6.4).
2.2. Geofeed Link 2.2. Geofeed Link
An RDAP server that hosts geofeed URLs for its IP network objects An RDAP server that hosts geofeed URLs for its IP network objects
(Section 5.4 of [RFC9083]) may include link objects for those geofeed (Section 5.4 of [RFC9083]) may include link objects for those geofeed
URLs in IP network objects in its responses. These link objects are URLs in IP network objects in its responses. These link objects are
added to the "links" member of each object (Section 4.2 of added to the "links" member of each object (Section 4.2 of
[RFC9083]). [RFC9083]).
In RDAP, the "value", "rel", and "href" JSON members are required for In RDAP, the "value", "rel", and "href" JSON members are required for
any link object. Additionally, for a geofeed link object, the "type" any link object. Additionally, for a geofeed link object, the "type"
JSON member is RECOMMENDED. The geofeed-specific components of a JSON member is RECOMMENDED. The geofeed-specific components of a
link object are like so: link object are like so:
* "rel" -- The link relation type is set to "geofeed". This is a "rel": The link relation type is set to "geofeed". This is a new
new link relation type for IP geolocation feed data, registered in link relation type for IP geolocation feed data, registered in the
the IANA Link Relations Registry (see Section 6.2) by this IANA "Link Relations" registry (see Section 6.2) by this document.
document.
* "href" -- The target URL is set to the HTTPS URL of the geofeed "href": The target URL is set to the HTTPS URL of the geofeed file
file (Section 6 of [RFC9632]) for an IP network. (Section 6 of [RFC9632]) for an IP network.
* "type" -- "application/geofeed+csv" (see Section 2.1).
"type": "application/geofeed+csv" (see Section 2.1).
An IP network object returned by an RDAP server MAY contain zero or An IP network object returned by an RDAP server MAY contain zero or
more geofeed link objects, though typically an IP network will have more geofeed link objects, though typically an IP network will have
either no such link objects or only one. The scenario where more either zero or only one. The scenario where more than one geofeed
than one geofeed link object could be returned is when the server is link object could be returned is when the server is able to represent
able to represent that data in multiple languages. In such a case, that data in multiple languages. In such a case, the server SHOULD
the server SHOULD provide "hreflang" members for the geofeed link provide "hreflang" members for the geofeed link objects. Except for
objects. Except for the multiple-languages scenario, the server the multiple-languages scenario, the server SHOULD NOT return more
SHOULD NOT return more than one geofeed link object. than one geofeed link object.
2.3. Extension Identifier 2.3. Extension Identifier
This document defines a new extension identifier, "geofeed1", for use This document defines a new extension identifier, "geofeed1", for use
by servers that host geofeed URLs for their IP network objects and by servers that host geofeed URLs for their IP network objects and
include geofeed URL link objects in their responses to clients in include geofeed URL link objects in their responses to clients in
accordance with Section 2.2. A server that uses this extension accordance with Section 2.2. A server that uses this extension
identifier MUST include it in the "rdapConformance" array identifier MUST include it in the "rdapConformance" array
(Section 4.1 of [RFC9083]) for any lookup or search response (Section 4.1 of [RFC9083]) for any lookup or search response
containing an IP network object, as well as in the help response. containing an IP network object, as well as in the help response.
Here is an elided example for this inclusion: Here is an elided example of this inclusion:
{ {
"rdapConformance": [ "rdap_level_0", "geofeed1", ... ], "rdapConformance": [ "rdap_level_0", "geofeed1", ... ],
... ...
} }
If the server includes "geofeed1" in the "rdapConformance" array, If the server includes "geofeed1" in the "rdapConformance" array,
then for any response concerning a particular IP network object for 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 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 the client (i.e., the server is not compelled to omit it due to
constraints or similar), the server MUST include a corresponding regulatory constraints or similar), the server MUST include a
geofeed link object in the response. corresponding geofeed link object in the response.
An RDAP server may make use of the "application/geofeed+csv" media An RDAP server may make use of the "application/geofeed+csv" media
type and the "geofeed" link relation defined in this specification in type and the "geofeed" link relation defined in this specification in
its responses without including the "geofeed1" extension identifier its responses without including the "geofeed1" extension identifier
in those responses, because RDAP servers are free to use any in those responses, because RDAP servers are free to use any
registered media type or link relation in a standard response without registered media type or link relation in a standard response without
implementing any particular extension. The additional value of implementing any particular extension. The additional value of
including the extension identifier in the "rdapConformance" array is including the extension identifier in the "rdapConformance" array is
that it signals to the client that the server hosts geofeed URLs for 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 its IP network objects. This is useful where a client receives an IP
network object without a geofeed link object, because in that case network object without a geofeed link object, because in that case
the client can infer that no geofeed data is available for that the client can infer that no geofeed data is available for that
object, since the server would have provided it if it were available. object, since the server would have provided it if it were available.
Although a server may use registered media types in its link objects Although a server may use registered media types in its link objects
without any restrictions, it is useful to define new RDAP extensions without any restrictions, it is useful to define new RDAP extensions
for those media types in order for the server to communicate to 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 clients that it will make data for that type accessible. This is the
way that the server does with the "geofeed1" extension identifier. same as what the server does with the "geofeed1" extension
identifier.
The "1" in "geofeed1" denotes that this is version 1 of the geofeed The "1" in "geofeed1" denotes that this is version 1 of the geofeed
extension. New versions of the geofeed extension will use different extension. New versions of the geofeed extension will use different
extension identifiers. extension identifiers.
2.4. Example 2.4. Example
The following is an elided example of an IP network object with a The following is an elided example of an IP network object with a
geofeed link object: geofeed link object:
skipping to change at page 7, line 12 skipping to change at line 266
containing the geofeed data for all of their resources. The resource containing the geofeed data for all of their resources. The resource
holder then updates each of their network object registrations to holder then updates each of their network object registrations to
refer to that single geofeed file. As with geofeed references in refer to that single geofeed file. As with geofeed references in
inetnum objects (per [RFC9632]), clients who find a geofeed link inetnum objects (per [RFC9632]), clients who find a geofeed link
object within an IP network object and opt to retrieve the data from 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 the associated link MUST ignore any entry where the entry's IP
address range is outside the IP network object's address range. address range is outside the IP network object's address range.
Section 3.2 of [RFC8805] recommends that consumers of geofeed data Section 3.2 of [RFC8805] recommends that consumers of geofeed data
verify that the publisher of the data is authoritative for the verify that the publisher of the data is authoritative for the
relevant resources. The RDAP bootstrap process ([RFC9224]) helps relevant resources. The RDAP bootstrap process [RFC9224] helps
clients with this recommendation, since a client following that clients with this recommendation, since a client following that
process will be directed to the RDAP server that is able to make process will be directed to the RDAP server that is able to make
authoritative statements about the disposition of the relevant authoritative statements about the disposition of the relevant
resources. resources.
To prevent undue load on RDAP and geofeed servers, clients fetching To prevent undue load on RDAP and geofeed servers, clients fetching
geofeed data using these mechanisms MUST NOT do frequent real-time geofeed data using these mechanisms MUST NOT do frequent real-time
lookups. See Section 6 of [RFC9632] for further details. lookups. See Section 6 of [RFC9632] for further details.
4. Privacy Considerations 4. Privacy Considerations
skipping to change at page 8, line 4 skipping to change at line 303
A geofeed file MUST be referenced with an HTTPS URL, per Section 6 of 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 [RFC9632]. The geofeed file may also contain an RPKI signature, per
Section 5 of [RFC9632]. Section 5 of [RFC9632].
Besides that, this document does not introduce any new security Besides that, this document does not introduce any new security
considerations past those already discussed in the RDAP protocol considerations past those already discussed in the RDAP protocol
specifications ([RFC7481], [RFC9560]). specifications ([RFC7481], [RFC9560]).
6. IANA Considerations 6. IANA Considerations
6.1. RDAP Extensions Registry 6.1. RDAP Extensions Registry
IANA is requested to register the following value in the RDAP IANA has registered the following value in the "RDAP Extensions"
Extensions Registry at [RDAP-EXTENSIONS]: registry at [RDAP-EXTENSIONS]:
* Extension identifier: geofeed1 Extension Identifier: geofeed1
* Registry operator: Any Registry Operator: Any
* Published specification: This document. Specification: RFC 9877
* Contact: IETF, iesg@ietf.org Contact: IETF <iesg@ietf.org>
* Intended usage: This extension describes version 1 of a method to Intended Usage: This extension describes version 1 of a method to
access the IP geolocation feed data through RDAP. access the IP geolocation feed data through RDAP.
6.2. Link Relations Registry 6.2. Link Relations Registry
IANA is requested to register the following value in the Link IANA has registered the following value in the "Link Relations"
Relations Registry at [LINK-RELATIONS]: registry at [LINK-RELATIONS]:
* Relation Name: geofeed Relation Name: geofeed
* Description: Refers to a resource with IP geofeed location Description: Refers to a resource with IP geofeed location
information related to the link context. information related to the link context.
* Reference: This document. Reference: RFC 9877
6.3. Media Types Registry 6.3. Media Types Registry
IANA is requested to register the following value in the Media Types IANA has registered the following media type in the "Media Types"
Registry at [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
* 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.)
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.)
9.1. Changes from 00 to 01
* Now using a web link instead of a simple URL string to specify a Type name: application
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 Subtype name: geofeed+csv
* Updated the "Requirements Language" section for examples. Required parameters: N/A
* 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 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]).
* Removed "value" and "hreflang" explanations from the "Geofeed Encoding considerations: See Section 2 of [RFC9632].
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 Security considerations: See Section 5 of RFC 9877.
* Updated the criteria for including the extension identifier in Interoperability considerations: There are no known interoperability
"rdapConformance". problems regarding this media format.
9.5. Changes from 04 to 05 Published specification: RFC 9877.
* Made various editorial changes. 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.
9.6. Changes from 05 to 06 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].
* The extension identifier inclusion is now a must. Person & email address to contact for further information:
* Added the "Operational Considerations" section to clarify the REGEXT Working Group <regext@ietf.org>
geofeed file and IP networks relationship, as well as how RDAP
Bootstrap helps with a recommendation from RFC 8805.
* Updated the "Privacy Considerations" section to clarify the Intended usage: COMMON
service provider responsibility.
9.7. Changes from 06 to 07 Restrictions on usage: None
* Updated the extension identifier text so as to clarify that the Authors: Tom Harrison, Jasdip Singh
media type and link relation can be used independently of that
identifier.
9.8. Changes from 07 to 08 Author/Change controller: IETF
* Added the "Implementation Status" section. 6.4. Structured Syntax Suffixes Registry
* Updated references.
9.9. Changes from 08 to 09 IANA has registered the following value in the "Structured Syntax
Suffixes" registry at [STRUCTURED-SYNTAX-SUFFIXES]:
* Incorporated feedback from the AD review. Name: Comma-Separated Values (CSV)
* 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 +suffix: +csv
* Incorporated feedback from the IESG review. References: [RFC4180], [RFC7111]
9.11. Changes from 10 to 11 Encoding Considerations: Same as "text/csv".
* Incorporated feedback from the IESG review. Interoperability Considerations: Same as "text/csv".
9.12. Changes from 11 to 12 Fragment Identifier Considerations: The syntax and semantics of
fragment identifiers specified for +csv SHOULD be as specified for
"text/csv".
* Incorporated feedback from the IESG review. The syntax and semantics for fragment identifiers for a specific
"xxx/yyy+csv" SHOULD be processed as follows:
9.13. Changes from 12 to 13 * 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".
* Incorporated feedback from the IESG review. Security Considerations: Same as "text/csv".
9.14. Changes from 13 to 14 Contact: IETF <iesg@ietf.org>
* Incorporated feedback from the IESG review. Author/Change controller: IETF
10. References 7. References
10.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>. 2003, <https://www.rfc-editor.org/info/rfc3629>.
skipping to change at page 13, line 38 skipping to change at line 444
[RFC9224] Blanchet, M., "Finding the Authoritative Registration Data [RFC9224] Blanchet, M., "Finding the Authoritative Registration Data
Access Protocol (RDAP) Service", STD 95, RFC 9224, Access Protocol (RDAP) Service", STD 95, RFC 9224,
DOI 10.17487/RFC9224, March 2022, DOI 10.17487/RFC9224, March 2022,
<https://www.rfc-editor.org/info/rfc9224>. <https://www.rfc-editor.org/info/rfc9224>.
[RFC9632] Bush, R., Candela, M., Kumari, W., and R. Housley, [RFC9632] Bush, R., Candela, M., Kumari, W., and R. Housley,
"Finding and Using Geofeed Data", RFC 9632, "Finding and Using Geofeed Data", RFC 9632,
DOI 10.17487/RFC9632, August 2024, DOI 10.17487/RFC9632, August 2024,
<https://www.rfc-editor.org/info/rfc9632>. <https://www.rfc-editor.org/info/rfc9632>.
10.2. Informative References 7.2. Informative References
[LINK-RELATIONS] [LINK-RELATIONS]
IANA, "Link Relations", IANA, "Link Relations",
<https://www.iana.org/assignments/link-relations/>. <https://www.iana.org/assignments/link-relations/>.
[MEDIA-TYPES] [MEDIA-TYPES]
IANA, "Media Types", IANA, "Media Types",
<https://www.iana.org/assignments/media-types/>. <https://www.iana.org/assignments/media-types/>.
[RDAP-EXTENSIONS] [RDAP-EXTENSIONS]
IANA, "RDAP Extensions", IANA, "RDAP Extensions",
<https://www.iana.org/assignments/rdap-extensions/>. <https://www.iana.org/assignments/rdap-extensions/>.
[REGEXT] IETF, "Registration Protocols Extensions", [REGEXT] IETF, "Registration Protocols Extensions (regext)",
<https://datatracker.ietf.org/wg/regext/>. <https://datatracker.ietf.org/wg/regext/>.
[RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., [RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D.,
Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra,
"Routing Policy Specification Language (RPSL)", RFC 2622, "Routing Policy Specification Language (RPSL)", RFC 2622,
DOI 10.17487/RFC2622, June 1999, DOI 10.17487/RFC2622, June 1999,
<https://www.rfc-editor.org/info/rfc2622>. <https://www.rfc-editor.org/info/rfc2622>.
[RFC4180] Shafranovich, Y., "Common Format and MIME Type for Comma- [RFC4180] Shafranovich, Y., "Common Format and MIME Type for Comma-
Separated Values (CSV) Files", RFC 4180, Separated Values (CSV) Files", RFC 4180,
skipping to change at page 14, line 49 skipping to change at line 502
[RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the [RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the
Registration Data Access Protocol (RDAP)", STD 95, Registration Data Access Protocol (RDAP)", STD 95,
RFC 7480, DOI 10.17487/RFC7480, March 2015, RFC 7480, DOI 10.17487/RFC7480, March 2015,
<https://www.rfc-editor.org/info/rfc7480>. <https://www.rfc-editor.org/info/rfc7480>.
[RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the [RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the
Registration Data Access Protocol (RDAP)", STD 95, Registration Data Access Protocol (RDAP)", STD 95,
RFC 7481, DOI 10.17487/RFC7481, March 2015, RFC 7481, DOI 10.17487/RFC7481, March 2015,
<https://www.rfc-editor.org/info/rfc7481>. <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>.
[RFC8805] Kline, E., Duleba, K., Szamonek, Z., Moser, S., and W. [RFC8805] Kline, E., Duleba, K., Szamonek, Z., Moser, S., and W.
Kumari, "A Format for Self-Published IP Geolocation Kumari, "A Format for Self-Published IP Geolocation
Feeds", RFC 8805, DOI 10.17487/RFC8805, August 2020, Feeds", RFC 8805, DOI 10.17487/RFC8805, August 2020,
<https://www.rfc-editor.org/info/rfc8805>. <https://www.rfc-editor.org/info/rfc8805>.
[RFC9560] Hollenbeck, S., "Federated Authentication for the [RFC9560] Hollenbeck, S., "Federated Authentication for the
Registration Data Access Protocol (RDAP) Using OpenID Registration Data Access Protocol (RDAP) Using OpenID
Connect", RFC 9560, DOI 10.17487/RFC9560, April 2024, Connect", RFC 9560, DOI 10.17487/RFC9560, April 2024,
<https://www.rfc-editor.org/info/rfc9560>. <https://www.rfc-editor.org/info/rfc9560>.
[STRUCTURED-SYNTAX-SUFFIXES] [STRUCTURED-SYNTAX-SUFFIXES]
IANA, "Structured Syntax Suffixes", IANA, "Structured Syntax Suffixes",
<https://www.iana.org/assignments/media-type-structured- <https://www.iana.org/assignments/media-type-structured-
suffix/>. suffix/>.
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-Yusef,
Dale R. Worley, Dhruv Dhody, Mohamed Boucadair, Mahesh Jethanandani,
Ketan Talaulikar, and Éric Vyncke provided valuable feedback for this
document.
Authors' Addresses Authors' Addresses
Jasdip Singh Jasdip Singh
ARIN ARIN
Email: jasdips@arin.net Email: jasdips@arin.net
Tom Harrison Tom Harrison
APNIC APNIC
Email: tomh@apnic.net Email: tomh@apnic.net
 End of changes. 59 change blocks. 
289 lines changed or deleted 149 lines changed or added

This html diff was produced by rfcdiff 1.48.