<?xml version="1.0" encoding="utf-8"?>
<!-- name="GENERATOR" content="github.com/mmarkdown/mmark Mmark Markdown Processor - mmark.miek.nl" --> encoding="UTF-8"?>

<!DOCTYPE rfc [
 <!ENTITY nbsp    "&#160;">
 <!ENTITY zwsp   "&#8203;">
 <!ENTITY nbhy   "&#8209;">
 <!ENTITY wj     "&#8288;">
]>

<rfc version="3" ipr="trust200902" docName="draft-ietf-regext-rdap-geofeed-14" number="9877" updates="" obsoletes="" consensus="true" submissionType="IETF" category="std" xml:lang="en" xmlns:xi="http://www.w3.org/2001/XInclude" indexInclude="true"> tocInclude="true" symRefs="true" sortRefs="true">

<front>
  <title abbrev="rdap-geofeed">Registration abbrev="RDAP Geofeed">Registration Data Access Protocol (RDAP) Extension for Geofeed Data</title><seriesInfo value="draft-ietf-regext-rdap-geofeed-14" stream="IETF" status="standard" name="Internet-Draft"></seriesInfo> Data</title>
  <seriesInfo name="RFC" value="9877"/>
  <author initials="J." surname="Singh" fullname="Jasdip Singh"><organization>ARIN</organization><address><postal><street></street>
</postal><email>jasdips@arin.net</email>
</address></author><author Singh">
    <organization>ARIN</organization>
    <address>
      <email>jasdips@arin.net</email>
    </address>
  </author>
  <author initials="T." surname="Harrison" fullname="Tom Harrison"><organization>APNIC</organization><address><postal><street></street>
</postal><email>tomh@apnic.net</email>
</address></author><date/>
<area>Applications and Real-Time Area (ART)</area>
<workgroup>Registration Protocols Extensions (regext)</workgroup> Harrison">
    <organization>APNIC</organization>
    <address>
      <email>tomh@apnic.net</email>
    </address>
  </author>
  <date month="October" year="2025"/>
  <area>ART</area>
  <workgroup>regext</workgroup>

<!--[rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->

<keyword>example</keyword>

<abstract>
<t>This document defines a new Registration Data Access Protocol (RDAP) extension, &quot;geofeed1&quot;, 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.</t>
</abstract>

</front>

<middle>

<section anchor="introduction"><name>Introduction</name>
<t><xref target="RFC8805"></xref> and <xref target="RFC9632"></xref> detail the IP geolocation feed (commonly known as 'geofeed') file format and associated
access mechanisms. While <xref target="RFC9632"></xref> describes how a registry can make geofeed URLs available by way of a Routing
Policy Specification Language (RPSL) <xref target="RFC2622"></xref> service, the Regional Internet Registries (RIRs) have deployed
Registration Data Access Protocol (RDAP) (<xref target="RFC7480"></xref>, <xref target="RFC7481"></xref>, <xref target="RFC9082"></xref>, <xref target="RFC9083"></xref>) services as successors to
RPSL for 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, &quot;geofeed1&quot;, 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.</t>
<t>Fetching and making use of geofeed data is out of scope for the purposes of this document. See <xref target="RFC8805"></xref> and
<xref target="RFC9632"></xref> for further details.</t>
<t>The
        <t>
    The key words &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&quot;, &quot;SHALL&quot;, &quot;SHALL NOT&quot;, &quot;SHOULD&quot;, &quot;SHOULD NOT&quot;, &quot;RECOMMENDED&quot;,
&quot;NOT RECOMMENDED&quot;, &quot;MAY&quot;, "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
    "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and &quot;OPTIONAL&quot; "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"></xref> target="RFC2119"/> <xref target="RFC8174"></xref>
    target="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.</t> here.
        </t>
<t>Indentation and whitespace in examples are provided only to illustrate element relationships, and they are not a required
feature of this specification.</t>
<t>&quot;...&quot; in examples is used as shorthand for elements defined outside of this document.</t>
</section>

<section anchor="specification"><name>Specification</name>

<section anchor="media_type_for_a_geofeed_link"><name>Media Type for a Geofeed Link</name>
<t><xref target="RFC9632"></xref> requires a geofeed file to be a UTF-8 <xref target="RFC3629"></xref> comma-separated values (CSV) file, with a series of &quot;#&quot;
comments at the end for the optional Resource Public Key Infrastructure (RPKI, (RPKI) <xref target="RFC6480"></xref>) target="RFC6480"></xref> signature. At first glance,
the &quot;text/csv&quot; media type seems like a good candidate for a geofeed file, since it supports the &quot;#&quot; comments needed for
including the RPKI signature.</t>
<t>However, although the CSV geofeed data could be viewed directly by a user such that the &quot;text/csv&quot; 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 &quot;application&quot; media type with a &quot;geofeed&quot;
subtype (<xref target="RFC6838" sectionFormat="of" section="4.2.5"></xref>) for the geofeed data is preferable to using &quot;text/csv&quot;.</t>
<t>To that end, this document registers a new &quot;application/geofeed+csv&quot; media type in the IANA Media Types Registry "Media Types" registry (see
<xref target="media_types_registry"></xref>), and a new &quot;+csv&quot; suffix in the IANA Structured "Structured Syntax Suffixes Registry Suffixes" registry (see
<xref target="structured_syntax_suffixes_registry"></xref>).</t>
</section>

<section anchor="geofeed_link"><name>Geofeed Link</name>
<t>An RDAP server that hosts geofeed URLs for its IP network objects (<xref target="RFC9083" sectionFormat="of" section="5.4"></xref>) may include link objects
for those geofeed URLs in IP network objects in its responses. These link objects are added to the &quot;links&quot; member of
each object (<xref target="RFC9083" sectionFormat="of" section="4.2"></xref>).</t>
<t>In RDAP, the &quot;value&quot;, &quot;rel&quot;, and &quot;href&quot; JSON members are required for any link object. Additionally, for a geofeed link
object, the &quot;type&quot; JSON member is RECOMMENDED. <bcp14>RECOMMENDED</bcp14>. The geofeed-specific components of a link object are like so:</t>

<ul spacing="compact">
<li>&quot;rel&quot; -- The

<dl spacing="normal" newline="false">
  <dt>&quot;rel&quot;:</dt>
  <dd>The link relation type is set to &quot;geofeed&quot;. This is a new link
  relation type for IP geolocation feed data, registered in the IANA Link Relations Registry "Link
  Relations" registry (see <xref target="link_relations_registry"></xref>) by
  this document.</li>
<li>&quot;href&quot; -- The document.</dd>
  <dt>&quot;href&quot;:</dt>
  <dd>The target URL is set to the HTTPS URL of the geofeed file (<xref
  target="RFC9632" sectionFormat="of" section="6"></xref>) for an IP network.</li>
<li>&quot;type&quot; -- &quot;application/geofeed+csv&quot;
  network.</dd>
  <dt>&quot;type&quot;:</dt>
  <dd>&quot;application/geofeed+csv&quot; (see <xref target="media_type_for_a_geofeed_link"></xref>).</li>
</ul> target="media_type_for_a_geofeed_link"></xref>).</dd>
</dl>
<t>An IP network object returned by an RDAP server MAY <bcp14>MAY</bcp14> contain zero or more geofeed link objects, though typically an IP
network will have either no such link objects zero 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 <bcp14>SHOULD</bcp14>
provide &quot;hreflang&quot; members for the geofeed link objects. Except for the multiple-languages scenario, the server SHOULD
NOT <bcp14>SHOULD
NOT</bcp14> return more than one geofeed link object.</t>
</section>

<section anchor="extension-identifier"><name>Extension Identifier</name>
<t>This document defines a new extension identifier, &quot;geofeed1&quot;, 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 <xref target="geofeed_link"></xref>. A
server that uses this extension identifier MUST <bcp14>MUST</bcp14> include it in the &quot;rdapConformance&quot; array (<xref target="RFC9083" sectionFormat="of" section="4.1"></xref>) for
any lookup or search response containing an IP network object, as well as in the help response. Here is an elided
example for of this inclusion:</t>

<artwork><![CDATA[{

<sourcecode type="json"><![CDATA[{
    "rdapConformance": [ "rdap_level_0", "geofeed1", ... ],
    ...
}
]]></artwork>
}]]></sourcecode>
<t>If the server includes &quot;geofeed1&quot; in the &quot;rdapConformance&quot; 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. (i.e., the server is not
compelled to omit it due to regulatory constraints or similar), the server MUST <bcp14>MUST</bcp14> include a corresponding geofeed link
object in the response.</t>
<t>An RDAP server may make use of the &quot;application/geofeed+csv&quot; media type and the &quot;geofeed&quot; link relation defined in this
specification in its responses without including the &quot;geofeed1&quot; 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 &quot;rdapConformance&quot; 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.</t>
<t>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 accessible. This is the same way that as what the server does with the &quot;geofeed1&quot; extension identifier.</t>
<t>The &quot;1&quot; in &quot;geofeed1&quot; denotes that this is version 1 of the geofeed extension.  New versions of the geofeed extension
will use different extension identifiers.</t>
</section>

<section anchor="example"><name>Example</name>
<t>The following is an elided example of an IP network object with a geofeed link object:</t>

<artwork><![CDATA[{
<!--[rfced] Would you like to add text to explain usage of "XXXX-RIR"
and "YYYY-RIR", or is it sufficiently clear from the context?
Perhaps they are used to represent unique identifiers for two
different RIRs. (This notation is also used in RFCs 7483, 8521, and 9083.)

We note "xxx/yyy" is used later (Section 6.4) for a different purpose.

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

Perhaps:
   The following is an elided example of an IP network object with
   a geofeed link object, where "XXXX-RIR" and "YYYY-RIR"
   represent two different RIR handles:
-->
<sourcecode type="json"><![CDATA[{
    "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"
        },
        ...
    ],
    ...
}
]]></artwork>
}]]></sourcecode>
</section>
</section>

<section anchor="operational-considerations"><name>Operational Considerations</name>
<t>When an RDAP client performs an IP network lookup, per <xref target="RFC9082" sectionFormat="of" section="3.1.1"></xref>, 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.</t>
<!--[rfced] Would you like to update "inetnum object" to "inetnum: object"
(with a colon), as the latter is used in RFC 9632 (in most instances)?

Original:
   As with geofeed references in inetnum objects (per [RFC9632]), ...

Perhaps:
   As with geofeed references in inetnum: objects (per [RFC9632]), ...
-->
<t>It is common for a resource holder to maintain a single geofeed file containing the geofeed data for all of their
resources. The resource holder then updates each of their network object registrations to refer to that single geofeed
file. As with geofeed references in inetnum objects (per <xref target="RFC9632"></xref>), clients who find a geofeed link object within an
IP network object and opt to retrieve the data from the associated link MUST <bcp14>MUST</bcp14> ignore any entry where the entry's IP
address range is outside the IP network object's address range.</t>
<t><xref target="RFC8805" sectionFormat="of" section="3.2"></xref> recommends that consumers of geofeed data verify that the publisher of the data is
authoritative for the relevant resources. The RDAP bootstrap process (<xref target="RFC9224"></xref>) <xref target="RFC9224"></xref> 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.</t>
<t>To prevent undue load on RDAP and geofeed servers, clients fetching geofeed data using these mechanisms MUST NOT <bcp14>MUST NOT</bcp14> do
frequent real-time lookups. See <xref target="RFC9632" sectionFormat="of" section="6"></xref> for further details.</t>
</section>

<section anchor="privacy-considerations"><name>Privacy Considerations</name>
<t>All the privacy considerations from <xref target="RFC9632" sectionFormat="of" section="7"></xref> apply to this document. In particular, the service provider
publishing the geofeed file MUST <bcp14>MUST</bcp14> take care not to expose the location of any individual.</t>
<t>Many jurisdictions have laws or regulations that restrict the use of &quot;personal data&quot;, per the definition in <xref target="RFC6973"></xref>.
Given that, registry operators should ascertain whether the regulatory environment in which they operate permits
implementation of the functionality defined in this document.</t>
</section>

<section anchor="security_considerations"><name>Security Considerations</name>
<!--[rfced] Section 6 of [RFC9632] does contain security considerations,
but Section 9 of [RFC9632] is titled "Security Considerations".
Would you like to cite that section as well?

