draft-ietf-regext-rdap-rir-search-08.txt | draft-ietf-regext-rdap-rir-search-09.txt | |||
---|---|---|---|---|
Internet Engineering Task Force T. Harrison | Internet Engineering Task Force T. Harrison | |||
Internet-Draft APNIC | Internet-Draft APNIC | |||
Intended status: Standards Track J. Singh | Intended status: Standards Track J. Singh | |||
Expires: 21 September 2024 ARIN | Expires: 26 September 2024 ARIN | |||
20 March 2024 | 25 March 2024 | |||
RDAP RIR Search | RDAP RIR Search | |||
draft-ietf-regext-rdap-rir-search-08 | draft-ietf-regext-rdap-rir-search-09 | |||
Abstract | Abstract | |||
The Registration Data Access Protocol (RDAP) is used by Regional | The Registration Data Access Protocol (RDAP) is used by Regional | |||
Internet Registries (RIRs) and Domain Name Registries (DNRs) to | Internet Registries (RIRs) and Domain Name Registries (DNRs) to | |||
provide access to their resource registration information. The core | provide access to their resource registration information. The core | |||
specifications for RDAP define basic search functionality, but there | specifications for RDAP define basic search functionality, but there | |||
are various IP and ASN-related search options provided by RIRs via | are various IP and ASN-related search options provided by RIRs via | |||
their Whois services for which there is no corresponding RDAP | their Whois services for which there is no corresponding RDAP | |||
functionality. This document extends RDAP to support those search | functionality. This document extends RDAP to support those search | |||
skipping to change at page 1, line 38 ¶ | skipping to change at page 1, line 38 ¶ | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on 21 September 2024. | This Internet-Draft will expire on 26 September 2024. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2024 IETF Trust and the persons identified as the | Copyright (c) 2024 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
skipping to change at page 2, line 21 ¶ | skipping to change at page 2, line 21 ¶ | |||
1.1. Conventions Used in This Document . . . . . . . . . . . . 3 | 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 | |||
2. Basic Searches . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Basic Searches . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2.1. Path Segments . . . . . . . . . . . . . . . . . . . . . . 3 | 2.1. Path Segments . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2.2. IP Network Search . . . . . . . . . . . . . . . . . . . . 4 | 2.2. IP Network Search . . . . . . . . . . . . . . . . . . . . 4 | |||
2.3. Autonomous System Number Search . . . . . . . . . . . . . 4 | 2.3. Autonomous System Number Search . . . . . . . . . . . . . 4 | |||
3. Relation Searches . . . . . . . . . . . . . . . . . . . . . . 5 | 3. Relation Searches . . . . . . . . . . . . . . . . . . . . . . 5 | |||
3.1. Path Segments . . . . . . . . . . . . . . . . . . . . . . 5 | 3.1. Path Segments . . . . . . . . . . . . . . . . . . . . . . 5 | |||
3.2. Relation Search . . . . . . . . . . . . . . . . . . . . . 6 | 3.2. Relation Search . . . . . . . . . . . . . . . . . . . . . 6 | |||
3.2.1. Definitions . . . . . . . . . . . . . . . . . . . . . 7 | 3.2.1. Definitions . . . . . . . . . . . . . . . . . . . . . 7 | |||
3.2.2. Relations . . . . . . . . . . . . . . . . . . . . . . 10 | 3.2.2. Relations . . . . . . . . . . . . . . . . . . . . . . 10 | |||
3.2.2.1. "up" . . . . . . . . . . . . . . . . . . . . . . 11 | 3.2.2.1. Single-Result Searches . . . . . . . . . . . . . 11 | |||
3.2.2.2. "down" . . . . . . . . . . . . . . . . . . . . . 11 | 3.2.2.2. Multiple-Result Searches . . . . . . . . . . . . 11 | |||
3.2.2.3. "top" . . . . . . . . . . . . . . . . . . . . . . 11 | ||||
3.2.2.4. "bottom" . . . . . . . . . . . . . . . . . . . . 11 | ||||
3.3. Status . . . . . . . . . . . . . . . . . . . . . . . . . 11 | 3.3. Status . . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
3.4. Link Relations . . . . . . . . . . . . . . . . . . . . . 12 | 3.4. Link Relations . . . . . . . . . . . . . . . . . . . . . 12 | |||
4. Responding To Searches . . . . . . . . . . . . . . . . . . . 15 | 4. Responding To Searches . . . . . . . . . . . . . . . . . . . 15 | |||
4.1. Single-Result Searches . . . . . . . . . . . . . . . . . 15 | ||||
4.2. Multiple-Result Searches . . . . . . . . . . . . . . . . 15 | ||||
5. Reverse Search . . . . . . . . . . . . . . . . . . . . . . . 17 | 5. Reverse Search . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
6. RDAP Conformance . . . . . . . . . . . . . . . . . . . . . . 17 | 6. RDAP Conformance . . . . . . . . . . . . . . . . . . . . . . 17 | |||
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18 | 7. Operational Considerations . . . . . . . . . . . . . . . . . 18 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 | 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19 | |||
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 | 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 | |||
9.1. RDAP Extensions Registry . . . . . . . . . . . . . . . . 19 | 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 | |||
9.2. Link Relations Registry . . . . . . . . . . . . . . . . . 20 | 10.1. RDAP Extensions Registry . . . . . . . . . . . . . . . . 19 | |||
9.3. RDAP Reverse Search Registry . . . . . . . . . . . . . . 21 | 10.2. Link Relations Registry . . . . . . . . . . . . . . . . 20 | |||
9.4. RDAP Reverse Search Mapping Registry . . . . . . . . . . 22 | 10.3. RDAP Reverse Search Registry . . . . . . . . . . . . . . 21 | |||
10. Implementation Status . . . . . . . . . . . . . . . . . . . . 23 | 10.4. RDAP Reverse Search Mapping Registry . . . . . . . . . . 23 | |||
10.1. APNIC RDAP Implementation . . . . . . . . . . . . . . . 24 | 11. Implementation Status . . . . . . . . . . . . . . . . . . . . 24 | |||
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 | 11.1. APNIC RDAP Implementation . . . . . . . . . . . . . . . 24 | |||
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 | 11.2. RIPE NCC RDAP Implementation . . . . . . . . . . . . . . 25 | |||
12.1. Normative References . . . . . . . . . . . . . . . . . . 24 | 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 | |||
12.2. Informative References . . . . . . . . . . . . . . . . . 25 | 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 | |||
13.1. Normative References . . . . . . . . . . . . . . . . . . 25 | ||||
13.2. Informative References . . . . . . . . . . . . . . . . . 26 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 | |||
1. Introduction | 1. Introduction | |||
The Registration Data Access Protocol (RDAP) [RFC7480] is used by | The Registration Data Access Protocol (RDAP) [RFC7480] is used by | |||
Regional Internet Registries (RIRs) and Domain Name Registries (DNRs) | Regional Internet Registries (RIRs) and Domain Name Registries (DNRs) | |||
to provide access to their resource registration information. The | to provide access to their resource registration information. The | |||
core specifications for RDAP define basic search functionality, but | core specifications for RDAP define basic search functionality, but | |||
this is limited to domains, nameservers, and entities. No searches | this is limited to domains, nameservers, and entities. No searches | |||
were defined for IP networks or autonomous system numbers. In an | were defined for IP networks or autonomous system numbers. In an | |||
effort to have RDAP reach feature parity with the existing RIR Whois | effort to have RDAP reach feature parity with the existing RIR Whois | |||
services in this respect, this document defines additional search | services in this respect, this document defines additional search | |||
options for IP networks and autonomous system numbers. | options for IP networks and autonomous system numbers. | |||
While this document is in terms of RIRs and DNRs for the sake of | While this document is in terms of RIRs and DNRs for the sake of | |||
consistency with earlier RDAP documents such as [RFC9082] and | consistency with earlier RDAP documents such as [RFC9082] and | |||
[RFC9083], the functionality described here may be used by any RDAP | [RFC9083], the functionality described here may be used by any RDAP | |||
server operator that hosts Internet Number Resource (INR) objects, | server operator that hosts Internet Number Resource (INR) objects. | |||
such as National Internet Registries (NIRs) or Local Internet | ||||
Registries (LIRs). | ||||
1.1. Conventions Used in This Document | 1.1. Conventions Used in This Document | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
"OPTIONAL" in this document are to be interpreted as described in BCP | "OPTIONAL" in this document are to be interpreted as described in BCP | |||
14 [RFC2119] [RFC8174] when, and only when, they appear in all | 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
capitals, as shown here. | capitals, as shown here. | |||
Indentation and whitespace in examples are provided only to | Indentation and whitespace in examples are provided only to | |||
skipping to change at page 6, line 17 ¶ | skipping to change at page 6, line 17 ¶ | |||
separated by a single hyphen ('-', US-ASCII value 0x2D), where the | separated by a single hyphen ('-', US-ASCII value 0x2D), where the | |||
second number is greater than the first. | second number is greater than the first. | |||
<resource type search path segment>: A search path segment | <resource type search path segment>: A search path segment | |||
corresponding to an Internet Number Resource (INR) object class | corresponding to an Internet Number Resource (INR) object class | |||
(i.e. an IP network address or range, autonomous system number or | (i.e. an IP network address or range, autonomous system number or | |||
number range, or reverse domain name). | number range, or reverse domain name). | |||
<object value>: a value used to identify an object for the | <object value>: a value used to identify an object for the | |||
purposes of a relation search relative to that object. One of <IP | purposes of a relation search relative to that object. One of <IP | |||
address>, <CIDR prefix>, <CIDR length>, <domain name>, or | address>, <CIDR prefix> and <CIDR length> pair, <domain name>, or | |||
<autonomous system number or range>, depending on the type of | <autonomous system number or range>, depending on the type of | |||
search that is being performed. | search that is being performed. | |||
<status>: an object status value, as defined in Section 4.6 of | <status>: an object status value, as defined in Section 4.6 of | |||
[RFC9083]. | [RFC9083]. | |||
The new resource type path segments for relation search (similar to | The new resource type path segments for relation search (similar to | |||
the searches defined in [RFC9082] and [RFC9083]) are: | the searches defined in [RFC9082] and [RFC9083]) are: | |||
'ips/rirSearch1/<relation>/<IP address>': Used to identify an IP | 'ips/rirSearch1/<relation>/<IP address>': Used to identify an IP | |||
skipping to change at page 6, line 51 ¶ | skipping to change at page 6, line 51 ¶ | |||
reverse domain search using a relation and a reverse domain name | reverse domain search using a relation and a reverse domain name | |||
to match a set of reverse domains. | to match a set of reverse domains. | |||
3.2. Relation Search | 3.2. Relation Search | |||
Syntax: <resource type search path | Syntax: <resource type search path | |||
segment>/rirSearch1/<relation>/<object value>[?status=<status>] | segment>/rirSearch1/<relation>/<object value>[?status=<status>] | |||
The relation searches defined in this document rely on the syntax | The relation searches defined in this document rely on the syntax | |||
described above. Each search works in the same way for each object | described above. Each search works in the same way for each object | |||
type. | class. | |||
3.2.1. Definitions | 3.2.1. Definitions | |||
An INR object value may have a "parent" object and one or more | An INR object value may have a "parent" object and one or more | |||
"child" objects. The "parent" object is the next-least-specific | "child" objects. The "parent" object is the next-least-specific | |||
object that exists in the relevant registry, while the "child" | object that exists in the relevant registry, while the "child" | |||
objects are the next-most-specific objects that exist in the relevant | objects are the next-most-specific objects that exist in the relevant | |||
registry. For example, for a registry with the following seven IP | registry. For example, for a registry with the following seven IP | |||
network objects: | network objects: | |||
skipping to change at page 8, line 18 ¶ | skipping to change at page 8, line 18 ¶ | |||
| 192.0.2.0/32 | 192.0.2.0/28 | | | 192.0.2.0/32 | 192.0.2.0/28 | | |||
+------------------+----------------+ | +------------------+----------------+ | |||
| 192.0.2.0/28 | 192.0.2.0/25 | | | 192.0.2.0/28 | 192.0.2.0/25 | | |||
+------------------+----------------+ | +------------------+----------------+ | |||
| 192.0.2.64/26 | 192.0.2.0/25 | | | 192.0.2.64/26 | 192.0.2.0/25 | | |||
+------------------+----------------+ | +------------------+----------------+ | |||
| 192.0.2.128/26 | 192.0.2.128/25 | | | 192.0.2.128/26 | 192.0.2.128/25 | | |||
+------------------+----------------+ | +------------------+----------------+ | |||
| 192.0.2.192/26 | 192.0.2.128/25 | | | 192.0.2.192/26 | 192.0.2.128/25 | | |||
+------------------+----------------+ | +------------------+----------------+ | |||
| 192.0.2.128/25 | 192.0.2.0/24 | | ||||
+------------------+----------------+ | ||||
| 192.0.2.0/25 | 192.0.2.0/24 | | | 192.0.2.0/25 | 192.0.2.0/24 | | |||
+------------------+----------------+ | +------------------+----------------+ | |||
| 192.0.2.128/25 | 192.0.2.0/24 | | ||||
+------------------+----------------+ | ||||
| 192.0.2.0/24 | N/A | | | 192.0.2.0/24 | N/A | | |||
+------------------+----------------+ | +------------------+----------------+ | |||
Table 1: Parent objects | Table 1: Parent objects | |||
+==================+================================+ | +==================+================================+ | |||
| INR object value | Child objects | | | INR object value | Child objects | | |||
+==================+================================+ | +==================+================================+ | |||
| 192.0.2.0/24 | 192.0.2.0/25, 192.0.2.128/25 | | | 192.0.2.0/24 | 192.0.2.0/25, 192.0.2.128/25 | | |||
+------------------+--------------------------------+ | +------------------+--------------------------------+ | |||
skipping to change at page 9, line 5 ¶ | skipping to change at page 8, line 49 ¶ | |||
+------------------+--------------------------------+ | +------------------+--------------------------------+ | |||
| 192.0.2.192/26 | N/A | | | 192.0.2.192/26 | N/A | | |||
+------------------+--------------------------------+ | +------------------+--------------------------------+ | |||
| 192.0.2.0/28 | 192.0.2.0/32 | | | 192.0.2.0/28 | 192.0.2.0/32 | | |||
+------------------+--------------------------------+ | +------------------+--------------------------------+ | |||
| 192.0.2.0/32 | N/A | | | 192.0.2.0/32 | N/A | | |||
+------------------+--------------------------------+ | +------------------+--------------------------------+ | |||
Table 2: Child objects | Table 2: Child objects | |||
Along similar lines, each INR object value may have a "top" object, | (INR object values do not necessarily correspond to registry objects, | |||
being the least-specific covering object that exists in the registry, | because users can provide arbitrary object values as input to the | |||
and one or more "bottom" objects, being the most-specific objects | searches defined in this document.) | |||
that entirely cover the INR object value when taken together. Given | Similarly to the parent/child object relationships, each INR object | |||
the registry defined in the previous paragraph, the top and bottom | value may have a "top" object, being the least-specific covering | |||
object relationships are: | object that exists in the registry, and one or more "bottom" objects, | |||
being the most-specific objects that entirely cover the INR object | ||||
value when taken together. Given the registry defined in the | ||||
previous paragraph, the top and bottom object relationships are: | ||||
+==================+==============+ | +==================+==============+ | |||
| INR object value | Top object | | | INR object value | Top object | | |||
+==================+==============+ | +==================+==============+ | |||
| 192.0.2.0/32 | 192.0.2.0/24 | | | 192.0.2.0/32 | 192.0.2.0/24 | | |||
+------------------+--------------+ | +------------------+--------------+ | |||
| 192.0.2.0/28 | 192.0.2.0/24 | | | 192.0.2.0/28 | 192.0.2.0/24 | | |||
+------------------+--------------+ | +------------------+--------------+ | |||
| 192.0.2.64/26 | 192.0.2.0/24 | | | 192.0.2.64/26 | 192.0.2.0/24 | | |||
+------------------+--------------+ | +------------------+--------------+ | |||
| 192.0.2.128/26 | 192.0.2.0/24 | | | 192.0.2.128/26 | 192.0.2.0/24 | | |||
+------------------+--------------+ | +------------------+--------------+ | |||
| 192.0.2.192/26 | 192.0.2.0/24 | | | 192.0.2.192/26 | 192.0.2.0/24 | | |||
+------------------+--------------+ | +------------------+--------------+ | |||
| 192.0.2.128/25 | 192.0.2.0/24 | | ||||
+------------------+--------------+ | ||||
| 192.0.2.0/25 | 192.0.2.0/24 | | | 192.0.2.0/25 | 192.0.2.0/24 | | |||
+------------------+--------------+ | +------------------+--------------+ | |||
| 192.0.2.128/25 | 192.0.2.0/24 | | ||||
+------------------+--------------+ | ||||
| 192.0.2.0/24 | N/A | | | 192.0.2.0/24 | N/A | | |||
+------------------+--------------+ | +------------------+--------------+ | |||
Table 3: Top objects | Table 3: Top objects | |||
+==================+===========================================+ | +==================+===========================================+ | |||
| INR object value | Bottom objects | | | INR object value | Bottom objects | | |||
+==================+===========================================+ | +==================+===========================================+ | |||
| 192.0.2.0/24 | 192.0.2.0/25, 192.0.2.0/28, 192.0.2.0/32, | | | 192.0.2.0/24 | 192.0.2.0/25, 192.0.2.0/28, 192.0.2.0/32, | | |||
| | 192.0.2.128/26, 192.0.2.192/26 | | | | 192.0.2.128/26, 192.0.2.192/26 | | |||
skipping to change at page 11, line 4 ¶ | skipping to change at page 11, line 4 ¶ | |||
The bottom objects for a given INR object value may include an object | The bottom objects for a given INR object value may include an object | |||
that is less-specific than that INR object value. For example, | that is less-specific than that INR object value. For example, | |||
192.0.2.0/31 is an INR object value that has a more-specific object, | 192.0.2.0/31 is an INR object value that has a more-specific object, | |||
being 192.0.2.0/32, so the set of bottom objects must include at | being 192.0.2.0/32, so the set of bottom objects must include at | |||
least that object. The most-specific object that covers the residual | least that object. The most-specific object that covers the residual | |||
(i.e. 192.0.2.1/32) is 192.0.2.0/28, so it is included in the results | (i.e. 192.0.2.1/32) is 192.0.2.0/28, so it is included in the results | |||
as well. | as well. | |||
3.2.2. Relations | 3.2.2. Relations | |||
3.2.2.1. "up" | 3.2.2.1. Single-Result Searches | |||
3.2.2.1.1. "up" | ||||
If the server receives a search containing the relation value "up", | If the server receives a search containing the relation value "up", | |||
it will return the parent object for the specified INR object value. | it will return the parent object for the specified INR object value | |||
If no such object exists, it will return an empty search response. | as though that object had been requested directly. If no such object | |||
exists, it will respond with a HTTP 404 (Not Found) [RFC9110] search | ||||
response. | ||||
3.2.2.2. "down" | 3.2.2.1.2. "top" | |||
If the server receives a search containing the relation value "top", | ||||
it will return the top object for the specified INR object value as | ||||
though that object had been requested directly. If no such object | ||||
exists, it will respond with an HTTP 404 (Not Found) [RFC9110] search | ||||
response. | ||||
3.2.2.2. Multiple-Result Searches | ||||
3.2.2.2.1. "down" | ||||
If the server receives a search containing the relation value "down", | If the server receives a search containing the relation value "down", | |||
it will return the child objects for the specified INR object value. | it will return the child objects for the specified INR object value. | |||
If no such objects exist, it will return an empty search response. | If no such objects exist, it will return an empty search response. | |||
Per the definitions section, this includes only immediate child | Per the definitions section, this includes only immediate child | |||
objects. | objects. | |||
3.2.2.3. "top" | 3.2.2.2.2. "bottom" | |||
If the server receives a search containing the relation value "top", | ||||
it will return the top object for the specified INR object value. If | ||||
no such object exists, it will return an empty search response. | ||||
3.2.2.4. "bottom" | ||||
If the server receives a search containing the relation value | If the server receives a search containing the relation value | |||
"bottom", it will return the bottom objects for the specified INR | "bottom", it will return the bottom objects for the specified INR | |||
object value. If no such objects exist, it will return an empty | object value. If no such objects exist, it will return an empty | |||
search response. | search response. | |||
3.3. Status | 3.3. Status | |||
If the "status" argument is provided, then response processing will | If the "status" argument is provided, then response processing will | |||
proceed as though all objects without the specified status had first | proceed as though all objects without the specified status had first | |||
skipping to change at page 12, line 5 ¶ | skipping to change at page 12, line 19 ¶ | |||
+----------------+----------+ | +----------------+----------+ | |||
| 192.0.2.128/25 | inactive | | | 192.0.2.128/25 | inactive | | |||
+----------------+----------+ | +----------------+----------+ | |||
| 192.0.2.128/26 | active | | | 192.0.2.128/26 | active | | |||
+----------------+----------+ | +----------------+----------+ | |||
| 192.0.2.192/26 | active | | | 192.0.2.192/26 | active | | |||
+----------------+----------+ | +----------------+----------+ | |||
Table 5: Statuses | Table 5: Statuses | |||
then a server receiving a "child" object query with the INR object | then a server receiving a "down" search request with the INR object | |||
value 192.0.2.0/24 and a "status" argument of "active" would return | value 192.0.2.0/24 and a "status" argument of "active" would return | |||
the objects 192.0.2.0/25, 192.0.2.128/26, and 192.0.2.192/26. | the objects 192.0.2.0/25, 192.0.2.128/26, and 192.0.2.192/26. | |||
Status filtering is useful, for example, where the client is trying | Status filtering is useful, for example, where the client is trying | |||
to find the delegation from an RIR to an RIR account holder: by using | to find the delegation from an RIR to an RIR account holder: by using | |||
the "top" relation with a "status" of "active", the delegation from | the "top" relation with a "status" of "active", the delegation from | |||
IANA to the RIR will be ignored, and the client will receive the | IANA to the RIR will be ignored, and the client will receive the | |||
delegation from the RIR to the account holder in the response | delegation from the RIR to the account holder in the response | |||
instead. | instead. | |||
By default, any valid status value may be used for status filtering. | By default, any valid status value may be used for status filtering. | |||
Server operators MAY opt not to support "status" filtering for the | Server operators MAY opt not to support "status" filtering for the | |||
"down" and "bottom" link relations, in which case the server should | "down" and "bottom" link relations, in which case the server should | |||
respond with a HTTP 501 (Not Implemented) [RFC9110] response code if | respond with an HTTP 501 (Not Implemented) [RFC9110] response code if | |||
it receives such a request. Server operators MAY also opt not to | it receives such a request. Server operators MAY also opt not to | |||
support "status" filtering for values other than "active" for the | support "status" filtering for values other than "active" for the | |||
"up" and "top" link relations, in which case the server should | "up" and "top" link relations, in which case the server should | |||
respond with a HTTP 501 (Not Implemented) [RFC9110] response code if | respond with an HTTP 501 (Not Implemented) [RFC9110] response code if | |||
it receives such a request. | it receives such a request. | |||
3.4. Link Relations | 3.4. Link Relations | |||
Each of the relations defined in section 3.2.2 has a corresponding | Each of the relations defined in section 3.2.2 has a corresponding | |||
link relation that can be used for a link object contained within | link relation that can be used for a link object contained within | |||
another RDAP object. When constructing these link objects, the | another RDAP object. When constructing these link objects, the | |||
server MUST set link targets that yield the same response as for the | server MUST use the corresponding search URL for the link target, or | |||
corresponding search. The following is an elided example of a | a URL that yields the same response as for the corresponding search | |||
response that makes use of those link relations: | as at the time of the request. The following is an elided example of | |||
a response that makes use of those link relations: | ||||
{ | { | |||
"startAddress": "192.0.2.0", | "startAddress": "192.0.2.0", | |||
"endAddress": "192.0.2.127", | "endAddress": "192.0.2.127", | |||
... | ... | |||
"links": [ | "links": [ | |||
..., | ..., | |||
{ | { | |||
"value": "https://rdap.example.com/ip/192.0.2.0/25", | "value": "https://example.com/rdap/ip/192.0.2.0/25", | |||
"rel": "up", | "rel": "up", | |||
"href": "https://rdap.example.com/ips/rirSearch1/up/192.0.2.0/25", | "href": "https://example.com/rdap/ips/rirSearch1/up/192.0.2.0/25", | |||
"type": "application/rdap+json" | "type": "application/rdap+json" | |||
}, | }, | |||
{ | { | |||
"value": "https://rdap.example.com/ip/192.0.2.0/25", | "value": "https://example.com/rdap/ip/192.0.2.0/25", | |||
"rel": "down", | "rel": "down", | |||
"href": "https://rdap.example.com/ips/rirSearch1/down/192.0.2.0/25", | "href": "https://example.com/rdap/ips/rirSearch1/down/192.0.2.0/25", | |||
"type": "application/rdap+json" | "type": "application/rdap+json" | |||
}, | }, | |||
{ | { | |||
"value": "https://rdap.example.com/ip/192.0.2.0/25", | "value": "https://example.com/rdap/ip/192.0.2.0/25", | |||
"rel": "top", | "rel": "top", | |||
"href": "https://rdap.example.com/ips/rirSearch1/top/192.0.2.0/25", | "href": "https://example.com/rdap/ips/rirSearch1/top/192.0.2.0/25", | |||
"type": "application/rdap+json" | "type": "application/rdap+json" | |||
}, | }, | |||
{ | { | |||
"value": "https://rdap.example.com/ip/192.0.2.0/25", | "value": "https://example.com/rdap/ip/192.0.2.0/25", | |||
"rel": "bottom", | "rel": "bottom", | |||
"href": "https://rdap.example.com/ips/rirSearch1/bottom/192.0.2.0/25", | "href": "https://example.com/rdap/ips/rirSearch1/bottom/192.0.2.0/25", | |||
"type": "application/rdap+json" | "type": "application/rdap+json" | |||
} | } | |||
] | ] | |||
} | } | |||
Figure 2: Example links | Figure 2: Example links | |||
Two additional link relations are defined that correspond to relation | Two additional link relations are defined that correspond to relation | |||
searches with a "status" of "active": "up-active" and "top-active". | searches with a "status" of "active": "up-active" and "top-active". | |||
No other status-specific link relations are defined, because the only | No other status-specific link relations are defined, because the only | |||
skipping to change at page 14, line 12 ¶ | skipping to change at page 14, line 12 ¶ | |||
relations and the "active" status. The following is an elided | relations and the "active" status. The following is an elided | |||
example of a response that makes use of those link relations: | example of a response that makes use of those link relations: | |||
{ | { | |||
"startAddress": "192.0.2.0", | "startAddress": "192.0.2.0", | |||
"endAddress": "192.0.2.127", | "endAddress": "192.0.2.127", | |||
... | ... | |||
"links": [ | "links": [ | |||
..., | ..., | |||
{ | { | |||
"value": "https://rdap.example.com/ip/192.0.2.0/25", | "value": "https://example.com/rdap/ip/192.0.2.0/25", | |||
"rel": "up-active", | "rel": "up-active", | |||
"href": | "href": | |||
"https://rdap.example.com/ips/rirSearch1/up/192.0.2.0/25?status=active", | "https://example.com/rdap/ips/rirSearch1/up/192.0.2.0/25?status=active", | |||
"type": "application/rdap+json" | "type": "application/rdap+json" | |||
}, | }, | |||
{ | { | |||
"value": "https://rdap.example.com/ip/192.0.2.0/25", | "value": "https://example.com/rdap/ip/192.0.2.0/25", | |||
"rel": "top-active", | "rel": "top-active", | |||
"href": | "href": | |||
"https://rdap.example.com/ips/rirSearch1/top/192.0.2.0/25?status=active", | "https://example.com/rdap/ips/rirSearch1/top/192.0.2.0/25?status=active", | |||
"type": "application/rdap+json" | "type": "application/rdap+json" | |||
} | } | |||
] | ] | |||
} | } | |||
Figure 3: Example status links | Figure 3: Example status links | |||
Since the "top" and "up" link relations resolve to a single object, | Since the "top" and "up" link relations resolve either to a single | |||
it is possible to simply include that object's link in the "href" | object or to an HTTP 404 (Not Found) [RFC9110] response, it is | |||
attribute in the link object. The following is an elided example of | possible for a server to use a lookup URL in the "href" attribute in | |||
a response that uses this approach: | the link object. The following is an elided example of a response | |||
that uses this approach: | ||||
{ | { | |||
"startAddress": "192.0.2.0", | "startAddress": "192.0.2.0", | |||
"endAddress": "192.0.2.127", | "endAddress": "192.0.2.127", | |||
... | ... | |||
"links": [ | "links": [ | |||
..., | ..., | |||
{ | { | |||
"value": "https://rdap.example.com/ip/192.0.2.0/25", | "value": "https://example.com/rdap/ip/192.0.2.0/25", | |||
"rel": "up", | "rel": "up", | |||
"href": "https://rdap.example.com/192.0.2.0/24", | "href": "https://example.com/rdap/ip/192.0.2.0/24", | |||
"type": "application/rdap+json" | "type": "application/rdap+json" | |||
} | } | |||
] | ] | |||
} | } | |||
Figure 4: Example single object links | Figure 4: Example single-result links | |||
This section mandates specific behaviour for the "up" link relation, | This section mandates specific behaviour for the "up" link relation, | |||
but does not define that link relation (see [RFC8288]). This is | but does not define that link relation (see [RFC8288]). This is | |||
acceptable, because this behaviour: | acceptable, because this behaviour: | |||
does not conflict with the current description of the link | does not conflict with the current description of the link | |||
relation; and | relation; and | |||
is not generally applicable, but instead limited to the context of | is not generally applicable, but instead limited to the context of | |||
RDAP INR objects only. | RDAP INR objects only. | |||
Use of these link relations in responses is OPTIONAL. The absence in | Use of these link relations in responses is OPTIONAL. The absence in | |||
a response of a link for a specific relation does not necessarily | a response of a link for a specific relation does not necessarily | |||
mean that the corresponding object does not exist or that the | mean that the corresponding search will return no results. | |||
corresponding search will return no results. | ||||
4. Responding To Searches | 4. Responding To Searches | |||
As with [RFC9083], responses to the IP network and autonomous system | 4.1. Single-Result Searches | |||
number searches defined in the previous sections take the form of an | ||||
The "up" and "top" relations are single-result searches. When | ||||
processing these searches, if there is a result for the search, the | ||||
server returns that object as though it were requested directly via a | ||||
lookup URL (see section 3.1 of [RFC9082]). If there is no result for | ||||
the search, the server returns an HTTP 404 (Not Found) [RFC9110] | ||||
response code. | ||||
4.2. Multiple-Result Searches | ||||
The "down" and "bottom" relations are multiple-result searches. As | ||||
with [RFC9083], responses for these searches take the form of an | ||||
array of object instances, where each instance is an appropriate | array of object instances, where each instance is an appropriate | |||
object class for the search (i.e., a search beginning with /ips | object class for the search (i.e., a search beginning with /ips | |||
yields an array of IP network object instances, and a search | yields an array of IP network object instances, and a search | |||
beginning with /autnums yields an array of autonomous system number | beginning with /autnums yields an array of autonomous system number | |||
object instances). The IP network object and autonomous system | object instances). The IP network object and autonomous system | |||
number object types are defined in sections 5.4 and 5.5 of [RFC9083]. | number object classes are defined in sections 5.4 and 5.5 of | |||
The object instance arrays are contained within the response object. | [RFC9083]. The object instance arrays are contained within the | |||
response object. | ||||
The names of the arrays are as follows: | The names of the arrays are as follows: | |||
for /ips searches, the array is "ipSearchResults"; and | for /ips searches, the array is "ipSearchResults"; and | |||
for /autnums searches, the array is "autnumSearchResults". | for /autnums searches, the array is "autnumSearchResults". | |||
The following is an elided example of a response to an IP network | The following is an elided example of a response to an IP network | |||
search: | search: | |||
skipping to change at page 16, line 47 ¶ | skipping to change at page 16, line 47 ¶ | |||
{ | { | |||
"objectClassName": "autnum", | "objectClassName": "autnum", | |||
"handle": "XXXX-RIR", | "handle": "XXXX-RIR", | |||
"startAutnum": 64496, | "startAutnum": 64496, | |||
"endAutnum": 64496, | "endAutnum": 64496, | |||
... | ... | |||
}, | }, | |||
{ | { | |||
"objectClassName": "autnum", | "objectClassName": "autnum", | |||
"handle": "YYYY-RIR", | "handle": "YYYY-RIR", | |||
"startAddress": "64497", | "startAutnum": "64497", | |||
"endAddress": "64497", | "endAutnum": "64497", | |||
... | ... | |||
} | } | |||
] | ] | |||
} | } | |||
Figure 6: ASN search response | Figure 6: ASN search response | |||
Responses for relation searches for reverse domain objects have the | Responses for relation searches for reverse domain objects have the | |||
same form as for a standard domain search response, per [RFC9083]. | same form as for a standard domain search response, per [RFC9083]. | |||
If the search can be processed by the server, but there are no | If the search can be processed by the server, but there are no | |||
results for the search, then the server returns a HTTP 200 (OK) | results for the search, then the server returns an HTTP 200 (OK) | |||
response code, with the body of the response containing an empty | [RFC9110] response code, with the body of the response containing an | |||
results array. | empty results array. | |||
5. Reverse Search | 5. Reverse Search | |||
RDAP reverse search is defined by | RDAP reverse search is defined by | |||
[I-D.ietf-regext-rdap-reverse-search]. That document limits reverse | [I-D.ietf-regext-rdap-reverse-search]. That document limits reverse | |||
search to domains, nameservers, and entities. This document extends | search to domains, nameservers, and entities. This document extends | |||
reverse search to cover IP networks and autonomous system numbers as | reverse search to cover IP networks and autonomous system numbers as | |||
well. | well. | |||
If a server receives a reverse search query with a searchable | If a server receives a reverse search query with a searchable | |||
resource type (per the definition of that term in | resource type (per the definition of that term in | |||
[I-D.ietf-regext-rdap-reverse-search]) of "ips", then the reverse | [I-D.ietf-regext-rdap-reverse-search]) of "ips", then the reverse | |||
search will be performed on the IP network objects from its data | search will be performed on the IP network objects from its data | |||
store. Similarly, if a server receives a reverse search query with a | store. Similarly, if a server receives a reverse search query with a | |||
searchable resource type of "autnums", then the reverse search will | searchable resource type of "autnums", then the reverse search will | |||
be performed on the autonomous system number objects from its data | be performed on the autonomous system number objects from its data | |||
store. | store. | |||
Additionally, Section 9 includes requests to register new entries for | Additionally, Section 10 includes requests to register new entries | |||
IP network and autonomous system number searches in the RDAP Reverse | for IP network and autonomous system number searches in the RDAP | |||
Search and RDAP Reverse Search Mapping IANA registries. | Reverse Search and RDAP Reverse Search Mapping IANA registries. | |||
6. RDAP Conformance | 6. RDAP Conformance | |||
A server that supports the functionality specified in this document | A server that supports the functionality specified in this document | |||
MUST include additional string literals in the rdapConformance array | MUST include additional string literals in the rdapConformance array | |||
of its responses, in accordance with the following: | of its responses, in accordance with the following: | |||
any response that includes an IP network basic search link, an IP | any response that includes an IP network basic search link, an IP | |||
network relation search link, or an IP network reverse search | network relation search link, or an IP network reverse search | |||
link, includes the "rirSearch1" and "ips" literals; | link, includes the "rirSearch1" and "ips" literals; | |||
skipping to change at page 18, line 24 ¶ | skipping to change at page 18, line 24 ¶ | |||
a response to a "/help" request includes the "rirSearch1", "ips", | a response to a "/help" request includes the "rirSearch1", "ips", | |||
"ipSearchResults", "autnums", and "autnumSearchResults" literals. | "ipSearchResults", "autnums", and "autnumSearchResults" literals. | |||
Although responses will generally not include all of the | Although responses will generally not include all of the | |||
rdapConformance string literals defined in this document, that is not | rdapConformance string literals defined in this document, that is not | |||
meant to imply that a server can support only a portion of the | meant to imply that a server can support only a portion of the | |||
functionality defined in this document. | functionality defined in this document. | |||
The "ips", "autnums", "ipSearchResults", and "autnumSearchResults" | The "ips", "autnums", "ipSearchResults", and "autnumSearchResults" | |||
extension identifiers are included here due to the requirements set | extension identifiers are included here due to the requirements set | |||
out in [RFC7480], [RFC9082], and [RFC9083] that an RDAP extension | out in [RFC7480], [RFC9082], and [RFC9083]. These requirements are | |||
identifier be used as a prefix in new path segments and JSON members | that an RDAP extension identifier be used as a prefix in new path | |||
introduced by the extension, and those strings are used as such as | segments and JSON members introduced by the extension, and those | |||
part of the basic searches defined in this document. Furthermore, | strings are used as such as part of the basic searches defined in | |||
using these strings as path segments helps to increase consistency | this document. Furthermore, using these strings as path segments | |||
among the basic searches for the core RDAP object types. | helps to increase consistency among the basic searches for the core | |||
RDAP object classes. | ||||
As with the other core object classes (entity, domain, and | As with the other core object classes (entity, domain, and | |||
nameserver), other documents may define additional reverse searches | nameserver), other documents may define additional reverse searches | |||
with IP networks and ASNs as the searchable resource type by | with IP networks and ASNs as the searchable resource type by | |||
registering those in the IANA RDAP reverse search registries. | registering those in the IANA RDAP reverse search registries. | |||
Because a given extension identifier must correspond to a single | Because a given extension identifier must correspond to a single | |||
extension, though, any document making use of IP networks or ASNs as | extension, though, any document making use of IP networks or ASNs as | |||
the searchable resource type must also implement the functionality | the searchable resource type must also implement the functionality | |||
described in this document. | described in this document. | |||
7. Privacy Considerations | 7. Operational Considerations | |||
When using a link object for a single-result search, a server may | ||||
replace a search URL with a lookup URL, because the behaviour of the | ||||
lookup URL is the same as for the search URL as at the time when the | ||||
response is generated. One difference between these approaches is | ||||
that when using the lookup URL, the server is effectively performing | ||||
the search on behalf of the client as at the time of response | ||||
generation. If there is no change to the relevant database state | ||||
between the time when the original response is generated and the time | ||||
when the client resolves the link relation target, then the search | ||||
URL and the lookup URL will lead to the same result. However, if | ||||
there is a change to the relevant database state, then the lookup URL | ||||
may lead to a different result from that of the search URL. Server | ||||
operators should consider which type of URL will be more effective | ||||
for their clients when implementing this specification. | ||||
8. Privacy Considerations | ||||
The search functionality defined in this document may affect the | The search functionality defined in this document may affect the | |||
privacy of entities in the registry (and elsewhere) in various ways: | privacy of entities in the registry (and elsewhere) in various ways: | |||
see [RFC6973] for a general treatment of privacy in protocol | see [RFC6973] for a general treatment of privacy in protocol | |||
specifications. Server operators should be aware of the tradeoffs | specifications. Server operators should be aware of the tradeoffs | |||
that result from implementation of this functionality. | that result from implementation of this functionality. | |||
Many jurisdictions have laws or regulations that restrict the use of | Many jurisdictions have laws or regulations that restrict the use of | |||
"Personal Data", per the definition in [RFC6973]. Given that, server | "Personal Data", per the definition in [RFC6973]. Given that, server | |||
operators should ascertain whether the regulatory environment in | operators should ascertain whether the regulatory environment in | |||
which they operate permits implementation of the functionality | which they operate permits implementation of the functionality | |||
defined in this document. | defined in this document. | |||
8. Security Considerations | 9. Security Considerations | |||
[RFC7481] describes security requirements and considerations for RDAP | [RFC7481] describes security requirements and considerations for RDAP | |||
generally. | generally. | |||
9. IANA Considerations | 10. IANA Considerations | |||
9.1. RDAP Extensions Registry | 10.1. RDAP Extensions Registry | |||
IANA is requested to register the following values in the RDAP | IANA is requested to register the following values in the RDAP | |||
Extensions Registry: | Extensions Registry: | |||
* Extension identifier: rirSearch1 | * Extension identifier: rirSearch1 | |||
* Registry operator: Any | * Registry operator: Any | |||
* Published specification: [this document] | * Published specification: [this document] | |||
skipping to change at page 20, line 29 ¶ | skipping to change at page 20, line 42 ¶ | |||
* Registry operator: Any | * Registry operator: Any | |||
* Published specification: [this document] | * Published specification: [this document] | |||
* Contact: IETF <iesg@ietf.org> | * Contact: IETF <iesg@ietf.org> | |||
* Intended usage: This extension identifier is used for INR-specific | * Intended usage: This extension identifier is used for INR-specific | |||
search operations. | search operations. | |||
9.2. Link Relations Registry | 10.2. Link Relations Registry | |||
IANA is requested to register the following values in the Link | IANA is requested to register the following values in the Link | |||
Relations Registry: | Relations Registry: | |||
* Relation Name: up-active | * Relation Name: up-active | |||
* Description: Refers to an RDAP parent document that has a status | * Description: Refers to an RDAP parent document that has a status | |||
of "active" in a hierarchy of documents. | of "active" in a hierarchy of documents. | |||
* Reference: [this document] | * Reference: [this document] | |||
skipping to change at page 21, line 21 ¶ | skipping to change at page 21, line 35 ¶ | |||
* Reference: [this document] | * Reference: [this document] | |||
* Relation Name: bottom | * Relation Name: bottom | |||
* Description: Refers to the set of child documents that do not | * Description: Refers to the set of child documents that do not | |||
themselves have child documents, in a hierarchy of documents. | themselves have child documents, in a hierarchy of documents. | |||
* Reference: [this document] | * Reference: [this document] | |||
9.3. RDAP Reverse Search Registry | 10.3. RDAP Reverse Search Registry | |||
IANA is requested to register the following entries in the "RDAP | IANA is requested to register the following entries in the "RDAP | |||
Reverse Search" registry: | Reverse Search" registry: | |||
Searchable Resource Type: ips, autnums | Searchable Resource Type: ips, autnums | |||
Related Resource Type: entity | Related Resource Type: entity | |||
Property: fn | Property: fn | |||
skipping to change at page 22, line 36 ¶ | skipping to change at page 23, line 5 ¶ | |||
Description: The server supports the IP/autnum search based on the | Description: The server supports the IP/autnum search based on the | |||
role of an associated entity. | role of an associated entity. | |||
Registrant Name: IETF | Registrant Name: IETF | |||
Registrant Contact Information: iesg@ietf.org | Registrant Contact Information: iesg@ietf.org | |||
Reference: This document. | Reference: This document. | |||
9.4. RDAP Reverse Search Mapping Registry | 10.4. RDAP Reverse Search Mapping Registry | |||
IANA is requested to register the following entries in the "RDAP | IANA is requested to register the following entries in the "RDAP | |||
Reverse Search Mapping" registry: | Reverse Search Mapping" registry: | |||
Searchable Resource Type: ips, autnums | Searchable Resource Type: ips, autnums | |||
Related Resource Type: entity | Related Resource Type: entity | |||
Property: fn | Property: fn | |||
skipping to change at page 23, line 35 ¶ | skipping to change at page 24, line 4 ¶ | |||
Property Path: $..entities[*].vcardArray[1][?(@[0]=='email')][3] | Property Path: $..entities[*].vcardArray[1][?(@[0]=='email')][3] | |||
Registrant Name: IETF | Registrant Name: IETF | |||
Registrant Contact Information: iesg@ietf.org | Registrant Contact Information: iesg@ietf.org | |||
Reference: This document. | Reference: This document. | |||
Searchable Resource Type: ips, autnums | Searchable Resource Type: ips, autnums | |||
Related Resource Type: entity | Related Resource Type: entity | |||
Property: role | Property: role | |||
Property Path: $..entities[*].roles | Property Path: $..entities[*].roles | |||
Registrant Name: IETF | Registrant Name: IETF | |||
Registrant Contact Information: iesg@ietf.org | Registrant Contact Information: iesg@ietf.org | |||
Reference: This document. | Reference: This document. | |||
10. Implementation Status | 11. Implementation Status | |||
| Note to the RFC Editor - remove this section before | | Note to the RFC Editor - remove this section before | |||
| publication, as well as the reference to RFC 7942. | | publication, as well as the reference to RFC 7942. | |||
This section records the status of known implementations of the | This section records the status of known implementations of the | |||
protocol defined by this specification at the time of posting of this | protocol defined by this specification at the time of posting of this | |||
Internet-Draft, and is based on a proposal described in [RFC7942]. | Internet-Draft, and is based on a proposal described in [RFC7942]. | |||
The description of implementations in this section is intended to | The description of implementations in this section is intended to | |||
assist the IETF in its decision processes in progressing drafts to | assist the IETF in its decision processes in progressing drafts to | |||
RFCs. Please note that the listing of any individual implementation | RFCs. Please note that the listing of any individual implementation | |||
skipping to change at page 24, line 25 ¶ | skipping to change at page 24, line 41 ¶ | |||
features. Readers are advised to note that other implementations may | features. Readers are advised to note that other implementations may | |||
exist. | exist. | |||
According to [RFC7942], "this will allow reviewers and working groups | According to [RFC7942], "this will allow reviewers and working groups | |||
to assign due consideration to documents that have the benefit of | to assign due consideration to documents that have the benefit of | |||
running code, which may serve as evidence of valuable experimentation | running code, which may serve as evidence of valuable experimentation | |||
and feedback that have made the implemented protocols more mature. | and feedback that have made the implemented protocols more mature. | |||
It is up to the individual working groups to use this information as | It is up to the individual working groups to use this information as | |||
they see fit". | they see fit". | |||
10.1. APNIC RDAP Implementation | 11.1. APNIC RDAP Implementation | |||
* Responsible Organization: Asia-Pacific Network Information Centre | * Responsible Organization: Asia-Pacific Network Information Centre | |||
(APNIC) | (APNIC) | |||
* Location: https://github.com/APNIC-net/rdap-rmp-demo/tree/rir- | * Location: https://github.com/APNIC-net/rdap-rmp-demo/tree/rir- | |||
search | search | |||
* Description: This implementation includes support for the various | * Description: This implementation includes support for the various | |||
searches and responses described in this document. | searches and responses described in this document. | |||
* Level of Maturity: This is a proof-of-concept implementation. | * Level of Maturity: This is a proof-of-concept implementation. | |||
* Coverage: This implementation includes all of the features | * Coverage: This implementation includes all of the features | |||
described in this specification. | described in this specification. | |||
* Contact Information: Tom Harrison, tomh@apnic.net | * Contact Information: Tom Harrison, tomh@apnic.net | |||
11. Acknowledgements | 11.2. RIPE NCC RDAP Implementation | |||
* Responsible Organization: RIPE NCC | ||||
* Location: https://github.com/RIPE-NCC/whois | ||||
* Description: This implementation includes support for basic | ||||
searches for IP networks and ASNs. | ||||
* Level of Maturity: This is a production implementation. | ||||
* Coverage: This implementation includes the new basic searches | ||||
only. | ||||
* Contact Information: Ed Shryane, eshryane@ripe.net | ||||
12. Acknowledgements | ||||
The authors wish to thank Mario Loffredo, Andy Newton, Antoin | The authors wish to thank Mario Loffredo, Andy Newton, Antoin | |||
Verschuren, and James Gould for document review and associated | Verschuren, and James Gould for document review and associated | |||
comments. | comments. | |||
12. References | 13. References | |||
12.1. Normative References | 13.1. Normative References | |||
[I-D.ietf-regext-rdap-reverse-search] | [I-D.ietf-regext-rdap-reverse-search] | |||
Loffredo, M. and M. Martinelli, "Registration Data Access | Loffredo, M. and M. Martinelli, "Registration Data Access | |||
Protocol (RDAP) Reverse Search", Work in Progress, | Protocol (RDAP) Reverse Search", Work in Progress, | |||
Internet-Draft, draft-ietf-regext-rdap-reverse-search-26, | Internet-Draft, draft-ietf-regext-rdap-reverse-search-26, | |||
13 November 2023, <https://datatracker.ietf.org/doc/html/ | 13 November 2023, <https://datatracker.ietf.org/doc/html/ | |||
draft-ietf-regext-rdap-reverse-search-26>. | draft-ietf-regext-rdap-reverse-search-26>. | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
skipping to change at page 25, line 41 ¶ | skipping to change at page 26, line 29 ¶ | |||
[RFC9083] Hollenbeck, S. and A. Newton, "JSON Responses for the | [RFC9083] Hollenbeck, S. and A. Newton, "JSON Responses for the | |||
Registration Data Access Protocol (RDAP)", STD 95, | Registration Data Access Protocol (RDAP)", STD 95, | |||
RFC 9083, DOI 10.17487/RFC9083, June 2021, | RFC 9083, DOI 10.17487/RFC9083, June 2021, | |||
<https://www.rfc-editor.org/info/rfc9083>. | <https://www.rfc-editor.org/info/rfc9083>. | |||
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, | [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, | |||
Ed., "HTTP Semantics", STD 97, RFC 9110, | Ed., "HTTP Semantics", STD 97, RFC 9110, | |||
DOI 10.17487/RFC9110, June 2022, | DOI 10.17487/RFC9110, June 2022, | |||
<https://www.rfc-editor.org/info/rfc9110>. | <https://www.rfc-editor.org/info/rfc9110>. | |||
12.2. Informative References | 13.2. Informative References | |||
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., | [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., | |||
Morris, J., Hansen, M., and R. Smith, "Privacy | Morris, J., Hansen, M., and R. Smith, "Privacy | |||
Considerations for Internet Protocols", RFC 6973, | Considerations for Internet Protocols", RFC 6973, | |||
DOI 10.17487/RFC6973, July 2013, | DOI 10.17487/RFC6973, July 2013, | |||
<https://www.rfc-editor.org/info/rfc6973>. | <https://www.rfc-editor.org/info/rfc6973>. | |||
[RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the | [RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the | |||
Registration Data Access Protocol (RDAP)", STD 95, | Registration Data Access Protocol (RDAP)", STD 95, | |||
RFC 7480, DOI 10.17487/RFC7480, March 2015, | RFC 7480, DOI 10.17487/RFC7480, March 2015, | |||
End of changes. 59 change blocks. | ||||
106 lines changed or deleted | 163 lines changed or added | |||
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |