RDAP RIR Search

The Registration Data Access Protocol (RDAP) is used by Internet Number Resource (INR) registries and domain name registries to provide access to their resource registration information. The core specifications for RDAP define basic search functionality, but this is limited to domains, nameservers, and entities. No searches were defined for IP networks or autonomous system numbers. In an effort to have RDAP reach feature parity with the existing INR Whois services in this respect, this document defines additional search options for IP networks and autonomous system numbers, along with an additional link relation for finding more-specific resources.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

The new resource type path segments for search are: 'ips': Used to identify an IP network search using a pattern to match one of a set of IP network attributes. 'autnums': Used to identify an Autonomous System number search using a pattern to match one of a set of Autonomous System number attributes. Search path segments are formed using the same logic as in section 3.2 of .

Syntax: ips?handle=<handle search pattern> Syntax: ips?name=<name search pattern> Searches for IP network information by handle are specified using the form: ips?handle=XXXX XXXX is a search pattern representing an IP network identifier, the syntax for which is specific to the registration provider. The following URL would be used to find information for IP networks with handles matching the "NET-199*" pattern: https://example.com/rdap/ips?handle=NET-199* Searches for IP network information by name are specified using the form: ips?name=XXXX XXXX is a search pattern representing an IP network identifier that is assigned to the network registration by the registration holder. The following URL would be used to find information for IP networks with names matching the "NET-EXAMPLE-*" pattern: https://example.com/rdap/ips?name=NET-EXAMPLE-*

Syntax: autnums?handle=<handle search pattern> Syntax: autnums?name=<name search pattern> Searches for autonomous system number information by handle are specified using the form: autnums?handle=XXXX XXXX is a search pattern representing an autonomous system number identifier, the syntax for which is specific to the registration provider. The following URL would be used to find information for autonomous system numbers with handles matching the "AS1*" pattern: https://example.com/rdap/autnums?handle=AS1* Searches for autonomous system number information by name are specified using the form: autnums?name=XXXX XXXX is a search pattern representing an autonomous system number identifier that is assigned to the autonomous system number registration by the registration holder. The following URL would be used to find information for autonomous system numbers with names matching the "ASN-EXAMPLE-*" pattern: https://example.com/rdap/autnums?name=ASN-EXAMPLE-*

As with , responses to the IP network and autonomous system number searches defined in the previous section take the form of an array of object instances, where each instance is an appropriate object class for the search (i.e., a search for /ips yields an array of IP network object instances, and a search for /autnums yields an array of autonomous system number object instances). These arrays are contained within the response object. The names of the arrays are as follows: for /ips searches, the array is "ipSearchResults"; and for /autnums searches, the array is "autnumSearchResults".

An IP network, autonomous system number, or reverse domain object may have a 'parent' object and one or more 'child' objects. The 'parent' object is the next-least-specific object that exists in the relevant registry, while the 'child' objects are the next-most-specific objects that exist in the relevant registry. For example, for a registry with the following four IP network objects: 192.0.2.0/24 192.0.2.0/25 192.0.2.128/25 192.0.2.0/32 the parent object of 192.0.2.0/32 would be 192.0.2.0/25, the parent object of 192.0.2.128/25 would be 192.0.2.0/24, the parent object of 192.0.2.0/25 would be 192.0.2.0/24, and 192.0.2.0/24 would have no parent object. Conversely, the child objects for 192.0.2.0/24 would be 192.0.2.0/25 and 192.0.2.128/25, for 192.0.2.0/25 192.0.2.0/32, and for 192.0.2.128/25 and 192.0.2.0/32 there would be no child objects. In order to permit clients to locate the parent object for a given object, an operator includes a link using the "up" link relation that links to the parent object. Similarly, in order to permit clients to locate the child objects for a given object, an operator includes a link using the "down" link relation that when resolved, returns a response that has the same format as a search for the relevant object type containing all of the child objects for that object. For example: In the example above, the link target for the link with the "down" relation is "http://rdap.example.com/ip-down/192.0.2.0/25". However, the link structure used by a server for these links is not defined by this specification, and clients MUST NOT make inferences about supported behaviour by inspecting the structure of these links. An operator MUST NOT include a link with an "up" link relation in an object if that object has no parent object. Similarly, an operator MUST NOT include a link with a "down" link relation in an object if that object has no child objects. This permits clients to rely on the absence of a given link relation as determinative of the question whether the object has any related objects of that type.

RDAP reverse search is defined by . That document limits reverse search to domains, nameservers, and entities. This document extends reverse search to cover IP networks and autonomous system numbers as well. If a server receives a reverse search query with a searchable resource type (per the definition of that term in ) of "ips", then the reverse search will be performed on the IP network objects from its data store. Similarly, if a server receives a reverse search query with a searchable resource type of "autnums", then the reverse search will be performed on the autonomous system number objects from its data store. Additionally, includes requests to register new entries for IP network and autonomous system number searches in the RDAP Reverse Search and RDAP Reverse Search Mapping IANA registries.

A server that supports all of the functionality specified in this document MUST include the string literal "inr_search" in the rdapConformance array in their response objects. , and collectively require that an RDAP extension identifier be used as a prefix in new path segments and response object members that are introduced by the extension. Because IP network objects and autonomous system number objects are part of the original set of object types defined for use in RDAP, it may be unintuitive or confusing for users if the searches and associated responses defined here include the "inr_search" extension prefix, since the searches and associated responses for the other original object types do not include a prefix. Therefore, the extension identifier is not used as a prefix in this document. Since this is not in keeping with the requirements of those earlier documents, this document is marked as updating those documents.

The search functionality defined in this document may affect the privacy of entities in the registry (and elsewhere) in various ways: see for a general treatment of privacy in protocol specifications. Registry operators should be aware of the tradeoffs that result from implementation of this functionality. Many jurisdictions have laws or regulations that restrict the use of "Personal Data", per the definition in . Given that, registry operators should ascertain whether the regulatory environment in which they operate permits implementation of the functionality defined in this document.

describes security requirements and considerations for RDAP generally.

IANA is requested to register the following value in the RDAP Extensions Registry: Extension identifier: inr_search Registry operator: Any Published specification: [this document] Contact: IETF <iesg@ietf.org> Intended usage: This extension identifier is used for INR-specific search operations. IANA is also requested to register the following value in the Link Relations Registry: Relation Name: down Description: Refers to a set of child documents in a hierarchy of documents. Reference: [this document] IANA is also requested to register the following entries in the "RDAP Reverse Search" registry: ips, autnums entity fn The server supports the IP/autnum search based on the full name (a.k.a formatted name) of an associated entity. IESG iesg@ietf.org This document. ips, autnums entity handle The server supports the IP/autnum search based on the handle of an associated entity. IESG iesg@ietf.org This document. ips, autnums entity email The server supports the IP/autnum search based on the email address of an associated entity. IESG iesg@ietf.org This document. ips, autnums entity role The server supports the IP/autnum search based on the role of an associated entity. IESG iesg@ietf.org This document. IANA is also requested to register the following entries in the "RDAP Reverse Search Mapping" registry: ips, autnums entity fn $..entities[*].vcardArray[1][?(@[0]=='fn')][3] IESG iesg@ietf.org This document. ips, autnums entity handle $..entities[*].handle IESG iesg@ietf.org This document. ips, autnums entity email $..entities[*].vcardArray[1][?(@[0]=='email')][3] IESG iesg@ietf.org This document. ips, autnums entity role $..entities[*].roles IESG iesg@ietf.org This document.

TBD