Original:
   Section 6 of [RFC9632] documents several security considerations that
   are equally relevant in the RDAP context.
-->
<t><xref target="RFC9632" sectionFormat="of" section="6"></xref> documents several security considerations that are equally relevant in the RDAP context.</t>
<t>A geofeed file MUST <bcp14>MUST</bcp14> be referenced with an HTTPS URL, per <xref target="RFC9632" sectionFormat="of" section="6"></xref>. The geofeed file may also contain an
RPKI signature, per <xref target="RFC9632" sectionFormat="of" section="5"></xref>.</t>
<t>Besides that, this document does not introduce any new security considerations past those already discussed in the RDAP
protocol specifications (<xref target="RFC7481"></xref>, <xref target="RFC9560"></xref>).</t>
</section>

<section anchor="iana-considerations"><name>IANA Considerations</name>

<section anchor="rdap-extensions-registry"><name>RDAP Extensions Registry</name>
<t>IANA is requested to register has registered the following value in the RDAP Extensions Registry "RDAP Extensions" registry at <xref target="RDAP-EXTENSIONS"></xref>:</t>

<ul

<dl spacing="compact">
<li>Extension identifier: geofeed1</li>
<li>Registry operator: Any</li>
<li>Published specification: This document.</li>
<li>Contact: IETF, iesg@ietf.org</li>
<li>Intended usage: This
  <dt>Extension Identifier:</dt><dd>geofeed1</dd>
  <dt>Registry Operator:</dt><dd>Any</dd>
  <dt>Specification:</dt><dd>RFC 9877</dd>
  <dt>Contact:</dt><dd>IETF &lt;iesg@ietf.org&gt;</dd>
  <dt>Intended Usage:</dt><dd>This extension describes version 1 of a method to access the IP geolocation feed data through RDAP.</li>
</ul> RDAP.</dd>
</dl>
</section>

<section anchor="link_relations_registry"><name>Link Relations Registry</name>
<t>IANA is requested to register has registered the following value in the Link Relations Registry "Link Relations" registry at <xref target="LINK-RELATIONS"></xref>:</t>

<ul

<dl spacing="compact">
<li>Relation Name: geofeed</li>
<li>Description: Refers
  <dt>Relation Name:</dt><dd>geofeed</dd>
  <dt>Description:</dt><dd>Refers to a resource with IP geofeed location information related to the link context.</li>
<li>Reference: This document.</li>
</ul> context.</dd>
  <dt>Reference:</dt><dd>RFC 9877</dd>
</dl>
</section>

<section anchor="media_types_registry"><name>Media Types Registry</name>
<t>IANA is requested to register has registered the following value media type in the Media Types Registry "Media Types" registry at <xref target="MEDIA-TYPES"></xref>:</t>

<ul spacing="compact">
<li>Type name: application</li>
<li>Subtype name: geofeed+csv</li>
<li>Required parameters: N/A</li>
<li>Optional parameters: &quot;charset&quot;

<dl spacing="normal" newline="false">
  <dt>Type name:</dt><dd>application</dd>
  <dt>Subtype name:</dt><dd>geofeed+csv</dd>
  <dt>Required parameters:</dt><dd>N/A</dd>
  <dt>Optional parameters:</dt><dd>&quot;charset&quot; is an optional
  parameter for &quot;text/csv&quot;, but it is not used for
  &quot;application/geofeed+csv&quot; because the geofeed content is always in
  UTF-8 (<xref target="RFC8805" sectionFormat="of" section="2.1"></xref>).</li>
<li>Encoding considerations: See
  section="2.1"></xref>).</dd>
  <dt>Encoding considerations:</dt><dd>See <xref target="RFC9632" sectionFormat="of" section="2"></xref>.</li>
<li>Security considerations: See section="2"></xref>.</dd>
  <dt>Security considerations:</dt><dd>See <xref target="security_considerations"></xref> of this document.</li>
<li>Interoperability considerations: There RFC 9877.</dd>
  <dt>Interoperability considerations:</dt><dd>There are no known interoperability problems regarding this media format.</li>
