Diff: rfc9877.original.xml

	rfc9877.original.xml	rfc9877.xml

	<?xml version="1.0" encoding="utf-8"?>	<?xml version="1.0" encoding="UTF-8"?>
	<!-- name="GENERATOR" content="github.com/mmarkdown/mmark Mmark Markdown Process
	or - mmark.miek.nl" -->	<!DOCTYPE rfc [
	<rfc version="3" ipr="trust200902" docName="draft-ietf-regext-rdap-geofeed-14" s	<!ENTITY nbsp " ">
	ubmissionType="IETF" category="std" xml:lang="en" xmlns:xi="http://www.w3.org/20	<!ENTITY zwsp "">
	01/XInclude" indexInclude="true">	<!ENTITY nbhy "‑">
		<!ENTITY wj "⁠">
		]>

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

	<front>	<front>

	<title abbrev="rdap-geofeed">Registration Data Access Protocol (RDAP) Extension	<title abbrev="RDAP Geofeed">Registration Data Access Protocol (RDAP) Extensio
	for Geofeed Data</title><seriesInfo value="draft-ietf-regext-rdap-geofeed-14" st	n for Geofeed Data</title>
	ream="IETF" status="standard" name="Internet-Draft"></seriesInfo>	<seriesInfo name="RFC" value="9877"/>
	<author initials="J." surname="Singh" fullname="Jasdip Singh"><organization>ARIN	<author initials="J." surname="Singh" fullname="Jasdip Singh">
	</organization><address><postal><street></street>	<organization>ARIN</organization>
	</postal><email>jasdips@arin.net</email>	<address>
	</address></author><author initials="T." surname="Harrison" fullname="Tom Harris	<email>jasdips@arin.net</email>
	on"><organization>APNIC</organization><address><postal><street></street>	</address>
	</postal><email>tomh@apnic.net</email>	</author>
	</address></author><date/>	<author initials="T." surname="Harrison" fullname="Tom Harrison">
	<area>Applications and Real-Time Area (ART)</area>	<organization>APNIC</organization>
	<workgroup>Registration Protocols Extensions (regext)</workgroup>	<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>	<abstract>
	<t>This document defines a new Registration Data Access Protocol (RDAP) extensio n, "geofeed1", for indicating that an RDAP	<t>This document defines a new Registration Data Access Protocol (RDAP) extensio n, "geofeed1", for indicating that an RDAP
	server hosts geofeed URLs for its IP network objects. It also defines a new medi a type and a new link relation type for	server hosts geofeed URLs for its IP network objects. It also defines a new medi a type and a new link relation type for
	the associated link objects included in responses.</t>	the associated link objects included in responses.</t>
	</abstract>	</abstract>

	</front>	</front>

	<middle>	<middle>

	skipping to change at line 36 ¶	skipping to change at line 57 ¶
	<t><xref target="RFC8805"></xref> and <xref target="RFC9632"></xref> detail the IP geolocation feed (commonly known as 'geofeed') file format and associated	<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	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	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	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	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 specifi es how geofeed URLs can be accessed	transition from RPSL to RDAP in this context. To that end, this document specifi es how geofeed URLs can be accessed
	through RDAP. It defines a new RDAP extension, "geofeed1", for indicat ing that an RDAP server hosts geofeed URLs for its	through RDAP. It defines a new RDAP extension, "geofeed1", for indicat ing 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>	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 t his document. See <xref target="RFC8805"></xref> and	<t>Fetching and making use of geofeed data is out of scope for the purposes of t his document. See <xref target="RFC8805"></xref> and
	<xref target="RFC9632"></xref> for further details.</t>	<xref target="RFC9632"></xref> for further details.</t>

	<t>The key words "MUST", "MUST NOT", "REQUIRED", &	<t>
	quot;SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT&qu	The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
	ot;, "RECOMMENDED",	"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
	"NOT RECOMMENDED", "MAY", and "OPTIONAL" in this d	",
	ocument are to be interpreted as described in BCP 14	"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
	<xref target="RFC2119"></xref> <xref target="RFC8174"></xref> when, and only whe	"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	n, they appear in all capitals, as shown here.</t>	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
	<t>Indentation and whitespace in examples are provided only to illustrate elemen	be
	t relationships, and are not a required	interpreted as described in BCP 14 <xref target="RFC2119"/> <xref
		target="RFC8174"/> when, and only when, they appear in all capitals, as
		shown here.
		</t>
		<t>Indentation and whitespace in examples are provided only to illustrate elemen
		t relationships, and they are not a required
	feature of this specification.</t>	feature of this specification.</t>
	<t>"..." in examples is used as shorthand for elements defined outside of this document.</t>	<t>"..." in examples is used as shorthand for elements defined outside of this document.</t>
	</section>	</section>

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

	<section anchor="media_type_for_a_geofeed_link"><name>Media Type for a Geofeed L ink</name>	<section anchor="media_type_for_a_geofeed_link"><name>Media Type for a Geofeed L ink</name>
	<t><xref target="RFC9632"></xref> requires a geofeed file to be a UTF-8 <xref ta rget="RFC3629"></xref> comma-separated values (CSV) file, with a series of &quot ;#"	<t><xref target="RFC9632"></xref> requires a geofeed file to be a UTF-8 <xref ta rget="RFC3629"></xref> comma-separated values (CSV) file, with a series of &quot ;#"

	comments at the end for the optional Resource Public Key Infrastructure (RPKI, < xref target="RFC6480"></xref>) signature. At first glance,	comments at the end for the optional Resource Public Key Infrastructure (RPKI) < xref target="RFC6480"></xref> signature. At first glance,
	the "text/csv" media type seems like a good candidate for a geofeed fi le, since it supports the "#" comments needed for	the "text/csv" media type seems like a good candidate for a geofeed fi le, since it supports the "#" comments needed for
	including the RPKI signature.</t>	including the RPKI signature.</t>
	<t>However, although the CSV geofeed data could be viewed directly by a user suc h that the "text/csv" media type was	<t>However, although the CSV geofeed data could be viewed directly by a user suc h that the "text/csv" media type was
	appropriate, the most common use case will involve it being processed by some so rt of application first, in order to	appropriate, the most common use case will involve it being processed by some so rt of application first, in order to
	facilitate subsequent IP address lookup operations. Therefore, using a new &quot ;application" media type with a "geofeed"	facilitate subsequent IP address lookup operations. Therefore, using a new &quot ;application" media type with a "geofeed"
	subtype (<xref target="RFC6838" sectionFormat="of" section="4.2.5"></xref>) for the geofeed data is preferable to using "text/csv".</t>	subtype (<xref target="RFC6838" sectionFormat="of" section="4.2.5"></xref>) for the geofeed data is preferable to using "text/csv".</t>

	<t>To that end, this document registers a new "application/geofeed+csv&quot	<t>To that end, this document registers a new "application/geofeed+csv&quot
	; media type in the IANA Media Types Registry (see	; media type in the IANA "Media Types" registry (see
	<xref target="media_types_registry"></xref>), and a new "+csv" suffix	<xref target="media_types_registry"></xref>), and a new "+csv" suffix
	in the IANA Structured Syntax Suffixes Registry (see	in the IANA "Structured Syntax Suffixes" registry (see
	<xref target="structured_syntax_suffixes_registry"></xref>).</t>	<xref target="structured_syntax_suffixes_registry"></xref>).</t>
	</section>	</section>

	<section anchor="geofeed_link"><name>Geofeed Link</name>	<section anchor="geofeed_link"><name>Geofeed Link</name>
	<t>An RDAP server that hosts geofeed URLs for its IP network objects (<xref targ et="RFC9083" sectionFormat="of" section="5.4"></xref>) may include link objects	<t>An RDAP server that hosts geofeed URLs for its IP network objects (<xref targ et="RFC9083" sectionFormat="of" section="5.4"></xref>) may include link objects
	for those geofeed URLs in IP network objects in its responses. These link object s are added to the "links" member of	for those geofeed URLs in IP network objects in its responses. These link object s are added to the "links" member of
	each object (<xref target="RFC9083" sectionFormat="of" section="4.2"></xref>).</ t>	each object (<xref target="RFC9083" sectionFormat="of" section="4.2"></xref>).</ t>
	<t>In RDAP, the "value", "rel", and "href" JSON me mbers are required for any link object. Additionally, for a geofeed link	<t>In RDAP, the "value", "rel", and "href" JSON me mbers are required for any link object. Additionally, for a geofeed link

	object, the "type" JSON member is RECOMMENDED. The geofeed-specific co mponents of a link object are like so:</t>	object, the "type" JSON member is <bcp14>RECOMMENDED</bcp14>. The geof eed-specific components of a link object are like so:</t>


	<ul spacing="compact">	<dl spacing="normal" newline="false">
	<li>"rel" -- The link relation type is set to "geofeed". Thi	<dt>"rel":</dt>
	s is a new link relation type for IP geolocation feed data,	<dd>The link relation type is set to "geofeed". This is a new link
	registered in the IANA Link Relations Registry (see <xref target="link_relations	relation type for IP geolocation feed data, registered in the IANA "Link
	_registry"></xref>) by this document.</li>	Relations" registry (see <xref target="link_relations_registry"></xref>) by
	<li>"href" -- The target URL is set to the HTTPS URL of the geofeed fi	this document.</dd>
	le (<xref target="RFC9632" sectionFormat="of" section="6"></xref>) for an IP net	<dt>"href":</dt>
	work.</li>	<dd>The target URL is set to the HTTPS URL of the geofeed file (<xref
	<li>"type" -- "application/geofeed+csv" (see <xref target="m	target="RFC9632" sectionFormat="of" section="6"></xref>) for an IP
	edia_type_for_a_geofeed_link"></xref>).</li>	network.</dd>
	</ul>	<dt>"type":</dt>
	<t>An IP network object returned by an RDAP server MAY contain zero or more geof	<dd>"application/geofeed+csv" (see <xref target="media_type_for_a_ge
	eed link objects, though typically an IP	ofeed_link"></xref>).</dd>
	network will have either no such link objects or only one. The scenario where mo	</dl>
	re than one geofeed link object could be	<t>An IP network object returned by an RDAP server <bcp14>MAY</bcp14> contain ze
	returned is when the server is able to represent that data in multiple languages	ro or more geofeed link objects, though typically an IP
	. In such a case, the server SHOULD	network will have either zero or only one. The scenario where more than one geof
	provide "hreflang" members for the geofeed link objects. Except for th	eed link object could be
	e multiple-languages scenario, the server SHOULD	returned is when the server is able to represent that data in multiple languages
	NOT return more than one geofeed link object.</t>	. In such a case, the server <bcp14>SHOULD</bcp14>
		provide "hreflang" members for the geofeed link objects. Except for th
		e multiple-languages scenario, the server <bcp14>SHOULD
		NOT</bcp14> return more than one geofeed link object.</t>
	</section>	</section>

	<section anchor="extension-identifier"><name>Extension Identifier</name>	<section anchor="extension-identifier"><name>Extension Identifier</name>
	<t>This document defines a new extension identifier, "geofeed1", for u se by servers that host geofeed URLs for their IP	<t>This document defines a new extension identifier, "geofeed1", for u se by servers that host geofeed URLs for their IP
	network objects and include geofeed URL link objects in their responses to clien ts in accordance with <xref target="geofeed_link"></xref>. A	network objects and include geofeed URL link objects in their responses to clien ts in accordance with <xref target="geofeed_link"></xref>. A

	server that uses this extension identifier MUST include it in the "rdapConf ormance" array (<xref target="RFC9083" sectionFormat="of" section="4.1"></x ref>) for	server that uses this extension identifier <bcp14>MUST</bcp14> include it in the "rdapConformance" array (<xref target="RFC9083" sectionFormat="of" se ction="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	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:</t>	example of this inclusion:</t>


	<artwork><![CDATA[{	<sourcecode type="json"><![CDATA[{
	"rdapConformance": [ "rdap_level_0", "geofeed1", ... ],	"rdapConformance": [ "rdap_level_0", "geofeed1", ... ],
	...	...

	}	}]]></sourcecode>
	]]></artwork>
	<t>If the server includes "geofeed1" in the "rdapConformance&quot ; array, then for any response concerning a particular IP	<t>If the server includes "geofeed1" in the "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 retur	network object for which the server possesses a geofeed URL and is able to retur
	n it to the client (i.e. is not	n it to the client (i.e., the server is not
	compelled to omit it due to regulatory constraints or similar), the server MUST	compelled to omit it due to regulatory constraints or similar), the server <bcp1
	include a corresponding geofeed link	4>MUST</bcp14> include a corresponding geofeed link
	object in the response.</t>	object in the response.</t>
	<t>An RDAP server may make use of the "application/geofeed+csv" media type and the "geofeed" link relation defined in this	<t>An RDAP server may make use of the "application/geofeed+csv" media type and the "geofeed" link relation defined in this
	specification in its responses without including the "geofeed1" extens ion identifier in those responses, because RDAP	specification in its responses without including the "geofeed1" extens ion 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	servers are free to use any registered media type or link relation in a standard response without implementing any
	particular extension. The additional value of including the extension identifier in the "rdapConformance" array is that	particular extension. The additional value of including the extension identifier in the "rdapConformance" array is that
	it signals to the client that the server hosts geofeed URLs for its IP network o bjects. This is useful where a client	it signals to the client that the server hosts geofeed URLs for its IP network o bjects. This is useful where a client
	receives an IP network object without a geofeed link object, because in that cas e the client can infer that no geofeed	receives an IP network object without a geofeed link object, because in that cas e 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>	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	<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	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 "geofee d1" extension identifier.</t>	that type accessible. This is the same as what the server does with the "ge ofeed1" extension identifier.</t>
	<t>The "1" in "geofeed1" denotes that this is version 1 of t he geofeed extension. New versions of the geofeed extension	<t>The "1" in "geofeed1" denotes that this is version 1 of t he geofeed extension. New versions of the geofeed extension
	will use different extension identifiers.</t>	will use different extension identifiers.</t>
	</section>	</section>

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

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


	<artwork><![CDATA[{	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",	"objectClassName": "ip network",
	"handle": "XXXX-RIR",	"handle": "XXXX-RIR",
	"startAddress": "2001:db8::",	"startAddress": "2001:db8::",
	"endAddress": "2001:db8:0:ffff:ffff:ffff:ffff:ffff",	"endAddress": "2001:db8:0:ffff:ffff:ffff:ffff:ffff",
	"ipVersion": "v6",	"ipVersion": "v6",
	"name": "NET-RTR-1",	"name": "NET-RTR-1",
	"type": "DIRECT ALLOCATION",	"type": "DIRECT ALLOCATION",
	"country": "AU",	"country": "AU",
	"parentHandle": "YYYY-RIR",	"parentHandle": "YYYY-RIR",
	"status": [ "active" ],	"status": [ "active" ],

	skipping to change at line 141 ¶	skipping to change at line 190 ¶
	},	},
	{	{
	"value": "https://example.net/ip/2001:db8::/48",	"value": "https://example.net/ip/2001:db8::/48",
	"rel": "geofeed",	"rel": "geofeed",
	"href": "https://example.com/geofeed",	"href": "https://example.com/geofeed",
	"type": "application/geofeed+csv"	"type": "application/geofeed+csv"
	},	},
	...	...
	],	],
	...	...

	}	}]]></sourcecode>
	]]></artwork>
	</section>	</section>
	</section>	</section>

	<section anchor="operational-considerations"><name>Operational Considerations</n ame>	<section anchor="operational-considerations"><name>Operational Considerations</n ame>
	<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 retu rn	<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 retu rn
	the most-specific IP network object that covers the IP address range provided by the client. That IP network object may	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.	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 RDA P should consider whether to retrieve	Clients attempting to retrieve geofeed data for a given IP address range via RDA P 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	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 opt ions for resource holders in order to	contain geofeed data. Conversely, server operators should consider interface opt ions for resource holders in order to
	support the provisioning of geofeed links for all networks covered by the associ ated data.</t>	support the provisioning of geofeed links for all networks covered by the associ ated 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 containi ng the geofeed data for all of their	<t>It is common for a resource holder to maintain a single geofeed file containi ng the geofeed data for all of their
	resources. The resource holder then updates each of their network object registr ations to refer to that single geofeed	resources. The resource holder then updates each of their network object registr ations 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	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 ign ore any entry where the entry's IP	IP network object and opt to retrieve the data from the associated link <bcp14>M UST</bcp14> ignore any entry where the entry's IP
	address range is outside the IP network object's address range.</t>	address range is outside the IP network object's address range.</t>
	<t><xref target="RFC8805" sectionFormat="of" section="3.2"></xref> recommends th at consumers of geofeed data verify that the publisher of the data is	<t><xref target="RFC8805" sectionFormat="of" section="3.2"></xref> recommends th at consumers of geofeed data verify that the publisher of the data is

	authoritative for the relevant resources. The RDAP bootstrap process (<xref targ et="RFC9224"></xref>) helps clients with this	authoritative for the relevant resources. The RDAP bootstrap process <xref targe t="RFC9224"></xref> helps clients with this
	recommendation, since a client following that process will be directed to the RD AP server that is able to make	recommendation, since a client following that process will be directed to the RD AP server that is able to make
	authoritative statements about the disposition of the relevant resources.</t>	authoritative statements about the disposition of the relevant resources.</t>

	<t>To prevent undue load on RDAP and geofeed servers, clients fetching geofeed d ata using these mechanisms MUST NOT do	<t>To prevent undue load on RDAP and geofeed servers, clients fetching geofeed d ata using these mechanisms <bcp14>MUST NOT</bcp14> do
	frequent real-time lookups. See <xref target="RFC9632" sectionFormat="of" sectio n="6"></xref> for further details.</t>	frequent real-time lookups. See <xref target="RFC9632" sectionFormat="of" sectio n="6"></xref> for further details.</t>
	</section>	</section>

	<section anchor="privacy-considerations"><name>Privacy Considerations</name>	<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	<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 take care not to expose the location of any ind ividual.</t>	publishing the geofeed file <bcp14>MUST</bcp14> take care not to expose the loca tion of any individual.</t>
	<t>Many jurisdictions have laws or regulations that restrict the use of "pe rsonal data", per the definition in <xref target="RFC6973"></xref>.	<t>Many jurisdictions have laws or regulations that restrict the use of "pe rsonal data", per the definition in <xref target="RFC6973"></xref>.
	Given that, registry operators should ascertain whether the regulatory environme nt in which they operate permits	Given that, registry operators should ascertain whether the regulatory environme nt in which they operate permits
	implementation of the functionality defined in this document.</t>	implementation of the functionality defined in this document.</t>
	</section>	</section>

	<section anchor="security_considerations"><name>Security Considerations</name>	<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 sever al security considerations that are equally relevant in the RDAP context.</t>	<t><xref target="RFC9632" sectionFormat="of" section="6"></xref> documents sever al security considerations that are equally relevant in the RDAP context.</t>

	<t>A geofeed file MUST be referenced with an HTTPS URL, per <xref target="RFC963 2" sectionFormat="of" section="6"></xref>. The geofeed file may also contain an	<t>A geofeed file <bcp14>MUST</bcp14> be referenced with an HTTPS URL, per <xref target="RFC9632" sectionFormat="of" section="6"></xref>. The geofeed file may a lso contain an
	RPKI signature, per <xref target="RFC9632" sectionFormat="of" section="5"></xref >.</t>	RPKI signature, per <xref target="RFC9632" sectionFormat="of" section="5"></xref >.</t>
	<t>Besides that, this document does not introduce any new security consideration s past those already discussed in the RDAP	<t>Besides that, this document does not introduce any new security consideration s past those already discussed in the RDAP
	protocol specifications (<xref target="RFC7481"></xref>, <xref target="RFC9560"> </xref>).</t>	protocol specifications (<xref target="RFC7481"></xref>, <xref target="RFC9560"> </xref>).</t>
	</section>	</section>

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

	<section anchor="rdap-extensions-registry"><name>RDAP Extensions Registry</name>	<section anchor="rdap-extensions-registry"><name>RDAP Extensions Registry</name>

	<t>IANA is requested to register the following value in the RDAP Extensions Regi stry at <xref target="RDAP-EXTENSIONS"></xref>:</t>	<t>IANA has registered the following value in the "RDAP Extensions" registry at <xref target="RDAP-EXTENSIONS"></xref>:</t>


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

	<section anchor="link_relations_registry"><name>Link Relations Registry</name>	<section anchor="link_relations_registry"><name>Link Relations Registry</name>

	<t>IANA is requested to register the following value in the Link Relations Regis try at <xref target="LINK-RELATIONS"></xref>:</t>	<t>IANA has registered the following value in the "Link Relations" registry at < xref target="LINK-RELATIONS"></xref>:</t>


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

	<section anchor="media_types_registry"><name>Media Types Registry</name>	<section anchor="media_types_registry"><name>Media Types Registry</name>

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


	<ul spacing="compact">	<dl spacing="normal" newline="false">
	<li>Type name: application</li>	<dt>Type name:</dt><dd>application</dd>
	<li>Subtype name: geofeed+csv</li>	<dt>Subtype name:</dt><dd>geofeed+csv</dd>
	<li>Required parameters: N/A</li>	<dt>Required parameters:</dt><dd>N/A</dd>
	<li>Optional parameters: "charset" is an optional parameter for "	<dt>Optional parameters:</dt><dd>"charset" is an optional
	text/csv", but it is not used for	parameter for "text/csv", but it is not used for
	"application/geofeed+csv" because the geofeed content is always in UTF	"application/geofeed+csv" because the geofeed content is always in
	-8 (<xref target="RFC8805" sectionFormat="of" section="2.1"></xref>).</li>	UTF-8 (<xref target="RFC8805" sectionFormat="of"
	<li>Encoding considerations: See <xref target="RFC9632" sectionFormat="of" secti	section="2.1"></xref>).</dd>
	on="2"></xref>.</li>	<dt>Encoding considerations:</dt><dd>See <xref target="RFC9632" sectionFormat=
	<li>Security considerations: See <xref target="security_considerations"></xref>	"of" section="2"></xref>.</dd>
	of this document.</li>	<dt>Security considerations:</dt><dd>See <xref target="security_considerations
	<li>Interoperability considerations: There are no known interoperability problem	"></xref> of RFC 9877.</dd>
	s regarding this media format.</li>	<dt>Interoperability considerations:</dt><dd>There are no known interoperabili
	<li>Published specification: This document.</li>	ty problems regarding this media format.</dd>
	<li>Applications that use this media type: Implementations of the Registration D	<dt>Published specification:</dt><dd>RFC 9877.</dd>
	ata Access Protocol (RDAP) Extension for	<dt>Applications that use this media type:</dt><dd>Implementations of the
	Geofeed Data. Furthermore, any application that processes the CSV geofeed data.<	Registration Data Access Protocol (RDAP) Extension for Geofeed
	/li>	Data. Furthermore, any application that processes the CSV geofeed data.</dd>
	<li>Additional information: This media type is a product of the IETF REGEXT Work	<dt>Additional information:</dt><dd>This media type is a product of the IETF
	ing Group. The REGEXT charter, information	REGEXT Working Group. The REGEXT charter, information on the REGEXT mailing
	on the REGEXT mailing list, and other documents produced by the REGEXT Working G	list, and other documents produced by the REGEXT Working Group can be found
	roup can be found at <xref target="REGEXT"></xref>.</li>	at <xref target="REGEXT"></xref>.</dd>
	<li>Person & email address to contact for further information: REGEXT Workin	<dt>Person & email address to contact for further information:</dt><dd><br
	g Group, regext@ietf.org</li>	/>REGEXT Working Group <regext@ietf.org></dd>
	<li>Intended usage: COMMON</li>	<dt>Intended usage:</dt><dd>COMMON</dd>
	<li>Restrictions on usage: None</li>	<dt>Restrictions on usage:</dt><dd>None</dd>
	<li>Authors: Tom Harrison, Jasdip Singh</li>	<dt>Authors:</dt><dd>Tom Harrison, Jasdip Singh</dd>
	<li>Author/Change controller: IETF</li>	<dt>Author/Change controller:</dt><dd>IETF</dd>
	<li>Provisional Registration: No</li>	</dl>
	</ul>
	</section>	</section>

	<section anchor="structured_syntax_suffixes_registry"><name>Structured Syntax Su ffixes Registry</name>	<section anchor="structured_syntax_suffixes_registry"><name>Structured Syntax Su ffixes Registry</name>

	<t>IANA is requested to register the following value in the Structured Syntax Su ffixes Registry	<t>IANA has registered the following value in the "Structured Syntax Suffixes" r egistry
	at <xref target="STRUCTURED-SYNTAX-SUFFIXES"></xref>:</t>	at <xref target="STRUCTURED-SYNTAX-SUFFIXES"></xref>:</t>


	<ul>	<dl spacing="normal" newline="false">
	<li>Name: Comma-Separated Values (CSV)</li>	<dt>Name:</dt><dd>Comma-Separated Values (CSV)</dd>
	<li>+suffix: +csv</li>	<dt>+suffix:</dt><dd>+csv</dd>
	<li>References: <xref target="RFC4180"></xref>, <xref target="RFC7111"></xref></	<dt>References:</dt><dd><xref target="RFC4180"></xref>, <xref target="RFC7111"
	li>	></xref></dd>
	<li>Encoding Considerations: Same as "text/csv".</li>	<dt>Encoding Considerations:</dt><dd>Same as "text/csv".</dd>
	<li>Interoperability Considerations: Same as "text/csv".</li>	<dt>Interoperability Considerations:</dt><dd>Same as "text/csv".</dd
	<li><t>Fragment Identifier Considerations:</t>	>
	<t>The syntax and semantics of fragment identifiers specified for +csv SHOULD be	<dt>Fragment Identifier Considerations:</dt>
	as specified for "text/csv".</t>	<dd><t>The syntax and semantics of fragment identifiers specified for +csv <bc
	<t>The syntax and semantics for fragment identifiers for a specific "xxx/yy	p14>SHOULD</bcp14> be as specified for "text/csv".</t>
	y+csv" SHOULD be processed as follows:</t>	<t>The syntax and semantics for fragment identifiers for a specific "xxx/
	<t>For cases defined in +csv, where the fragment identifier resolves per the +cs	yyy+csv" <bcp14>SHOULD</bcp14> be processed as follows:</t>
	v rules, then as specified for +csv.</t>	<ul spacing="compact">
	<t>For cases defined in +csv, where the fragment identifier does not resolve per	<li>For cases defined in +csv, where the fragment identifier resolves per
	the +csv rules, then as specified	the +csv rules, then as specified for +csv.</li> <li>For cases defined in
	for "xxx/yyy+csv".</t>	+csv, where the fragment identifier does not resolve per the +csv rules,
	<t>For cases not defined in +csv, then as specified for "xxx/yyy+csv".	then as specified for "xxx/&wj;yyy+csv".</li>
	</t>	<li>For cases not defined in +csv, then as specified for "xxx/&wj;yyy+c
	</li>	sv".</li>
	<li><t>Security Considerations: Same as "text/csv".</t>	</ul></dd>
	</li>	<dt>Security Considerations:</dt><dd>Same as "text/csv".</dd>
	<li><t>Contact: IETF, iesg@ietf.org</t>	<dt>Contact:</dt><dd>IETF <iesg@ietf.org></dd>
	</li>	<dt>Author/Change controller:</dt><dd>IETF</dd>
	<li><t>Author/Change controller: IETF</t>	</dl>
	</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 defi
	ned by this specification at the time of
	posting of this Internet-Draft, and is based on a proposal described in <xref ta
	rget="RFC7942"></xref>. The description of implementations
	in this section is intended to assist the IETF in its decision processes in prog
	ressing 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 co
	ntributors. This is not intended as, and
	must not be construed to be, a catalog of available implementations or their fea
	tures. Readers are advised to note that
	other implementations may exist.</t>
	<t>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 experimenta
	tion 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".</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-databas
	e-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 0
	1 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 f
	ile URL. Andy Newton, James Gould, Scott
	Hollenbeck, Mario Loffredo, Orie Steele, Alexey Melnikov, Mark Nottingham, Rifaa
	t 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 fil
	e URL.</li>
	<li>Renamed the extension as "geofeed1" instead of "geofeedv1&quo
	t;.</li>
	<li>Introduced the new "geo" link relation type.</li>
	<li>Introduced the new "application/geofeed+csv" 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 "Requirements Language" section for examples.</li>
	<li>Added an example for RDAP conformance.</li>
	<li>Updated the rationale for using the new "application/geofeed+csv"
	media type.</li>
	<li>Updated the "Applications that use this media type" section for th
	e "application/geofeed+csv" registration.</li>
	</ul>
	</section>

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

	<ul spacing="compact">
	<li>Removed "value" and "hreflang" explanations from the &qu
	ot;Geofeed Link" section. Further, clarified the cardinality of
	geofeed link objects.</li>
	<li>Updated extensibility verbiage in the "Media Type for a Geofeed Link&qu
	ot; section.</li>
	<li>In the "Example" section, updated the domain in "href" o
	f the geofeed link object to contrast with the domain in
	"value" to highlight that "href" is for a geofeed file hoste
	d at a network operator site whereas "value" is for an IP
	network object from an RDAP server.</li>
	<li>Removed the "Redaction" 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 "rdapCon
	formance".</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 "Operational Considerations" section to clarify the geof
	eed file and IP networks relationship, as well as
	how RDAP Bootstrap helps with a recommendation from RFC 8805.</li>
	<li>Updated the "Privacy Considerations" section to clarify the servic
	e 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 a
	nd 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 "Implementation Status" 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>
	</section>	</section>
	</section>	</section>

	</middle>	</middle>

	<back>	<back>
	<references><name>References</name>	<references><name>References</name>
	<references><name>Normative 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.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.3629.xml" />

	skipping to change at line 458 ¶	skipping to change at line 370 ¶
	<reference anchor="RDAP-EXTENSIONS" target="https://www.iana.org/assignments/rda p-extensions/">	<reference anchor="RDAP-EXTENSIONS" target="https://www.iana.org/assignments/rda p-extensions/">
	<front>	<front>
	<title>RDAP Extensions</title>	<title>RDAP Extensions</title>
	<author>	<author>
	<organization>IANA</organization>	<organization>IANA</organization>
	</author>	</author>
	</front>	</front>
	</reference>	</reference>
	<reference anchor="REGEXT" target="https://datatracker.ietf.org/wg/regext/">	<reference anchor="REGEXT" target="https://datatracker.ietf.org/wg/regext/">
	<front>	<front>

	<title>Registration Protocols Extensions</title>	<title>Registration Protocols Extensions (regext)</title>
	<author>	<author>
	<organization>IETF</organization>	<organization>IETF</organization>
	</author>	</author>
	</front>	</front>
	</reference>	</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.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.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.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.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.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.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.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.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.8805.xml" />
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9560.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/assi gnments/media-type-structured-suffix/">	<reference anchor="STRUCTURED-SYNTAX-SUFFIXES" target="https://www.iana.org/assi gnments/media-type-structured-suffix/">
	<front>	<front>
	<title>Structured Syntax Suffixes</title>	<title>Structured Syntax Suffixes</title>
	<author>	<author>
	<organization>IANA</organization>	<organization>IANA</organization>
	</author>	</author>
	</front>	</front>
	</reference>	</reference>
	</references>	</references>
	</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>	</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>	</rfc>

End of changes. 35 change blocks.
	335 lines changed or deleted	226 lines changed or added
This html diff was produced by rfcdiff 1.48.