<?xml version="1.0" encoding="utf-8"?>
<!-- name="GENERATOR" content="github.com/mmarkdown/mmark Mmark Markdown Processor - mmark.miek.nl" -->
<rfc version="3" ipr="trust200902" docName="draft-ietf-regext-rdap-geofeed-01" submissionType="IETF" category="std" xml:lang="en" xmlns:xi="http://www.w3.org/2001/XInclude" indexInclude="true">

<front>
<title abbrev="rdap-geofeed">An RDAP Extension for Geofeed Data</title><seriesInfo value="draft-ietf-regext-rdap-geofeed-01" stream="IETF" status="standard" name="Internet-Draft"></seriesInfo>
<author initials="J." surname="Singh" fullname="Jasdip Singh"><organization>ARIN</organization><address><postal><street></street>
</postal><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>

<abstract>
<t>This document defines a new RDAP extension &quot;geofeed1&quot; for including a geofeed file URL in an IP Network object.</t>
</abstract>

</front>

<middle>

<section anchor="introduction"><name>Introduction</name>
<t><xref target="RFC8805"></xref> and <xref target="I-D.ymbk-opsawg-9092-update"></xref> (obsoletes <xref target="RFC9092"></xref>) detail the IP geolocation feed (in short,
geofeed) concept. This document specifies how the geofeed data can be accessed through RDAP. It defines a new RDAP
extension &quot;geofeed1&quot; for including a geofeed file URL in an IP Network object.</t>

<section anchor="requirements-language"><name>Requirements Language</name>
<t>The keywords &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;, and &quot;OPTIONAL&quot; in this document are to be interpreted as described in BCP 14
<xref target="RFC2119"></xref> <xref target="RFC8174"></xref> when, and only when, they appear in all capitals, as shown here.</t>
</section>
</section>

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

<section anchor="extension"><name>Extension</name>
<t>A new RDAP extension &quot;geofeed1&quot; is defined for accessing the geofeed data through RDAP. It updates the IP Network object
class definition (<xref target="RFC9083" sectionFormat="of" section="5.4"></xref>) to include a new link object for the geofeed file URL in its &quot;links&quot; array
(<xref target="RFC9083" sectionFormat="of" section="4.2"></xref>).</t>
<t>An RDAP server conforming to this specification MUST include the &quot;geofeed1&quot; extension string in the &quot;rdapConformance&quot;
array for the IP Network lookup and search responses, as well as in the help response.</t>
</section>

<section anchor="geofeed-link"><name>Geofeed Link</name>
<t>The IP Network object class (<xref target="RFC9083" sectionFormat="of" section="5.4"></xref>) MAY include a link object for the geofeed file URL (also referred
to as a Geofeed link object) in its &quot;links&quot; array, with the following REQUIRED JSON members:</t>

<ul spacing="compact">
<li>&quot;value&quot; -- The &quot;value&quot; JSON value is the context URI (<xref target="RFC9083" sectionFormat="of" section="4.2"></xref>).</li>
<li>&quot;rel&quot; -- The &quot;rel&quot; JSON value is the link relation type and set to the &quot;geo&quot; string. The &quot;geo&quot; link relation type is
new and will be registered in the IANA Link Relations Registry (see the &quot;Link Relations Registry&quot; section).</li>
<li>&quot;href&quot; -- The &quot;href&quot; JSON value is the target URI and set to the HTTPS URL of the geofeed file for the IP network.</li>
</ul>
<t>Per the definition of a web link (<xref target="RFC8288"></xref>), a Geofeed link object may have additional JSON members.
Specifically:</t>

<ul spacing="compact">
<li>&quot;type&quot; -- The &quot;type&quot; JSON value is the media type for the target URI. Given that the geofeed data is mostly intended
for use by automated/scripted processes, it is RECOMMENDED that server operators set a media type in Geofeed link
objects. See the &quot;Media Type for a Geofeed Link&quot; section for acceptable &quot;type&quot; values.</li>
<li>&quot;hreflang&quot; -- The &quot;hreflang&quot; JSON value is an attribute for the target URI and could be used to indicate the languages
the geofeed data is available in. It is OPTIONAL.</li>
</ul>
<t>There MAY be zero or more Geofeed link objects in the &quot;links&quot; array of an IP Network object. In other words, the Geofeed
link objects are OPTIONAL.</t>
</section>

<section anchor="media-type-for-a-geofeed-link"><name>Media Type for a Geofeed Link</name>
<t><xref target="I-D.ymbk-opsawg-9092-update"></xref> requires a geofeed file to be a UTF-8 CSV file, with a series of &quot;#&quot; comments at the end
for the optional RPKI signature. At first glance, the &quot;text/csv&quot; media type (<xref target="RFC7111" sectionFormat="of" section="5.1"></xref>) seems like a good
candidate to represent a geofeed file, but it does not support the &quot;#&quot; comments needed to include the RPKI signature.</t>
<t>To enable including &quot;#&quot; comments for an RPKI signature, a new media type &quot;application/geofeed+csv&quot; will be registered in
the IANA Media Types Registry (see the &quot;Media Types Registry&quot; section), and a new suffix &quot;+csv&quot; in the IANA Structured
Syntax Suffixes Registry (see the &quot;Structured Syntax Suffixes Registry&quot; section).</t>
<t>The &quot;type&quot; JSON value in a Geofeed link object SHOULD be set to the &quot;application/geofeed+csv&quot; media type.</t>
<t>If alternative geofeed formats are defined in the future, they could be included in future versions of this
specification.</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[{
    "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.net/geofeed",
            "type": "application/geofeed+csv"
        },
        ...
    ],
    ...
}
]]>
</artwork>
</section>
</section>

<section anchor="redaction"><name>Redaction</name>
<t>Since the Geofeed link objects in the &quot;links&quot; array of an IP Network object are optional, the Redaction by Removal
method <xref target="I-D.ietf-regext-rdap-redacted"></xref> MUST be used when redacting them. The following is an elided example of an IP
Network object with redacted Geofeed link objects:</t>

<artwork><![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"
        },
        ...
    ],
    "redacted":
    [
        {
            "name":
            {
                "description": "Geofeed links"
            },
            "prePath": "$.links[?(@.rel=='geo')]",
            "method": "removal"
        }
    ],
    ...
}
]]>
</artwork>
</section>

<section anchor="privacy-considerations"><name>Privacy Considerations</name>
<t>When including a geofeed file URL in an IP Network object, an RDAP server operator SHOULD follow the guidance from
<xref target="I-D.ymbk-opsawg-9092-update" sectionFormat="of" section="7"></xref> to not accidentally expose the location of an individual.</t>
</section>

<section anchor="security-considerations"><name>Security Considerations</name>
<t><xref target="I-D.ymbk-opsawg-9092-update"></xref> requires an HTTPS URL for a geofeed file, and optionally RPKI-signing the data within.
Besides that, this document does not introduce any new security considerations past those already discussed in the
RDAP protocol specifications.</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 the following value in the RDAP Extensions Registry:</t>

<ul spacing="compact">
<li>Extension identifier: geofeed1</li>
<li>Registry operator: Any</li>
<li>Published specification: This document.</li>
<li>Contact: IETF <eref target="mailto:iesg@ietf.org">iesg@ietf.org</eref></li>
<li>Intended usage: This extension describes version 1 of a method to access the IP geolocation feed data through RDAP.</li>
</ul>
</section>

<section anchor="link-relations-registry"><name>Link Relations Registry</name>
<t>IANA is requested to register the following value in the Link Relations Registry:</t>

<ul spacing="compact">
<li>Relation Name: geo</li>
<li>Description: Indicates that the link context has a resource with geographic information at the link target.</li>
<li>Reference: This document.</li>
</ul>
</section>

<section anchor="media-types-registry"><name>Media Types Registry</name>

<ul spacing="compact">
<li>Type name: application</li>
<li>Subtype name: geofeed+csv</li>
<li>Required parameters: N/A</li>
<li>Optional parameters: N/A</li>
<li>Encoding considerations: See <xref target="I-D.ymbk-opsawg-9092-update" sectionFormat="of" section="2"></xref>.</li>
<li>Security considerations: See the &quot;Security Considerations&quot; section of this document.</li>
<li>Interoperability considerations: There are no known interoperability problems regarding this media format.</li>
<li>Published specification: This document.</li>
<li>Applications that use this media type: Implementations of the Registration Data Access Protocol (RDAP) Extension for
Geofeed Data.</li>
<li>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 <eref target="https://datatracker.ietf.org/wg/regext/">https://datatracker.ietf.org/wg/regext/</eref>.</li>
<li>Person &amp; email address to contact for further information: IESG &lt;iesg&amp;ietf.org&gt;</li>
<li>Intended usage: COMMON</li>
<li>Restrictions on usage: None</li>
<li>Authors: Tom Harrison, Jasdip Singh</li>
<li>Change controller: IETF</li>
<li>Provisional Registration: No</li>
</ul>
</section>

<section anchor="structured-syntax-suffixes-registry"><name>Structured Syntax Suffixes Registry</name>

<ul>
<li>Name: Comma-Separated Values (CSV)</li>
<li>+suffix: +csv</li>
<li>References: <xref target="RFC4180"></xref>, <xref target="RFC7111"></xref></li>
<li>Encoding Considerations: Same as &quot;text/csv&quot;.</li>
<li>Interoperability Considerations: Same as &quot;text/csv&quot;.</li>
<li><t>Fragment Identifier Considerations:</t>
<t>The syntax and semantics of fragment identifiers specified for +csv SHOULD 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 be processed as follows:</t>
<t>For cases defined in +csv, where the fragment identifier resolves per the +csv rules, then as specified in +csv.</t>
<t>For cases defined in +csv, where the fragment identifier does not resolve per the +csv rules, then as specified in &quot;xxx/yyy+csv&quot;.</t>
<t>For cases not defined in +csv, then as specified in &quot;xxx/yyy+csv&quot;.</t>
</li>
<li><t>Security Considerations: Same as &quot;text/csv&quot;.</t>
</li>
<li><t>Contact: IETF <eref target="mailto:iesg@ietf.org">iesg@ietf.org</eref></t>
</li>
</ul>
</section>
</section>

<section anchor="acknowledgements"><name>Acknowledgements</name>
<t>Gavin Brown suggested using a web link instead of a simple URI string to specify a geofeed file URL.</t>
</section>

<section anchor="change-history"><name>Change History</name>

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

</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.4180.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.8174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8288.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.9083.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9092.xml"/>
</references>
<references><name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-regext-rdap-redacted.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ymbk-opsawg-9092-update.xml"/>
</references>
</references>

</back>

</rfc>