<li>Published specification: This document.</li>
<li>Applications format.</dd>
  <dt>Published specification:</dt><dd>RFC 9877.</dd>
  <dt>Applications that use this media type: Implementations type:</dt><dd>Implementations of the
  Registration Data Access Protocol (RDAP) Extension for Geofeed
  Data. Furthermore, any application that processes the CSV geofeed data.</li>
<li>Additional information: This data.</dd>
  <dt>Additional information:</dt><dd>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 <xref target="REGEXT"></xref>.</li>
<li>Person target="REGEXT"></xref>.</dd>
  <dt>Person &amp; email address to contact for further information: REGEXT information:</dt><dd><br/>REGEXT Working Group, regext@ietf.org</li>
<li>Intended usage: COMMON</li>
<li>Restrictions Group &lt;regext@ietf.org&gt;</dd>
  <dt>Intended usage:</dt><dd>COMMON</dd>
  <dt>Restrictions on usage: None</li>
<li>Authors: Tom usage:</dt><dd>None</dd>
  <dt>Authors:</dt><dd>Tom Harrison, Jasdip Singh</li>
<li>Author/Change controller: IETF</li>
<li>Provisional Registration: No</li>
</ul> Singh</dd>
  <dt>Author/Change controller:</dt><dd>IETF</dd>
</dl>
</section>

<section anchor="structured_syntax_suffixes_registry"><name>Structured Syntax Suffixes Registry</name>
<t>IANA is requested to register has registered the following value in the Structured "Structured Syntax Suffixes Registry Suffixes" registry
at <xref target="STRUCTURED-SYNTAX-SUFFIXES"></xref>:</t>

<ul>
<li>Name: Comma-Separated

<dl spacing="normal" newline="false">
  <dt>Name:</dt><dd>Comma-Separated Values (CSV)</li>
<li>+suffix: +csv</li>
<li>References: <xref (CSV)</dd>
  <dt>+suffix:</dt><dd>+csv</dd>
  <dt>References:</dt><dd><xref target="RFC4180"></xref>, <xref target="RFC7111"></xref></li>
<li>Encoding Considerations: Same as &quot;text/csv&quot;.</li>
<li>Interoperability Considerations: Same target="RFC7111"></xref></dd>
  <dt>Encoding Considerations:</dt><dd>Same as &quot;text/csv&quot;.</dd>
  <dt>Interoperability Considerations:</dt><dd>Same as &quot;text/csv&quot;.</li>
<li><t>Fragment &quot;text/csv&quot;.</dd>
  <dt>Fragment Identifier Considerations:</t>
<t>The Considerations:</dt>
  <dd><t>The syntax and semantics of fragment identifiers specified for +csv SHOULD <bcp14>SHOULD</bcp14> be as specified for &quot;text/csv&quot;.</t>
  <t>The syntax and semantics for fragment identifiers for a specific &quot;xxx/yyy+csv&quot; SHOULD <bcp14>SHOULD</bcp14> be processed as follows:</t>
<t>For
  <ul spacing="compact">
    <li>For cases defined in +csv, where the fragment identifier resolves per
    the +csv rules, then as specified for +csv.</t>
<t>For +csv.</li> <li>For cases defined in
    +csv, where the fragment identifier does not resolve per the +csv rules,
    then as specified for &quot;xxx/yyy+csv&quot;.</t>
<t>For &quot;xxx/&wj;yyy+csv&quot;.</li>
    <li>For cases not defined in +csv, then as specified for &quot;xxx/yyy+csv&quot;.</t>
</li>
<li><t>Security Considerations: Same as &quot;text/csv&quot;.</t>
</li>
<li><t>Contact: IETF, iesg@ietf.org</t>
</li>
<li><t>Author/Change controller: IETF</t>
</li>
</ul>
</section>
</section>

<section anchor="implementation-status"><name>Implementation Status</name>
<t>(Remove this section before publication.)</t>
<t>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 <xref target="RFC7942"></xref>. 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.</t>
<t>According to RFC 7942, &quot;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&quot;.</t>

<section anchor="ripe-ncc"><name>RIPE NCC</name>

<ul spacing="compact">
<li>Responsible Organization: RIPE NCC</li>
<li>Location: <eref target="https://docs.db.ripe.net/Release-Notes/#ripe-database-release-1-110">https://docs.db.ripe.net/Release-Notes/#ripe-database-release-1-110</eref></li>
<li>Description: An RDAP server returning geofeed data.</li>
<li>Level of Maturity: This is a production implementation.</li>
<li>Coverage: This implementation covers all the features described in version 01 of this specification.</li>
<li>Contact Information: Ed Shryane, eshryane@ripe.net</li>
</ul>
</section>
</section>

<section anchor="acknowledgements"><name>Acknowledgements</name>
<t>Mark Kosters provided initial support and encouragement for this work, along with the <xref target="RFC9632"></xref> 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.</t>
</section>

<section anchor="change-history"><name>Change History</name>
<t>(Remove this section before publication.)</t>

<section anchor="changes-from-00-to-01"><name>Changes from 00 to 01</name>

<ul spacing="compact">
<li>Now using a web link instead of a simple URL string to specify a geofeed file URL.</li>
<li>Renamed the extension as &quot;geofeed1&quot; instead of &quot;geofeedv1&quot;.</li>
<li>Introduced the new &quot;geo&quot; link relation type.</li>
<li>Introduced the new &quot;application/geofeed+csv&quot; media type.</li>
</ul>
</section>

<section anchor="changes-from-01-to-02"><name>Changes from 01 to 02</name>

<ul spacing="compact">
<li>Updated the &quot;Requirements Language&quot; section for examples.</li>
<li>Added an example for RDAP conformance.</li>
<li>Updated the rationale for using the new &quot;application/geofeed+csv&quot; media type.</li>
<li>Updated the &quot;Applications that use this media type&quot; section for the &quot;application/geofeed+csv&quot; registration.</li>
</ul>
</section>

<section anchor="changes-from-02-to-03"><name>Changes from 02 to 03</name>

<ul spacing="compact">
<li>Removed &quot;value&quot; and &quot;hreflang&quot; explanations from the &quot;Geofeed Link&quot; section. Further, clarified the cardinality of
geofeed link objects.</li>
<li>Updated extensibility verbiage in the &quot;Media Type for a Geofeed Link&quot; section.</li>
<li>In the &quot;Example&quot; section, updated the domain in &quot;href&quot; of the geofeed link object to contrast with the domain in
&quot;value&quot; to highlight that &quot;href&quot; is for a geofeed file hosted at a network operator site whereas &quot;value&quot; is for an IP
network object from an RDAP server.</li>
<li>Removed the &quot;Redaction&quot; section since the geofeed files are public to start with.</li>
<li>Added URLs for various IANA registries.</li>
</ul>
</section>

<section anchor="changes-from-03-to-04"><name>Changes from 03 to 04</name>

<ul spacing="compact">
<li>Updated the criteria for including the extension identifier in &quot;rdapConformance&quot;.</li>
</ul>
</section>

<section anchor="changes-from-04-to-05"><name>Changes from 04 to 05</name>

<ul spacing="compact">
<li>Made various editorial changes.</li>
</ul>
</section>

<section anchor="changes-from-05-to-06"><name>Changes from 05 to 06</name>

<ul spacing="compact">
<li>The extension identifier inclusion is now a must.</li>
<li>Added the &quot;Operational Considerations&quot; section to clarify the geofeed file and IP networks relationship, as well as
how RDAP Bootstrap helps with a recommendation from RFC 8805.</li>
<li>Updated the &quot;Privacy Considerations&quot; section to clarify the service provider responsibility.</li>
</ul>
</section>

<section anchor="changes-from-06-to-07"><name>Changes from 06 to 07</name>

<ul spacing="compact">
<li>Updated the extension identifier text so as to clarify that the media type and link relation can be used independently
of that identifier.</li>
</ul>
</section>

<section anchor="changes-from-07-to-08"><name>Changes from 07 to 08</name>

<ul spacing="compact">
<li>Added the &quot;Implementation Status&quot; section.</li>
<li>Updated references.</li>
</ul>
</section>

<section anchor="changes-from-08-to-09"><name>Changes from 08 to 09</name>

<ul spacing="compact">
<li>Incorporated feedback from the AD review.</li>
<li>Incorporated feedback from the media type review.</li>
<li>RFCs 4180, 7111, and 8805 are now normative references.</li>
<li>Made minor editorial changes.</li>
</ul>
</section>

<section anchor="changes-from-09-to-10"><name>Changes from 09 to 10</name>

<ul spacing="compact">
<li>Incorporated feedback from the IESG review.</li>
</ul>
</section>

<section anchor="changes-from-10-to-11"><name>Changes from 10 to 11</name>

<ul spacing="compact">
<li>Incorporated feedback from the IESG review.</li>
</ul>
</section>

<section anchor="changes-from-11-to-12"><name>Changes from 11 to 12</name>

<ul spacing="compact">
<li>Incorporated feedback from the IESG review.</li>
</ul>
</section>

<section anchor="changes-from-12-to-13"><name>Changes from 12 to 13</name>

<ul spacing="compact">
<li>Incorporated feedback from the IESG review.</li>
</ul>
</section>

<section anchor="changes-from-13-to-14"><name>Changes from 13 to 14</name>

<ul spacing="compact">
<li>Incorporated feedback from the IESG review.</li>
</ul> &quot;xxx/&wj;yyy+csv&quot;.</li>
  </ul></dd>
  <dt>Security Considerations:</dt><dd>Same as &quot;text/csv&quot;.</dd>
  <dt>Contact:</dt><dd>IETF &lt;iesg@ietf.org&gt;</dd>
  <dt>Author/Change controller:</dt><dd>IETF</dd>
</dl>
</section>
</section>

</middle>

<back>
<references><name>References</name>
<references><name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3629.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9082.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9083.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9224.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9632.xml"/>
</references>
<references><name>Informative References</name>
<reference anchor="LINK-RELATIONS" target="https://www.iana.org/assignments/link-relations/">
  <front>
    <title>Link Relations</title>
    <author>
      <organization>IANA</organization>
    </author>
  </front>
</reference>
<reference anchor="MEDIA-TYPES" target="https://www.iana.org/assignments/media-types/">
  <front>
    <title>Media Types</title>
    <author>
      <organization>IANA</organization>
    </author>
  </front>
</reference>
<reference anchor="RDAP-EXTENSIONS" target="https://www.iana.org/assignments/rdap-extensions/">
  <front>
    <title>RDAP Extensions</title>
    <author>
      <organization>IANA</organization>
    </author>
  </front>
</reference>
<reference anchor="REGEXT" target="https://datatracker.ietf.org/wg/regext/">
  <front>
    <title>Registration Protocols Extensions</title> Extensions (regext)</title>
    <author>
      <organization>IETF</organization>
    </author>
  </front>
</reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2622.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4180.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6480.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6838.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6973.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7111.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7480.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7481.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7942.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8805.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9560.xml"/>
<reference anchor="STRUCTURED-SYNTAX-SUFFIXES" target="https://www.iana.org/assignments/media-type-structured-suffix/">
  <front>
    <title>Structured Syntax Suffixes</title>
    <author>
      <organization>IANA</organization>
    </author>
  </front>
</reference>
</references>
</references>

<section anchor="acknowledgements" numbered="false"><name>Acknowledgements</name>
<t><contact fullname="Mark Kosters"/> provided initial support and
encouragement for this work, along with the <xref target="RFC9632"></xref>
authors. <contact fullname="Gavin Brown"/> suggested using a web link instead
of a simple URL string to specify a geofeed file URL. <contact fullname="Andy
Newton"/>, <contact fullname="James Gould"/>, <contact fullname="Scott
Hollenbeck"/>, <contact fullname="Mario Loffredo"/>, <contact fullname="Orie
Steele"/>, <contact fullname="Alexey Melnikov"/>, <contact fullname="Mark
Nottingham"/>, <contact fullname="Rifaat Shekh-Yusef"/>, <contact
fullname="Dale R. Worley"/>, <contact fullname="Dhruv Dhody"/>, <contact
fullname="Mohamed Boucadair"/>, <contact fullname="Mahesh Jethanandani"/>,
<contact fullname="Ketan Talaulikar"/>, and <contact fullname="Éric Vyncke"/>
provided valuable feedback for this document.</t>
</section>

</back>

<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.  Updates of this nature typically
result in more precise language, which is helpful for readers.

Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->

</rfc>