<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" docName="draft-ietf-regext-rdap-rir-search-19" number="9910" consensus="true" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" prepTime="2026-01-07T15:53:51" indexInclude="true" scripts="Common,Latin">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-rir-search-19" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9910" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="RDAP RIR Search">Registration Data Access Protocol (RDAP) Regional Internet Registry (RIR) Search</title>
    <seriesInfo name="RFC" value="9910" stream="IETF"/>
    <author initials="T." surname="Harrison" fullname="Tom Harrison">
      <organization abbrev="APNIC" showOnFrontPage="true">Asia Pacific Network Information Centre</organization>
      <address>
        <postal>
          <street>6 Cordelia St</street>
          <city>South Brisbane</city>
          <code>4101</code>
          <country>Australia</country>
          <region>QLD</region>
        </postal>
        <email>tomh@apnic.net</email>
      </address>
    </author>
    <author initials="J." fullname="Jasdip Singh" surname="Singh">
      <organization abbrev="ARIN" showOnFrontPage="true">American Registry for Internet Numbers</organization>
      <address>
        <postal>
          <street>PO Box 232290</street>
          <city>Centreville</city>
          <region>VA</region>
          <code>20120</code>
          <country>United States of America</country>
        </postal>
        <email>jasdips@arin.net</email>
      </address>
    </author>
    <date month="01" year="2026"/>
    <area>ART</area>
    <workgroup>regext</workgroup>
    <keyword>RDAP</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">
            The Registration Data Access Protocol (RDAP) is used by
            Regional Internet Registries (RIRs) and Domain Name
            Registries (DNRs) to provide access to their resource
            registration information.  The core specifications for
            RDAP define basic search functionality, but there are
            various search options related to IP addresses, IP
            prefixes, and Autonomous System Numbers (ASNs), which are provided by RIRs via their
            WHOIS services, but for which there is no corresponding
            RDAP functionality.  This document extends RDAP to support
            those search options.

      </t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9910" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2026 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2">
              <li pn="section-toc.1-1.1.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-conventions-used-in-this-do">Conventions Used in This Document</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-basic-searches">Basic Searches</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.2.2">
              <li pn="section-toc.1-1.2.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.2.1.1"><xref derivedContent="2.1" format="counter" sectionFormat="of" target="section-2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-path-segments">Path Segments</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.2">
                <t indent="0" pn="section-toc.1-1.2.2.2.1"><xref derivedContent="2.2" format="counter" sectionFormat="of" target="section-2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ip-network-search">IP Network Search</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.3">
                <t indent="0" pn="section-toc.1-1.2.2.3.1"><xref derivedContent="2.3" format="counter" sectionFormat="of" target="section-2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-autonomous-system-number-se">Autonomous System Number Search</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-relation-searches">Relation Searches</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
              <li pn="section-toc.1-1.3.2.1">
                <t indent="0" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-path-segments-2">Path Segments</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.2">
                <t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-relation-search">Relation Search</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2.2.2">
                  <li pn="section-toc.1-1.3.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.3.2.2.2.1.1"><xref derivedContent="3.2.1" format="counter" sectionFormat="of" target="section-3.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-definitions">Definitions</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.2.2.2">
                    <t indent="0" pn="section-toc.1-1.3.2.2.2.2.1"><xref derivedContent="3.2.2" format="counter" sectionFormat="of" target="section-3.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-relations">Relations</xref></t>
                    <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2.2.2.2.2">
                      <li pn="section-toc.1-1.3.2.2.2.2.2.1">
                        <t indent="0" pn="section-toc.1-1.3.2.2.2.2.2.1.1"><xref derivedContent="3.2.2.1" format="counter" sectionFormat="of" target="section-3.2.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-single-result-searches">Single-Result Searches</xref></t>
                      </li>
                      <li pn="section-toc.1-1.3.2.2.2.2.2.2">
                        <t indent="0" pn="section-toc.1-1.3.2.2.2.2.2.2.1"><xref derivedContent="3.2.2.2" format="counter" sectionFormat="of" target="section-3.2.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-multiple-result-searches">Multiple-Result Searches</xref></t>
                      </li>
                    </ul>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.3.2.3">
                <t indent="0" pn="section-toc.1-1.3.2.3.1"><xref derivedContent="3.3" format="counter" sectionFormat="of" target="section-3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-status">Status</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.4">
                <t indent="0" pn="section-toc.1-1.3.2.4.1"><xref derivedContent="3.4" format="counter" sectionFormat="of" target="section-3.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-link-relations">Link Relations</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-responding-to-searches">Responding to Searches</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-single-result-searches-2">Single-Result Searches</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-multiple-result-searches-2">Multiple-Result Searches</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-reverse-search">Reverse Search</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-rdap-conformance">RDAP Conformance</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-operational-considerations">Operational Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-privacy-considerations">Privacy Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" format="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.10.2">
              <li pn="section-toc.1-1.10.2.1">
                <t indent="0" pn="section-toc.1-1.10.2.1.1"><xref derivedContent="10.1" format="counter" sectionFormat="of" target="section-10.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-rdap-extensions-registry">RDAP Extensions Registry</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.10.2.1.2">
                  <li pn="section-toc.1-1.10.2.1.2.1">
                    <t indent="0" pn="section-toc.1-1.10.2.1.2.1.1"><xref derivedContent="10.1.1" format="counter" sectionFormat="of" target="section-10.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-rirsearch1">rirSearch1</xref></t>
                  </li>
                  <li pn="section-toc.1-1.10.2.1.2.2">
                    <t indent="0" pn="section-toc.1-1.10.2.1.2.2.1"><xref derivedContent="10.1.2" format="counter" sectionFormat="of" target="section-10.1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ips">ips</xref></t>
                  </li>
                  <li pn="section-toc.1-1.10.2.1.2.3">
                    <t indent="0" pn="section-toc.1-1.10.2.1.2.3.1"><xref derivedContent="10.1.3" format="counter" sectionFormat="of" target="section-10.1.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-autnums">autnums</xref></t>
                  </li>
                  <li pn="section-toc.1-1.10.2.1.2.4">
                    <t indent="0" pn="section-toc.1-1.10.2.1.2.4.1"><xref derivedContent="10.1.4" format="counter" sectionFormat="of" target="section-10.1.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ipsearchresults">ipSearchResults</xref></t>
                  </li>
                  <li pn="section-toc.1-1.10.2.1.2.5">
                    <t indent="0" pn="section-toc.1-1.10.2.1.2.5.1"><xref derivedContent="10.1.5" format="counter" sectionFormat="of" target="section-10.1.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-autnumsearchresults">autnumSearchResults</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.10.2.2">
                <t indent="0" pn="section-toc.1-1.10.2.2.1"><xref derivedContent="10.2" format="counter" sectionFormat="of" target="section-10.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-link-relations-registry">Link Relations Registry</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.10.2.2.2">
                  <li pn="section-toc.1-1.10.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.10.2.2.2.1.1"><xref derivedContent="10.2.1" format="counter" sectionFormat="of" target="section-10.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-rdap-up-2">rdap-up</xref></t>
                  </li>
                  <li pn="section-toc.1-1.10.2.2.2.2">
                    <t indent="0" pn="section-toc.1-1.10.2.2.2.2.1"><xref derivedContent="10.2.2" format="counter" sectionFormat="of" target="section-10.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-rdap-down-2">rdap-down</xref></t>
                  </li>
                  <li pn="section-toc.1-1.10.2.2.2.3">
                    <t indent="0" pn="section-toc.1-1.10.2.2.2.3.1"><xref derivedContent="10.2.3" format="counter" sectionFormat="of" target="section-10.2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-rdap-top-2">rdap-top</xref></t>
                  </li>
                  <li pn="section-toc.1-1.10.2.2.2.4">
                    <t indent="0" pn="section-toc.1-1.10.2.2.2.4.1"><xref derivedContent="10.2.4" format="counter" sectionFormat="of" target="section-10.2.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-rdap-bottom-2">rdap-bottom</xref></t>
                  </li>
                  <li pn="section-toc.1-1.10.2.2.2.5">
                    <t indent="0" pn="section-toc.1-1.10.2.2.2.5.1"><xref derivedContent="10.2.5" format="counter" sectionFormat="of" target="section-10.2.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-rdap-active">rdap-active</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.10.2.3">
                <t indent="0" pn="section-toc.1-1.10.2.3.1"><xref derivedContent="10.3" format="counter" sectionFormat="of" target="section-10.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-rdap-reverse-search-registr">RDAP Reverse Search Registry</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.10.2.3.2">
                  <li pn="section-toc.1-1.10.2.3.2.1">
                    <t indent="0" pn="section-toc.1-1.10.2.3.2.1.1"><xref derivedContent="10.3.1" format="counter" sectionFormat="of" target="section-10.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-fn">fn</xref></t>
                  </li>
                  <li pn="section-toc.1-1.10.2.3.2.2">
                    <t indent="0" pn="section-toc.1-1.10.2.3.2.2.1"><xref derivedContent="10.3.2" format="counter" sectionFormat="of" target="section-10.3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-handle">handle</xref></t>
                  </li>
                  <li pn="section-toc.1-1.10.2.3.2.3">
                    <t indent="0" pn="section-toc.1-1.10.2.3.2.3.1"><xref derivedContent="10.3.3" format="counter" sectionFormat="of" target="section-10.3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-email">email</xref></t>
                  </li>
                  <li pn="section-toc.1-1.10.2.3.2.4">
                    <t indent="0" pn="section-toc.1-1.10.2.3.2.4.1"><xref derivedContent="10.3.4" format="counter" sectionFormat="of" target="section-10.3.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-role">role</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.10.2.4">
                <t indent="0" pn="section-toc.1-1.10.2.4.1"><xref derivedContent="10.4" format="counter" sectionFormat="of" target="section-10.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-rdap-reverse-search-mapping">RDAP Reverse Search Mapping Registry</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.10.2.4.2">
                  <li pn="section-toc.1-1.10.2.4.2.1">
                    <t indent="0" pn="section-toc.1-1.10.2.4.2.1.1"><xref derivedContent="10.4.1" format="counter" sectionFormat="of" target="section-10.4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-fn-2">fn</xref></t>
                  </li>
                  <li pn="section-toc.1-1.10.2.4.2.2">
                    <t indent="0" pn="section-toc.1-1.10.2.4.2.2.1"><xref derivedContent="10.4.2" format="counter" sectionFormat="of" target="section-10.4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-handle-2">handle</xref></t>
                  </li>
                  <li pn="section-toc.1-1.10.2.4.2.3">
                    <t indent="0" pn="section-toc.1-1.10.2.4.2.3.1"><xref derivedContent="10.4.3" format="counter" sectionFormat="of" target="section-10.4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-email-2">email</xref></t>
                  </li>
                  <li pn="section-toc.1-1.10.2.4.2.4">
                    <t indent="0" pn="section-toc.1-1.10.2.4.2.4.1"><xref derivedContent="10.4.4" format="counter" sectionFormat="of" target="section-10.4.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-role-2">role</xref></t>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="11" format="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.11.2">
              <li pn="section-toc.1-1.11.2.1">
                <t indent="0" pn="section-toc.1-1.11.2.1.1"><xref derivedContent="11.1" format="counter" sectionFormat="of" target="section-11.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.11.2.2">
                <t indent="0" pn="section-toc.1-1.11.2.2.1"><xref derivedContent="11.2" format="counter" sectionFormat="of" target="section-11.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.12">
            <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.13">
            <t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">
            The <xref target="RFC7480" format="default" sectionFormat="of" derivedContent="RFC7480">Registration Data Access
            Protocol (RDAP)</xref> is used by Regional Internet
            Registries (RIRs) and Domain Name Registries (DNRs) 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 RIR WHOIS
            <xref target="RFC3912" format="default" sectionFormat="of" derivedContent="RFC3912"/>
            services in this respect, this document defines additional
            search options for IP networks and autonomous system
            numbers.

      </t>
      <t indent="0" pn="section-1-2">
            
            While this document is written in terms of RIRs and DNRs for the
            sake of consistency with earlier RDAP documents such as <xref target="RFC9082" format="default" sectionFormat="of" derivedContent="RFC9082"/> and <xref target="RFC9083" format="default" sectionFormat="of" derivedContent="RFC9083"/>, the
            functionality described here may be used by any RDAP
            server operator that hosts Internet Number Resource (INR)
            objects.

      </t>
      <section anchor="conventions" numbered="true" toc="include" removeInRFC="false" pn="section-1.1">
        <name slugifiedName="name-conventions-used-in-this-do">Conventions Used in This Document</name>
        <t indent="0" pn="section-1.1-1">
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
    "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.
        </t>
        <t indent="0" pn="section-1.1-2">Indentation and whitespace in examples are provided
            only to illustrate element relationships and are not 
            required features of this specification.</t>
        <t indent="0" pn="section-1.1-3">"..." in examples is used as shorthand for elements
            defined outside of this document, as well as to abbreviate
            elements that are too long.</t>
      </section>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-basic-searches">Basic Searches</name>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-2.1">
        <name slugifiedName="name-path-segments">Path Segments</name>
        <t indent="0" pn="section-2.1-1">

                The new resource type path segments for basic search (similar to
                the searches defined in <xref target="RFC9082" format="default" sectionFormat="of" derivedContent="RFC9082"/> and <xref target="RFC9083" format="default" sectionFormat="of" derivedContent="RFC9083"/>) are:

        </t>
        <dl spacing="normal" newline="false" indent="3" pn="section-2.1-2">
          <dt pn="section-2.1-2.1">'ips':</dt>
          <dd pn="section-2.1-2.2">Used to identify an IP network search using a pattern to
  match one of a set of IP network attributes.</dd>
          <dt pn="section-2.1-2.3">'autnums':</dt>
          <dd pn="section-2.1-2.4">Used to identify an autonomous system number search
  using a pattern to match one of a set of autonomous system number
  attributes.</dd>
        </dl>
        <t indent="0" pn="section-2.1-3">

                A search pattern matches a value where it equals the
                string representation of the value, or where it is a
                match for the value in accordance with the use of the
                asterisk ('*', ASCII value 0x2A) character for
                partial string matching as defined in <xref target="RFC9082" sectionFormat="of" section="4.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9082#section-4.1" derivedContent="RFC9082"/>.
                For most searches, '*' may be used to match trailing
                characters only, and may appear in a search only once:
                see the previously mentioned section for a complete
                definition of the relevant behaviour.

        </t>
        <t indent="0" pn="section-2.1-4">

                <xref target="RFC9082" sectionFormat="of" section="4.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9082#section-4.1" derivedContent="RFC9082"/> describes the use of a trailing
                domain label suffix in a partial string search.  It is
                not necessary that servers support this type of search
                pattern for the basic searches defined in this
                document, since those searches do not relate to domain
                name members.

        </t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-2.2">
        <name slugifiedName="name-ip-network-search">IP Network Search</name>
        <dl spacing="normal" newline="false" indent="3" pn="section-2.2-1">
          <dt pn="section-2.2-1.1">Syntax:</dt>
          <dd pn="section-2.2-1.2">ips?handle=&lt;handle search pattern&gt;</dd>
          <dt pn="section-2.2-1.3">Syntax:</dt>
          <dd pn="section-2.2-1.4">ips?name=&lt;name search pattern&gt;</dd>
        </dl>
        <t indent="0" pn="section-2.2-2">

                Searches for IP network (see <xref target="RFC9083" sectionFormat="of" section="5.4" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9083#section-5.4" derivedContent="RFC9083"/>) information by
                handle are specified using the form:

        </t>
        <t indent="3" pn="section-2.2-3">

                ips?handle=XXXX

        </t>
        <t indent="0" pn="section-2.2-4">

                XXXX is a search pattern representing an IP network
                identifier whose syntax 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:

        </t>
        <t indent="3" pn="section-2.2-5">

                https://example.com/rdap/ips?handle=NET-199*

        </t>
        <t indent="0" pn="section-2.2-6">

                Searches for IP network (see <xref target="RFC9083" sectionFormat="of" section="5.4" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9083#section-5.4" derivedContent="RFC9083"/>) information by
                name are specified using the form:

        </t>
        <t indent="3" pn="section-2.2-7">

                ips?name=XXXX

        </t>
        <t indent="0" pn="section-2.2-8">

                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:

        </t>
        <t indent="3" pn="section-2.2-9">

                https://example.com/rdap/ips?name=NET-EXAMPLE-*

        </t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-2.3">
        <name slugifiedName="name-autonomous-system-number-se">Autonomous System Number Search</name>
        <dl spacing="normal" newline="false" indent="3" pn="section-2.3-1">
          <dt pn="section-2.3-1.1">Syntax:</dt>
          <dd pn="section-2.3-1.2">autnums?handle=&lt;handle search pattern&gt;</dd>
          <dt pn="section-2.3-1.3">Syntax:</dt>
          <dd pn="section-2.3-1.4">autnums?name=&lt;name search pattern&gt;</dd>
        </dl>
        <t indent="0" pn="section-2.3-2">
                Searches for autonomous system number (see <xref target="RFC9083" sectionFormat="of" section="5.5" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9083#section-5.5" derivedContent="RFC9083"/>)
                information by handle are specified using the form:

        </t>
        <t indent="3" pn="section-2.3-3">

                autnums?handle=XXXX

        </t>
        <t indent="0" pn="section-2.3-4">

                XXXX is a search pattern representing an autonomous
                system number identifier whose syntax 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:

        </t>
        <t indent="3" pn="section-2.3-5">

                https://example.com/rdap/autnums?handle=AS1*

        </t>
        <t indent="0" pn="section-2.3-6">

                Searches for autonomous system number (see <xref target="RFC9083" sectionFormat="of" section="5.5" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9083#section-5.5" derivedContent="RFC9083"/>)
                information by name are specified using the form:

        </t>
        <t indent="3" pn="section-2.3-7">

                autnums?name=XXXX

        </t>
        <t indent="0" pn="section-2.3-8">

                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:

        </t>
        <t indent="3" pn="section-2.3-9">

                https://example.com/rdap/autnums?name=ASN-EXAMPLE-*

        </t>
      </section>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-relation-searches">Relation Searches</name>
      <t indent="0" pn="section-3-1">

            This section defines searches and link relations for
            finding objects and sets of objects with respect to their
            position within a hierarchy.

      </t>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-3.1">
        <name slugifiedName="name-path-segments-2">Path Segments</name>
        <t indent="0" pn="section-3.1-1">

                The variables used in the path segments in this
                section include:

        </t>
        <dl spacing="normal" newline="false" indent="3" pn="section-3.1-2">
          <dt pn="section-3.1-2.1">&lt;relation&gt;:</dt>
          <dd pn="section-3.1-2.2">a relation type, as defined in <xref target="sec3.2.2" format="default" sectionFormat="of" derivedContent="Section 3.2.2"/>
  of this document.</dd>
          <dt pn="section-3.1-2.3">&lt;IP address&gt;:</dt>
          <dd pn="section-3.1-2.4">an IP address, as defined in <xref target="RFC9082" sectionFormat="of" section="3.1.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9082#section-3.1.1" derivedContent="RFC9082"/>.</dd>
          <dt pn="section-3.1-2.5">&lt;CIDR prefix&gt;:</dt>
          <dd pn="section-3.1-2.6">the first address of a Classless Inter-Domain Routing (CIDR) block, as
  defined in <xref target="RFC9082" sectionFormat="of" section="3.1.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9082#section-3.1.1" derivedContent="RFC9082"/>.</dd>
          <dt pn="section-3.1-2.7">&lt;CIDR length&gt;:</dt>
          <dd pn="section-3.1-2.8">the prefix length for a CIDR block, as
  defined in <xref target="RFC9082" sectionFormat="of" section="3.1.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9082#section-3.1.1" derivedContent="RFC9082"/>.</dd>
          <dt pn="section-3.1-2.9">&lt;domain name&gt;:</dt>
          <dd pn="section-3.1-2.10">a fully qualified domain name, as defined
  in <xref target="RFC9082" sectionFormat="of" section="3.1.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9082#section-3.1.3" derivedContent="RFC9082"/>.</dd>
          <dt pn="section-3.1-2.11">&lt;autonomous system number or range&gt;:</dt>
          <dd pn="section-3.1-2.12">an autonomous system
  number, as defined in <xref target="RFC9082" sectionFormat="of" section="3.1.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9082#section-3.1.2" derivedContent="RFC9082"/>, or two such numbers separated by a
  single hyphen ('-', ASCII value 0x2D), where the second number is greater
  than the first.</dd>
          <dt pn="section-3.1-2.13">&lt;resource type search path segment&gt;:</dt>
          <dd pn="section-3.1-2.14">a search path segment
  corresponding to an Internet Number Resource (INR) object class (i.e., an IP
  network address or range, autonomous system number or number range, or
  reverse domain name).</dd>
          <dt pn="section-3.1-2.15">&lt;object value&gt;:</dt>
          <dd pn="section-3.1-2.16">a value used to identify an object for the
  purposes of a relation search relative to that object.  One of &lt;IP
  address&gt;, &lt;CIDR prefix&gt; and &lt;CIDR length&gt; pair, &lt;domain
  name&gt;, or &lt;autonomous system number or range&gt;, depending on the
  type of search that is being performed.</dd>
          <dt pn="section-3.1-2.17">&lt;status&gt;:</dt>
          <dd pn="section-3.1-2.18">an object status value, as defined in <xref target="RFC9083" sectionFormat="of" section="4.6" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9083#section-4.6" derivedContent="RFC9083"/>.</dd>
        </dl>
        <t indent="0" pn="section-3.1-3">

                The new resource type path segments for relation
                search (similar to the searches defined in <xref target="RFC9082" format="default" sectionFormat="of" derivedContent="RFC9082"/> and <xref target="RFC9083" format="default" sectionFormat="of" derivedContent="RFC9083"/>)
                are:

        </t>
        <dl spacing="normal" newline="false" indent="3" pn="section-3.1-4">
          <dt pn="section-3.1-4.1">'ips/rirSearch1/&lt;relation&gt;/&lt;IP address&gt;':</dt>
          <dd pn="section-3.1-4.2">Used to identify an IP network search using a relation and an IP address
  to match a set of IP networks.</dd>
          <dt pn="section-3.1-4.3">'ips/rirSearch1/&lt;relation&gt;/&lt;CIDR prefix&gt;/&lt;CIDR length&gt;':</dt>
          <dd pn="section-3.1-4.4">Used to identify an IP network search using a relation and an IP address
  range to match a set of IP networks.</dd>
          <dt pn="section-3.1-4.5">'autnums/rirSearch1/&lt;relation&gt;/&lt;autonomous system number or range&gt;':</dt>
          <dd pn="section-3.1-4.6">Used to identify an autonomous system number search using a relation and
  a single ASN or an ASN range to match a set of ASN objects.</dd>
          <dt pn="section-3.1-4.7">'domains/rirSearch1/&lt;relation&gt;/&lt;domain name&gt;':</dt>
          <dd pn="section-3.1-4.8">Used to identify a reverse domain search using a relation and a reverse
  domain name to match a set of reverse domains.</dd>
        </dl>
      </section>
      <section anchor="relation-search" numbered="true" toc="include" removeInRFC="false" pn="section-3.2">
        <name slugifiedName="name-relation-search">Relation Search</name>
        <dl spacing="normal" newline="false" indent="3" pn="section-3.2-1">
          <dt pn="section-3.2-1.1">Syntax:</dt>
          <dd pn="section-3.2-1.2">&lt;resource type search path segment&gt;/rirSearch1/&lt;relation&gt;/&lt;object value&gt;[?status=&lt;status&gt;]</dd>
        </dl>
        <t indent="0" pn="section-3.2-2">

                The relation searches defined in this document rely on
                the syntax described above.  Each search works in the
                same way for each object class.

        </t>
        <t indent="0" pn="section-3.2-3">

                The rirSearch1 path segment is used in the relation
                search URLs in order to provide a single namespace for
                those searches, and so that other searches can be
                defined underneath the top-level resource type search
                path segments.

        </t>
        <section anchor="sec3.2.1" numbered="true" toc="include" removeInRFC="false" pn="section-3.2.1">
          <name slugifiedName="name-definitions">Definitions</name>
          <t indent="0" pn="section-3.2.1-1">
    
                    An INR object value 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, let's say there is a
                    registry with the following IP network objects:
    
          </t>
          <figure anchor="registry-objects" align="left" suppress-title="false" pn="figure-1">
            <name slugifiedName="name-example-registry-objects">Example Registry Objects</name>
            <artwork align="left" pn="section-3.2.1-2.1">
                        +--------------+
                        | 192.0.2.0/24 |
                        +--------------+
                           /        \
              +--------------+    +----------------+
              | 192.0.2.0/25 |    | 192.0.2.128/25 |
              +--------------+    +----------------+
                 /                   /          \
     +--------------+   +----------------+  +----------------+
     | 192.0.2.0/28 |   | 192.0.2.128/26 |  | 192.0.2.192/26 |
     +--------------+   +----------------+  +----------------+
        /
 +--------------+
 | 192.0.2.0/32 |
 +--------------+</artwork>
          </figure>
          <t indent="0" pn="section-3.2.1-3">
    
                    For this example registry, the INR object value to parent/child object relationships are:
    
          </t>
          <table anchor="parent" align="center" pn="table-1">
            <name slugifiedName="name-parent-objects">Parent Objects</name>
            <thead>
              <tr>
                <th align="left" colspan="1" rowspan="1">INR object value</th>
                <th align="left" colspan="1" rowspan="1">Parent object</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left" colspan="1" rowspan="1">192.0.2.0/32</td>
                <td align="left" colspan="1" rowspan="1">192.0.2.0/28</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">192.0.2.0/28</td>
                <td align="left" colspan="1" rowspan="1">192.0.2.0/25</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">192.0.2.64/26</td>
                <td align="left" colspan="1" rowspan="1">192.0.2.0/25</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">192.0.2.128/26</td>
                <td align="left" colspan="1" rowspan="1">192.0.2.128/25</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">192.0.2.192/26</td>
                <td align="left" colspan="1" rowspan="1">192.0.2.128/25</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">192.0.2.0/25</td>
                <td align="left" colspan="1" rowspan="1">192.0.2.0/24</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">192.0.2.128/25</td>
                <td align="left" colspan="1" rowspan="1">192.0.2.0/24</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">192.0.2.0/24</td>
                <td align="left" colspan="1" rowspan="1">N/A</td>
              </tr>
            </tbody>
          </table>
          <table anchor="children" align="center" pn="table-2">
            <name slugifiedName="name-child-objects">Child Objects</name>
            <thead>
              <tr>
                <th align="left" colspan="1" rowspan="1">INR object value</th>
                <th align="left" colspan="1" rowspan="1">Child objects</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left" colspan="1" rowspan="1">192.0.2.0/24</td>
                <td align="left" colspan="1" rowspan="1">192.0.2.0/25, 192.0.2.128/25</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">192.0.2.0/25</td>
                <td align="left" colspan="1" rowspan="1">192.0.2.0/28</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">192.0.2.128/25</td>
                <td align="left" colspan="1" rowspan="1">192.0.2.128/26, 192.0.2.192/26</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">192.0.2.64/26</td>
                <td align="left" colspan="1" rowspan="1">N/A</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">192.0.2.128/26</td>
                <td align="left" colspan="1" rowspan="1">N/A</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">192.0.2.192/26</td>
                <td align="left" colspan="1" rowspan="1">N/A</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">192.0.2.0/28</td>
                <td align="left" colspan="1" rowspan="1">192.0.2.0/32</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">192.0.2.0/32</td>
                <td align="left" colspan="1" rowspan="1">N/A</td>
              </tr>
            </tbody>
          </table>
          <t indent="0" pn="section-3.2.1-6">

                    (INR object values do not necessarily correspond
                    to registry objects, because users can provide
                    arbitrary object values as input to the searches
                    defined in this document.)

          </t>
          <t indent="0" pn="section-3.2.1-7">
    
                    Similarly to the parent/child object
                    relationships, each INR object value may have a
                    "top" object, being the least-specific covering
                    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
                    above, the top and bottom
                    object relationships are:
    
          </t>
          <table anchor="top" align="center" pn="table-3">
            <name slugifiedName="name-top-objects">Top Objects</name>
            <thead>
              <tr>
                <th align="left" colspan="1" rowspan="1">INR object value</th>
                <th align="left" colspan="1" rowspan="1">Top object</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left" colspan="1" rowspan="1">192.0.2.0/32</td>
                <td align="left" colspan="1" rowspan="1">192.0.2.0/24</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">192.0.2.0/28</td>
                <td align="left" colspan="1" rowspan="1">192.0.2.0/24</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">192.0.2.64/26</td>
                <td align="left" colspan="1" rowspan="1">192.0.2.0/24</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">192.0.2.128/26</td>
                <td align="left" colspan="1" rowspan="1">192.0.2.0/24</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">192.0.2.192/26</td>
                <td align="left" colspan="1" rowspan="1">192.0.2.0/24</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">192.0.2.0/25</td>
                <td align="left" colspan="1" rowspan="1">192.0.2.0/24</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">192.0.2.128/25</td>
                <td align="left" colspan="1" rowspan="1">192.0.2.0/24</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">192.0.2.0/24</td>
                <td align="left" colspan="1" rowspan="1">N/A</td>
              </tr>
            </tbody>
          </table>
          <table anchor="bottom" align="center" pn="table-4">
            <name slugifiedName="name-bottom-objects">Bottom Objects</name>
            <thead>
              <tr>
                <th align="left" colspan="1" rowspan="1">INR object value</th>
                <th align="left" colspan="1" rowspan="1">Bottom objects</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left" colspan="1" rowspan="1">192.0.2.0/24</td>
                <td align="left" colspan="1" rowspan="1">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</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">192.0.2.0/25</td>
                <td align="left" colspan="1" rowspan="1">192.0.2.0/25, 192.0.2.0/28, 192.0.2.0/32</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">192.0.2.128/25</td>
                <td align="left" colspan="1" rowspan="1">192.0.2.128/26, 192.0.2.192/26</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">192.0.2.64/26</td>
                <td align="left" colspan="1" rowspan="1">N/A</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">192.0.2.128/26</td>
                <td align="left" colspan="1" rowspan="1">N/A</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">192.0.2.192/26</td>
                <td align="left" colspan="1" rowspan="1">N/A</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">192.0.2.0/28</td>
                <td align="left" colspan="1" rowspan="1">192.0.2.0/28, 192.0.2.0/32</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">192.0.2.0/31</td>
                <td align="left" colspan="1" rowspan="1">192.0.2.0/28, 192.0.2.0/32</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">192.0.2.0/32</td>
                <td align="left" colspan="1" rowspan="1">N/A</td>
              </tr>
            </tbody>
          </table>
          <t indent="0" pn="section-3.2.1-10">
   
                    If there are no more-specific objects for a given
                    INR object value, then the set of bottom objects
                    for that INR object value will be empty.
                    192.0.2.0/32 is an example of such an INR object
                    value.

          </t>
          <t indent="0" pn="section-3.2.1-11">

                    It is not necessarily the case that the bottom
                    objects for a given INR object value will be
                    disjoint.  For example, 192.0.2.0/28's bottom
                    objects are 192.0.2.0/28 and 192.0.2.0/32.
                    192.0.2.0/32 is included because it is one of the 
                    most-specific objects (i.e., an object at the bottom
                    of the object hierarchy) for 192.0.2.0/28, while
                    192.0.2.0/28 itself is included because it is the
                    most-specific object for the other addresses
                    within the range (i.e., those aside from
                    192.0.2.0/32).

          </t>
          <t indent="0" pn="section-3.2.1-12">

                    The bottom objects for a given INR object value
                    may include an object 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, 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
                    (i.e., 192.0.2.1/32) is 192.0.2.0/28, so it is
                    included in the results as well.

          </t>
        </section>
        <section anchor="sec3.2.2" numbered="true" toc="include" removeInRFC="false" pn="section-3.2.2">
          <name slugifiedName="name-relations">Relations</name>
          <section numbered="true" toc="include" removeInRFC="false" pn="section-3.2.2.1">
            <name slugifiedName="name-single-result-searches">Single-Result Searches</name>
            <section numbered="true" toc="exclude" removeInRFC="false" pn="section-3.2.2.1.1">
              <name slugifiedName="name-rdap-up">"rdap-up"</name>
              <t indent="0" pn="section-3.2.2.1.1-1">

                            If the server receives a search containing
                            the relation value "rdap-up", it will
                            return the parent 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) <xref target="RFC9110" format="default" sectionFormat="of" derivedContent="RFC9110"/>
                            status code.

              </t>
            </section>
            <section numbered="true" toc="exclude" removeInRFC="false" pn="section-3.2.2.1.2">
              <name slugifiedName="name-rdap-top">"rdap-top"</name>
              <t indent="0" pn="section-3.2.2.1.2-1">

                            If the server receives a search containing
                            the relation value "rdap-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) <xref target="RFC9110" format="default" sectionFormat="of" derivedContent="RFC9110"/> status code.

              </t>
            </section>
          </section>
          <section numbered="true" toc="include" removeInRFC="false" pn="section-3.2.2.2">
            <name slugifiedName="name-multiple-result-searches">Multiple-Result Searches</name>
            <section numbered="true" toc="exclude" removeInRFC="false" pn="section-3.2.2.2.1">
              <name slugifiedName="name-rdap-down">"rdap-down"</name>
              <t indent="0" pn="section-3.2.2.2.1-1">

                            If the server receives a search containing
                            the relation value "rdap-down", it will
                            return the child objects for the specified
                            INR object value.  If no such objects
                            exist, it will return an empty search
                            response.  Per the definitions section,
                            this includes only immediate child
                            objects.

              </t>
            </section>
            <section numbered="true" toc="exclude" removeInRFC="false" pn="section-3.2.2.2.2">
              <name slugifiedName="name-rdap-bottom">"rdap-bottom"</name>
              <t indent="0" pn="section-3.2.2.2.2-1">

                            If the server receives a search containing
                            the relation value "rdap-bottom", it will
                            return the bottom objects for the
                            specified INR object value.  If no such
                            objects exist, it will return an empty
                            search response.

              </t>
            </section>
          </section>
        </section>
      </section>
      <section anchor="status" numbered="true" toc="include" removeInRFC="false" pn="section-3.3">
        <name slugifiedName="name-status">Status</name>
        <t indent="0" pn="section-3.3-1">

                If the "status" argument is provided, then response
                processing will proceed as though all objects without
                the specified status had first been removed from the
                database.  For example, if the registry objects from
                <xref target="sec3.2.1" format="default" sectionFormat="of" derivedContent="Section 3.2.1"/> had the following statuses:

        </t>
        <table anchor="statuses" align="center" pn="table-5">
          <name slugifiedName="name-statuses">Statuses</name>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Object</th>
              <th align="left" colspan="1" rowspan="1">Status</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">192.0.2.0/25</td>
              <td align="left" colspan="1" rowspan="1">active</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">192.0.2.128/25</td>
              <td align="left" colspan="1" rowspan="1">inactive</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">192.0.2.128/26</td>
              <td align="left" colspan="1" rowspan="1">active</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">192.0.2.192/26</td>
              <td align="left" colspan="1" rowspan="1">active</td>
            </tr>
          </tbody>
        </table>
        <t indent="0" pn="section-3.3-3">

                then a server receiving a "rdap-down" search request
                with the INR object 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.

        </t>
        <t indent="0" pn="section-3.3-4">

                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 the "rdap-top"
                relation with a "status" of "active", the delegation
                from IANA to the RIR will be ignored, and the client
                will receive the delegation from the RIR to the
                account holder in the response instead.

        </t>
        <t indent="0" pn="section-3.3-5">

                By default, any valid status value may be used for
                status filtering.  Server operators <bcp14>MAY</bcp14> opt not to
                support "status" filtering for the "rdap-down" and
                "rdap-bottom" link relations, in which case the server
                responds with an HTTP 501 (Not Implemented) <xref target="RFC9110" format="default" sectionFormat="of" derivedContent="RFC9110"/> response code if it receives such
                a request.  Server operators <bcp14>MAY</bcp14> also opt not to
                support "status" filtering for values other than
                "active" for the "rdap-up" and "rdap-top" link
                relations, in which case the server responds with an
                HTTP 501 (Not Implemented) <xref target="RFC9110" format="default" sectionFormat="of" derivedContent="RFC9110"/>
                response code if it receives such a request.

        </t>
        <t indent="0" pn="section-3.3-6">

                While any valid status value may be used for status
                filtering, a given RDAP server may make use of only a
                small number of those status values for INR objects.
                For example, a status value like "client hold" would
                typically only be used by a DNR for a forward domain
                name object.

        </t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-3.4">
        <name slugifiedName="name-link-relations">Link Relations</name>
        <t indent="0" pn="section-3.4-1">

                Each of the relations defined in <xref target="sec3.2.2" format="default" sectionFormat="of" derivedContent="Section 3.2.2"/> has a
                corresponding link relation that can be used for a
                link object contained within another RDAP object.
                When constructing these link objects, the server <bcp14>MUST</bcp14>
                use the corresponding search URL for the link target,
                or a URL that yields the same response as for the
                corresponding search as at the time of the request.
                The following is an elided example of an IPv4 response
                that makes use of those link relations:

        </t>
        <figure anchor="example-links-ipv4" align="left" suppress-title="false" pn="figure-2">
          <name slugifiedName="name-example-links-in-an-ipv4-re">Example Links in an IPv4 Response</name>
          <sourcecode type="json" markers="false" pn="section-3.4-2.1">
{
  "startAddress": "192.0.2.0",
  "endAddress": "192.0.2.127",
  ...
  "links": [
    ...,
    {
      "value": "https://example.com/rdap/ip/192.0.2.0/25",
      "rel": "rdap-up",
      "href": ".../rdap/ips/rirSearch1/rdap-up/192.0.2.0/25",
      "type": "application/rdap+json"
    },
    {
      "value": "https://example.com/rdap/ip/192.0.2.0/25",
      "rel": "rdap-down",
      "href": ".../rdap/ips/rirSearch1/rdap-down/192.0.2.0/25",
      "type": "application/rdap+json"
    },
    {
      "value": "https://example.com/rdap/ip/192.0.2.0/25",
      "rel": "rdap-top",
      "href": ".../rdap/ips/rirSearch1/rdap-top/192.0.2.0/25",
      "type": "application/rdap+json"
    },
    {
      "value": "https://example.com/rdap/ip/192.0.2.0/25",
      "rel": "rdap-bottom",
      "href": ".../rdap/ips/rirSearch1/rdap-bottom/192.0.2.0/25",
      "type": "application/rdap+json"
    }
  ]
}</sourcecode>
        </figure>
        <t indent="0" pn="section-3.4-3">

                The following is an elided example of an IPv6 response
                that makes use of the link relations:

        </t>
        <figure anchor="example-links-ipv6" align="left" suppress-title="false" pn="figure-3">
          <name slugifiedName="name-example-links-in-an-ipv6-re">Example Links in an IPv6 Response</name>
          <sourcecode type="json" markers="false" pn="section-3.4-4.1">
{
  "startAddress": "2001:db8:a::",
  "endAddress": "2001:db8:a:ffff:ffff:ffff:ffff:ffff",
  ...
  "links": [
    ...,
    {
      "value": "https://example.com/rdap/ip/2001:db8:a::/48",
      "rel": "rdap-up",
      "href": ".../rdap/ips/rirSearch1/rdap-up/2001:db8:a::/48",
      "type": "application/rdap+json"
    },
    {
      "value": "https://example.com/rdap/ip/2001:db8:a::/48",
      "rel": "rdap-down",
      "href": ".../rdap/ips/rirSearch1/rdap-down/2001:db8:a::/48",
      "type": "application/rdap+json"
    },
    {
      "value": "https://example.com/rdap/ip/2001:db8:a::/48",
      "rel": "rdap-top",
      "href": ".../rdap/ips/rirSearch1/rdap-top/2001:db8:a::/48",
      "type": "application/rdap+json"
    },
    {
      "value": "https://example.com/rdap/ip/2001:db8:a::/48",
      "rel": "rdap-bottom",
      "href": ".../rdap/ips/rirSearch1/rdap-bottom/2001:db8:a::/48",
      "type": "application/rdap+json"
    }
  ]
}</sourcecode>
        </figure>
        <t indent="0" pn="section-3.4-5">

                One additional link relation, "rdap-active", is
                defined for denoting a search with a "status" of
                "active".  No other status link relations are defined
                because the only known use cases for status filtering
                involve the "rdap-up" and "rdap-top" relations and the
                "active" status.  The following is an elided example
                of an IPv4 response that makes use of those link
                relations:

        </t>
        <figure anchor="example-status-links-ipv4" align="left" suppress-title="false" pn="figure-4">
          <name slugifiedName="name-example-status-links-in-an-">Example Status Links in an IPv4 Response</name>
          <sourcecode type="json" markers="false" pn="section-3.4-6.1">
{
  "startAddress": "192.0.2.0",
  "endAddress": "192.0.2.127",
  ...
  "links": [
    ...,
    {
      "value": "https://example.com/rdap/ip/192.0.2.0/25",
      "rel": "rdap-up rdap-active",
      "href":
       ".../rdap/ips/rirSearch1/rdap-up/192.0.2.0/25?status=active",
      "type": "application/rdap+json"
    },
    {
      "value": "https://example.com/rdap/ip/192.0.2.0/25",
      "rel": "rdap-top rdap-active",
      "href":
       ".../rdap/ips/rirSearch1/rdap-top/192.0.2.0/25?status=active",
      "type": "application/rdap+json"
    }
  ]
}</sourcecode>
        </figure>
        <t indent="0" pn="section-3.4-7">

                The following is an elided example of an IPv6 response
                that makes use of the link relations:

        </t>
        <figure anchor="example-status-links-ipv6" align="left" suppress-title="false" pn="figure-5">
          <name slugifiedName="name-example-status-links-in-an-i">Example Status Links in an IPv6 Response</name>
          <sourcecode type="json" markers="false" pn="section-3.4-8.1">
{
  "startAddress": "2001:db8:a::",
  "endAddress": "2001:db8:a:ffff:ffff:ffff:ffff:ffff",
  ...
  "links": [
    ...,
    {
      "value": "https://example.com/rdap/ip/2001:db8:a::/48",
      "rel": "rdap-up rdap-active",
      "href":
     ".../rdap/ips/rirSearch1/rdap-up/2001:db8:a::/48?status=active",
      "type": "application/rdap+json"
    },
    {
      "value": "https://example.com/rdap/ip/2001:db8:a::/48",
      "rel": "rdap-top rdap-active",
      "href":
    ".../rdap/ips/rirSearch1/rdap-top/2001:db8:a::/48?status=active",
      "type": "application/rdap+json"
    }
  ]
}</sourcecode>
        </figure>
        <t indent="0" pn="section-3.4-9">

                "rdap-active" is used only as a link relation in a
                link object.  It cannot be used as a value for
                &lt;relation&gt; in the relation search URL defined in
                <xref target="relation-search" format="default" sectionFormat="of" derivedContent="Section 3.2"/>.  <xref target="status" format="default" sectionFormat="of" derivedContent="Section 3.3"/> details status filtering for
                relation search URLs.

        </t>
        <t indent="0" pn="section-3.4-10">

                Since the "rdap-top" and "rdap-up" link relations
                resolve either to a single object or to an HTTP 404
                (Not Found) <xref target="RFC9110" format="default" sectionFormat="of" derivedContent="RFC9110"/> response, it is
                possible for a server to use a lookup URL (see <xref target="RFC9082" sectionFormat="of" section="3.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9082#section-3.1" derivedContent="RFC9082"/>)
                in the "href" attribute in the link object.  The
                following is an elided example of an IPv4 response
                that uses this approach:

        </t>
        <figure anchor="example-object-links-ipv4" align="left" suppress-title="false" pn="figure-6">
          <name slugifiedName="name-example-single-result-links">Example Single-Result Links in an IPv4 Response</name>
          <sourcecode type="json" markers="false" pn="section-3.4-11.1">
{
  "startAddress": "192.0.2.0",
  "endAddress": "192.0.2.127",
  ...
  "links": [
    ...,
    {
      "value": "https://example.com/rdap/ip/192.0.2.0/25",
      "rel": "rdap-up",
      "href": "https://example.com/rdap/ip/192.0.2.0/24",
      "type": "application/rdap+json"
    }
  ]
}</sourcecode>
        </figure>
        <t indent="0" pn="section-3.4-12">

                The following is an elided example of an IPv6 response
                that makes use of the approach:

        </t>
        <figure anchor="example-object-links-ipv6" align="left" suppress-title="false" pn="figure-7">
          <name slugifiedName="name-example-single-result-links-">Example Single-Result Links in an IPv6 Response</name>
          <sourcecode type="json" markers="false" pn="section-3.4-13.1">
{
  "startAddress": "2001:db8:a::",
  "endAddress": "2001:db8:a:ffff:ffff:ffff:ffff:ffff",
  ...
  "links": [
    ...,
    {
      "value": "https://example.com/rdap/ip/2001:db8:a::/48",
      "rel": "rdap-up",
      "href": "https://example.com/rdap/ip/2001:db8::/32",
      "type": "application/rdap+json"
    }
  ]
}</sourcecode>
        </figure>
        <t indent="0" pn="section-3.4-14">

                Use of these link relations in responses is <bcp14>OPTIONAL</bcp14>.
                The absence in a response of a link for a specific
                relation does not necessarily mean that the
                corresponding search will return no results.

        </t>
      </section>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-responding-to-searches">Responding to Searches</name>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-4.1">
        <name slugifiedName="name-single-result-searches-2">Single-Result Searches</name>
        <t indent="0" pn="section-4.1-1">

                The "rdap-up" and "rdap-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 <xref target="RFC9082" sectionFormat="of" section="3.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9082#section-3.1" derivedContent="RFC9082"/>).  If there is no
                result for the search, the server returns an HTTP 404
                (Not Found) <xref target="RFC9110" format="default" sectionFormat="of" derivedContent="RFC9110"/> response code.

        </t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-4.2">
        <name slugifiedName="name-multiple-result-searches-2">Multiple-Result Searches</name>
        <t indent="0" pn="section-4.2-1">

                The "rdap-down" and "rdap-bottom" relations are
                multiple-result searches.  As with <xref target="RFC9083" format="default" sectionFormat="of" derivedContent="RFC9083"/>, responses for these searches take
                the form of an array of object instances, where each
                instance is an appropriate object class for the search
                (i.e., a search beginning with /ips yields an array of
                IP network object instances, and a search beginning
                with /autnums yields an array of autonomous system
                number object instances).  The IP network object class
                is defined in <xref target="RFC9083" sectionFormat="of" section="5.4" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9083#section-5.4" derivedContent="RFC9083"/>, and the
                autonomous system number object class is defined in
                <xref target="RFC9083" sectionFormat="of" section="5.5" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9083#section-5.5" derivedContent="RFC9083"/>.  The object instance arrays are
                contained within the response object.

        </t>
        <t indent="0" pn="section-4.2-2">
                The names of the arrays are as follows:
        </t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.2-3">
          <li pn="section-4.2-3.1">for /ips searches, the array is "ipSearchResults"; and</li>
          <li pn="section-4.2-3.2">for /autnums searches, the array is "autnumSearchResults".</li>
        </ul>
        <t indent="0" pn="section-4.2-4">

                The following is an elided example of a response for
                an IPv4 network search:

        </t>
        <figure anchor="ip-network-search-response-ipv4" align="left" suppress-title="false" pn="figure-8">
          <name slugifiedName="name-ipv4-network-search-respons">IPv4 Network Search Response</name>
          <sourcecode type="json" markers="false" pn="section-4.2-5.1">
{
  "rdapConformance": [ "rdap_level_0", "rirSearch1",
                       "ips", "ipSearchResults", ... ],
  ...
  "ipSearchResults": [
    {
      "objectClassName": "ip network",
      "handle": "XXXX-RIR",
      "startAddress": "192.0.2.0",
      "endAddress": "192.0.2.127",
      ...
    },
    {
      "objectClassName": "ip network",
      "handle": "YYYY-RIR",
      "startAddress": "192.0.2.0",
      "endAddress": "192.0.2.255",
      ...
    }
  ]
}
</sourcecode>
        </figure>
        <t indent="0" pn="section-4.2-6">

                The following is an elided example of a response for
                an IPv6 network search:

        </t>
        <figure anchor="ip-network-search-response-ipv6" align="left" suppress-title="false" pn="figure-9">
          <name slugifiedName="name-ipv6-network-search-respons">IPv6 Network Search Response</name>
          <sourcecode type="json" markers="false" pn="section-4.2-7.1">
{
  "rdapConformance": [ "rdap_level_0", "rirSearch1",
                       "ips", "ipSearchResults", ... ],
  ...
  "ipSearchResults": [
    {
      "objectClassName": "ip network",
      "handle": "XXXX-RIR",
      "startAddress": "2001:db8:a::",
      "endAddress": "2001:db8:a:ffff:ffff:ffff:ffff:ffff",
      ...
    },
    {
      "objectClassName": "ip network",
      "handle": "YYYY-RIR",
      "startAddress": "2001:db8::",
      "endAddress": "2001:db8:ffff:ffff:ffff:ffff:ffff:ffff",
      ...
    }
  ]
}
</sourcecode>
        </figure>
        <t indent="0" pn="section-4.2-8">

                The following is an elided example of a response to an
                autonomous system number search:

        </t>
        <figure anchor="asn-search-response" align="left" suppress-title="false" pn="figure-10">
          <name slugifiedName="name-asn-search-response">ASN Search Response</name>
          <sourcecode type="json" markers="false" pn="section-4.2-9.1">
{
  "rdapConformance": [ "rdap_level_0", "rirSearch1",
                       "autnums", "autnumSearchResults", ... ],
  ...
  "autnumSearchResults": [
    {
      "objectClassName": "autnum",
      "handle": "XXXX-RIR",
      "startAutnum": 64496,
      "endAutnum": 64496,
      ...
    },
    {
      "objectClassName": "autnum",
      "handle": "YYYY-RIR",
      "startAutnum": "64497",
      "endAutnum": "64497",
      ...
    }
  ]
}
</sourcecode>
        </figure>
        <t indent="0" pn="section-4.2-10">

                Responses for relation searches for reverse domain objects
                have the same form as for a standard domain search
                response, per <xref target="RFC9083" format="default" sectionFormat="of" derivedContent="RFC9083"/>.

        </t>
        <t indent="0" pn="section-4.2-11">

                If the search can be processed by the server, but
                there are no results for the search, then the server
                returns an HTTP 404 (Not Found) <xref target="RFC9110" format="default" sectionFormat="of" derivedContent="RFC9110"/> response code, with the body of the response
                containing an empty results array.

        </t>
      </section>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-reverse-search">Reverse Search</name>
      <t indent="0" pn="section-5-1">

            RDAP reverse search is defined by <xref target="RFC9536" format="default" sectionFormat="of" derivedContent="RFC9536"/>.  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.

      </t>
      <t indent="0" pn="section-5-2">

            If a server receives a reverse search query with a
            searchable resource type (per the definition of that term
            in <xref target="RFC9536" format="default" sectionFormat="of" derivedContent="RFC9536"/>) 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.

      </t>
      <t indent="0" pn="section-5-3">

            Additionally, <xref target="IANA" format="default" sectionFormat="of" derivedContent="Section 10"/> notes that
            new registrations for IP network and autonomous system
            number searches have been made in the "RDAP Reverse Search" and "RDAP
            Reverse Search Mapping" IANA registries.

      </t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-rdap-conformance">RDAP Conformance</name>
      <t indent="0" pn="section-6-1">

            A server that supports the functionality specified in this
            document <bcp14>MUST</bcp14> include additional string literals in the
            rdapConformance array of its responses, in accordance with
            the following:

      </t>
      <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-6-2">
        <li pn="section-6-2.1">any response that includes an IP network basic
                search link, an IP network relation search link, or an IP
                network reverse search link includes the "rirSearch1"
                and "ips" literals;</li>
        <li pn="section-6-2.2">any response for an IP network basic search
                request, an IP network relation search request, or an
                IP network reverse search request includes the
                "rirSearch1", "ips", and "ipSearchResults"
                literals;</li>
        <li pn="section-6-2.3">any response that includes an ASN basic search
                link, an ASN relation search link, or an ASN reverse
                search link includes the "rirSearch1" and "autnums"
                literals;</li>
        <li pn="section-6-2.4">any response for an ASN basic search request, an
                ASN relation search request, or an ASN reverse search
                request includes the "rirSearch1", "autnums", and
                "autnumSearchResults" literals;</li>
        <li pn="section-6-2.5">any response that includes a domain relation search
                link includes the "rirSearch1" literal;</li>
        <li pn="section-6-2.6">any response for a domain relation search request
                includes the "rirSearch1" literal; and</li>
        <li pn="section-6-2.7">a response to a "/help" request includes the
                "rirSearch1", "ips", "ipSearchResults", "autnums", and
                "autnumSearchResults" literals.</li>
      </ul>
      <t indent="0" pn="section-6-3">
            Although responses will generally not include all of the
            rdapConformance string literals defined in this document,
            that is not meant to imply that a server can support only
            a portion of the functionality defined in this document.

      </t>
      <t indent="0" pn="section-6-4">

            The "ips", "autnums", "ipSearchResults", and
            "autnumSearchResults" extension identifiers are included
            here due to the requirements and recommendations set out
            in  <xref target="RFC7480" format="default" sectionFormat="of" derivedContent="RFC7480"/>, <xref target="RFC9082" format="default" sectionFormat="of" derivedContent="RFC9082"/>,
            and <xref target="RFC9083" format="default" sectionFormat="of" derivedContent="RFC9083"/>.  These requirements and
            recommendations are such that an RDAP extension identifier
            be used as a prefix in new path segments and JSON members
            introduced by the extension, and those strings are used as
            such as part of the basic searches defined in this
            document.  Furthermore, using these strings as path
            segments helps to increase consistency among the basic
            searches for the core RDAP object classes.

      </t>
      <t indent="0" pn="section-6-5">

            As with the other core object classes (entity, domain, and
            nameserver), other documents may define additional reverse
            searches with IP networks and ASNs as the searchable
            resource type by registering those in the IANA RDAP
            reverse search registries.  Because a given extension
            identifier must correspond to a single extension, though,
            any document making use of IP networks or ASNs as the
            searchable resource type must also implement the
            functionality described in this document.

      </t>
      <t indent="0" pn="section-6-6">

            The "1" in "rirSearch1" denotes that this is version 1 of
            the RIR search extension.  New versions of the RIR search
            extension will use different extension identifiers.  A
            version suffix is not used for the remaining identifiers
            defined by this document, partly because such a suffix
            would reduce consistency with the corresponding
            functionality for the other core object classes, and
            partly because it is very unlikely that the functionality
            associated with those identifiers will change.

      </t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-operational-considerations">Operational Considerations</name>
      <t indent="0" pn="section-7-1">
   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 that of the search URL at the time 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.

      </t>
      <t indent="0" pn="section-7-2">

            Where this document includes HTTP reason phrases, that is
            purely for the benefit of the reader and is not an
            indication that those phrases need to be used as-is in
            responses.

      </t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-8">
      <name slugifiedName="name-privacy-considerations">Privacy Considerations</name>
      <t indent="0" pn="section-8-1">

            The search functionality defined in this document may
            affect the privacy of entities in the registry (and
            elsewhere) in various ways: see <xref target="RFC6973" format="default" sectionFormat="of" derivedContent="RFC6973"/>
            for a general treatment of privacy in protocol
            specifications, and <xref target="RFC7481" format="default" sectionFormat="of" derivedContent="RFC7481"/> for specific
            discussion about privacy threats with respect to the
            registration data provided by RDAP.  Server operators
            should be aware of the tradeoffs that result from
            implementation of this functionality.

      </t>
      <t indent="0" pn="section-8-2">

            Many jurisdictions have laws or regulations that restrict
            the use of "Personal Data", per the definition in <xref target="RFC6973" format="default" sectionFormat="of" derivedContent="RFC6973"/>.  Given that, server operators should
            ascertain whether the regulatory environment in which they
            operate permits implementation of the functionality
            defined in this document.

      </t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-9">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-9-1">

            <xref target="RFC7481" format="default" sectionFormat="of" derivedContent="RFC7481"/> describes security requirements
            and considerations for RDAP generally.  Additionally,
            guidance as to the use of TLS has changed since that
            document was published: see <xref target="RFC8446" format="default" sectionFormat="of" derivedContent="RFC8446"/> and
            <xref target="BCP195" format="default" sectionFormat="of" derivedContent="BCP195"/> for further detail.

      </t>
      <t indent="0" pn="section-9-2">

            <xref target="RFC9082" format="default" sectionFormat="of" derivedContent="RFC9082"/> includes security considerations
            relating to object retrieval in RDAP.  Those
            considerations are relevant here as well.

      </t>
    </section>
    <section anchor="IANA" numbered="true" toc="include" removeInRFC="false" pn="section-10">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-10.1">
        <name slugifiedName="name-rdap-extensions-registry">RDAP Extensions Registry</name>
        <t indent="0" pn="section-10.1-1">

                IANA has registered the following values in
                the <eref brackets="angle" target="https://www.iana.org/assignments/rdap-extensions">"RDAP
                Extensions" registry</eref>.

        </t>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-10.1.1">
          <name slugifiedName="name-rirsearch1">rirSearch1</name>
          <dl newline="false" spacing="compact" indent="3" pn="section-10.1.1-1">
            <dt pn="section-10.1.1-1.1">Extension Identifier:</dt>
            <dd pn="section-10.1.1-1.2">rirSearch1</dd>
            <dt pn="section-10.1.1-1.3">Registry operator:</dt>
            <dd pn="section-10.1.1-1.4">Any</dd>
            <dt pn="section-10.1.1-1.5">Specification:</dt>
            <dd pn="section-10.1.1-1.6">RFC 9910</dd>
            <dt pn="section-10.1.1-1.7">Contact:</dt>
            <dd pn="section-10.1.1-1.8">IETF &lt;iesg@ietf.org&gt;</dd>
            <dt pn="section-10.1.1-1.9">Intended Usage:</dt>
            <dd pn="section-10.1.1-1.10">This extension identifier is used for INR-specific search operations.</dd>
          </dl>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-10.1.2">
          <name slugifiedName="name-ips">ips</name>
          <dl newline="false" spacing="compact" indent="3" pn="section-10.1.2-1">
            <dt pn="section-10.1.2-1.1">Extension Identifier:</dt>
            <dd pn="section-10.1.2-1.2">ips</dd>
            <dt pn="section-10.1.2-1.3">Registry operator:</dt>
            <dd pn="section-10.1.2-1.4">Any</dd>
            <dt pn="section-10.1.2-1.5">Specification:</dt>
            <dd pn="section-10.1.2-1.6">RFC 9910</dd>
            <dt pn="section-10.1.2-1.7">Contact:</dt>
            <dd pn="section-10.1.2-1.8">IETF &lt;iesg@ietf.org&gt;</dd>
            <dt pn="section-10.1.2-1.9">Intended Usage:</dt>
            <dd pn="section-10.1.2-1.10">This extension identifier is used for INR-specific search operations.</dd>
          </dl>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-10.1.3">
          <name slugifiedName="name-autnums">autnums</name>
          <dl newline="false" spacing="compact" indent="3" pn="section-10.1.3-1">
            <dt pn="section-10.1.3-1.1">Extension Identifier:</dt>
            <dd pn="section-10.1.3-1.2">autnums</dd>
            <dt pn="section-10.1.3-1.3">Registry operator:</dt>
            <dd pn="section-10.1.3-1.4">Any</dd>
            <dt pn="section-10.1.3-1.5">Specification:</dt>
            <dd pn="section-10.1.3-1.6">RFC 9910</dd>
            <dt pn="section-10.1.3-1.7">Contact:</dt>
            <dd pn="section-10.1.3-1.8">IETF &lt;iesg@ietf.org&gt;</dd>
            <dt pn="section-10.1.3-1.9">Intended Usage:</dt>
            <dd pn="section-10.1.3-1.10">This extension identifier is used for INR-specific search operations.</dd>
          </dl>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-10.1.4">
          <name slugifiedName="name-ipsearchresults">ipSearchResults</name>
          <dl newline="false" spacing="compact" indent="3" pn="section-10.1.4-1">
            <dt pn="section-10.1.4-1.1">Extension Identifier:</dt>
            <dd pn="section-10.1.4-1.2">ipSearchResults</dd>
            <dt pn="section-10.1.4-1.3">Registry operator:</dt>
            <dd pn="section-10.1.4-1.4">Any</dd>
            <dt pn="section-10.1.4-1.5">Specification:</dt>
            <dd pn="section-10.1.4-1.6">RFC 9910</dd>
            <dt pn="section-10.1.4-1.7">Contact:</dt>
            <dd pn="section-10.1.4-1.8">IETF &lt;iesg@ietf.org&gt;</dd>
            <dt pn="section-10.1.4-1.9">Intended Usage:</dt>
            <dd pn="section-10.1.4-1.10">This extension identifier is used for INR-specific search operations.</dd>
          </dl>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-10.1.5">
          <name slugifiedName="name-autnumsearchresults">autnumSearchResults</name>
          <dl newline="false" spacing="compact" indent="3" pn="section-10.1.5-1">
            <dt pn="section-10.1.5-1.1">Extension Identifier:</dt>
            <dd pn="section-10.1.5-1.2">autnumSearchResults</dd>
            <dt pn="section-10.1.5-1.3">Registry operator:</dt>
            <dd pn="section-10.1.5-1.4">Any</dd>
            <dt pn="section-10.1.5-1.5">Specification:</dt>
            <dd pn="section-10.1.5-1.6">RFC 9910</dd>
            <dt pn="section-10.1.5-1.7">Contact:</dt>
            <dd pn="section-10.1.5-1.8">IETF &lt;iesg@ietf.org&gt;</dd>
            <dt pn="section-10.1.5-1.9">Intended Usage:</dt>
            <dd pn="section-10.1.5-1.10">This extension identifier is used for INR-specific search operations.</dd>
          </dl>
        </section>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-10.2">
        <name slugifiedName="name-link-relations-registry">Link Relations Registry</name>
        <t indent="0" pn="section-10.2-1">

                IANA has registered the following values in
                the <eref brackets="angle" target="https://www.iana.org/assignments/link-relations">"Link
                Relations" registry</eref>.

        </t>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-10.2.1">
          <name slugifiedName="name-rdap-up-2">rdap-up</name>
          <dl newline="false" spacing="compact" indent="3" pn="section-10.2.1-1">
            <dt pn="section-10.2.1-1.1">Relation Name:</dt>
            <dd pn="section-10.2.1-1.2">rdap-up</dd>
            <dt pn="section-10.2.1-1.3">Description:</dt>
            <dd pn="section-10.2.1-1.4">Refers to an RDAP parent object in a hierarchy of objects.</dd>
            <dt pn="section-10.2.1-1.5">Reference:</dt>
            <dd pn="section-10.2.1-1.6">RFC 9910</dd>
          </dl>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-10.2.2">
          <name slugifiedName="name-rdap-down-2">rdap-down</name>
          <dl newline="false" spacing="compact" indent="3" pn="section-10.2.2-1">
            <dt pn="section-10.2.2-1.1">Relation Name:</dt>
            <dd pn="section-10.2.2-1.2">rdap-down</dd>
            <dt pn="section-10.2.2-1.3">Description:</dt>
            <dd pn="section-10.2.2-1.4">Refers to a set of RDAP child objects in a hierarchy of objects.</dd>
            <dt pn="section-10.2.2-1.5">Reference:</dt>
            <dd pn="section-10.2.2-1.6">RFC 9910</dd>
          </dl>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-10.2.3">
          <name slugifiedName="name-rdap-top-2">rdap-top</name>
          <dl newline="false" spacing="compact" indent="3" pn="section-10.2.3-1">
            <dt pn="section-10.2.3-1.1">Relation Name:</dt>
            <dd pn="section-10.2.3-1.2">rdap-top</dd>
            <dt pn="section-10.2.3-1.3">Description:</dt>
            <dd pn="section-10.2.3-1.4">Refers to the topmost RDAP parent object in a hierarchy of objects.</dd>
            <dt pn="section-10.2.3-1.5">Reference:</dt>
            <dd pn="section-10.2.3-1.6">RFC 9910</dd>
          </dl>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-10.2.4">
          <name slugifiedName="name-rdap-bottom-2">rdap-bottom</name>
          <dl newline="false" spacing="compact" indent="3" pn="section-10.2.4-1">
            <dt pn="section-10.2.4-1.1">Relation Name:</dt>
            <dd pn="section-10.2.4-1.2">rdap-bottom</dd>
            <dt pn="section-10.2.4-1.3">Description:</dt>
            <dd pn="section-10.2.4-1.4">Refers to the set of child RDAP objects that do not themselves have child objects, in a hierarchy of objects.</dd>
            <dt pn="section-10.2.4-1.5">Reference:</dt>
            <dd pn="section-10.2.4-1.6">RFC 9910</dd>
          </dl>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-10.2.5">
          <name slugifiedName="name-rdap-active">rdap-active</name>
          <dl newline="false" spacing="compact" indent="3" pn="section-10.2.5-1">
            <dt pn="section-10.2.5-1.1">Relation Name:</dt>
            <dd pn="section-10.2.5-1.2">rdap-active</dd>
            <dt pn="section-10.2.5-1.3">Description:</dt>
            <dd pn="section-10.2.5-1.4">The target is for an RDAP RIR search that filters for the status "active".</dd>
            <dt pn="section-10.2.5-1.5">Reference:</dt>
            <dd pn="section-10.2.5-1.6">RFC 9910</dd>
          </dl>
        </section>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-10.3">
        <name slugifiedName="name-rdap-reverse-search-registr">RDAP Reverse Search Registry</name>
        <t indent="0" pn="section-10.3-1">

                IANA has registered the following entries in
                the <eref brackets="angle" target="https://www.iana.org/assignments/rdap-reverse-search/">"RDAP
                Reverse Search" registry</eref>.

        </t>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-10.3.1">
          <name slugifiedName="name-fn">fn</name>
          <dl newline="false" spacing="compact" indent="3" pn="section-10.3.1-1">
            <dt pn="section-10.3.1-1.1">Property:</dt>
            <dd pn="section-10.3.1-1.2">fn</dd>
            <dt pn="section-10.3.1-1.3">Description:</dt>
            <dd pn="section-10.3.1-1.4">The server supports the IP/autnum search based on the full name (a.k.a. formatted name) of an associated entity.</dd>
            <dt pn="section-10.3.1-1.5">Searchable Resource Type:</dt>
            <dd pn="section-10.3.1-1.6">ips, autnums</dd>
            <dt pn="section-10.3.1-1.7">Related Resource Type:</dt>
            <dd pn="section-10.3.1-1.8">entity</dd>
            <dt pn="section-10.3.1-1.9">Registrant:</dt>
            <dd pn="section-10.3.1-1.10">IETF</dd>
            <dt pn="section-10.3.1-1.11">Contact Information:</dt>
            <dd pn="section-10.3.1-1.12">iesg@ietf.org</dd>
            <dt pn="section-10.3.1-1.13">Reference:</dt>
            <dd pn="section-10.3.1-1.14">RFC 9910</dd>
          </dl>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-10.3.2">
          <name slugifiedName="name-handle">handle</name>
          <dl newline="false" spacing="compact" indent="3" pn="section-10.3.2-1">
            <dt pn="section-10.3.2-1.1">Property:</dt>
            <dd pn="section-10.3.2-1.2">handle</dd>
            <dt pn="section-10.3.2-1.3">Description:</dt>
            <dd pn="section-10.3.2-1.4">The server supports the IP/autnum search based on the handle of an associated entity.</dd>
            <dt pn="section-10.3.2-1.5">Searchable Resource Type:</dt>
            <dd pn="section-10.3.2-1.6">ips, autnums</dd>
            <dt pn="section-10.3.2-1.7">Related Resource Type:</dt>
            <dd pn="section-10.3.2-1.8">entity</dd>
            <dt pn="section-10.3.2-1.9">Registrant:</dt>
            <dd pn="section-10.3.2-1.10">IETF</dd>
            <dt pn="section-10.3.2-1.11">Contact Information:</dt>
            <dd pn="section-10.3.2-1.12">iesg@ietf.org</dd>
            <dt pn="section-10.3.2-1.13">Reference:</dt>
            <dd pn="section-10.3.2-1.14">RFC 9910</dd>
          </dl>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-10.3.3">
          <name slugifiedName="name-email">email</name>
          <dl newline="false" spacing="compact" indent="3" pn="section-10.3.3-1">
            <dt pn="section-10.3.3-1.1">Property:</dt>
            <dd pn="section-10.3.3-1.2">email</dd>
            <dt pn="section-10.3.3-1.3">Description:</dt>
            <dd pn="section-10.3.3-1.4">The server supports the IP/autnum search based on the email address of an associated entity.</dd>
            <dt pn="section-10.3.3-1.5">Searchable Resource Type:</dt>
            <dd pn="section-10.3.3-1.6">ips, autnums</dd>
            <dt pn="section-10.3.3-1.7">Related Resource Type:</dt>
            <dd pn="section-10.3.3-1.8">entity</dd>
            <dt pn="section-10.3.3-1.9">Registrant:</dt>
            <dd pn="section-10.3.3-1.10">IETF</dd>
            <dt pn="section-10.3.3-1.11">Contact Information:</dt>
            <dd pn="section-10.3.3-1.12">iesg@ietf.org</dd>
            <dt pn="section-10.3.3-1.13">Reference:</dt>
            <dd pn="section-10.3.3-1.14">RFC 9910</dd>
          </dl>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-10.3.4">
          <name slugifiedName="name-role">role</name>
          <dl newline="false" spacing="compact" indent="3" pn="section-10.3.4-1">
            <dt pn="section-10.3.4-1.1">Property:</dt>
            <dd pn="section-10.3.4-1.2">role</dd>
            <dt pn="section-10.3.4-1.3">Description:</dt>
            <dd pn="section-10.3.4-1.4">The server supports the IP/autnum search based on the role of an associated entity.</dd>
            <dt pn="section-10.3.4-1.5">Searchable Resource Type:</dt>
            <dd pn="section-10.3.4-1.6">ips, autnums</dd>
            <dt pn="section-10.3.4-1.7">Related Resource Type:</dt>
            <dd pn="section-10.3.4-1.8">entity</dd>
            <dt pn="section-10.3.4-1.9">Registrant:</dt>
            <dd pn="section-10.3.4-1.10">IETF</dd>
            <dt pn="section-10.3.4-1.11">Contact Information:</dt>
            <dd pn="section-10.3.4-1.12">iesg@ietf.org</dd>
            <dt pn="section-10.3.4-1.13">Reference:</dt>
            <dd pn="section-10.3.4-1.14">RFC 9910</dd>
          </dl>
        </section>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-10.4">
        <name slugifiedName="name-rdap-reverse-search-mapping">RDAP Reverse Search Mapping Registry</name>
        <t indent="0" pn="section-10.4-1">

                IANA has registered the following entries
                in the <eref brackets="angle" target="https://www.iana.org/assignments/rdap-reverse-search-mapping">"RDAP
                Reverse Search Mapping" registry</eref>.

        </t>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-10.4.1">
          <name slugifiedName="name-fn-2">fn</name>
          <dl newline="false" spacing="compact" indent="3" pn="section-10.4.1-1">
            <dt pn="section-10.4.1-1.1">Property:</dt>
            <dd pn="section-10.4.1-1.2">fn</dd>
            <dt pn="section-10.4.1-1.3">Property Path:</dt>
            <dd pn="section-10.4.1-1.4">$.entities[*].vcardArray[1][?(@[0]=='fn')][3]</dd>
            <dt pn="section-10.4.1-1.5">Searchable Resource Type:</dt>
            <dd pn="section-10.4.1-1.6">ips, autnums</dd>
            <dt pn="section-10.4.1-1.7">Related Resource Type:</dt>
            <dd pn="section-10.4.1-1.8">entity</dd>
            <dt pn="section-10.4.1-1.9">Registrant:</dt>
            <dd pn="section-10.4.1-1.10">IETF</dd>
            <dt pn="section-10.4.1-1.11">Contact Information:</dt>
            <dd pn="section-10.4.1-1.12">iesg@ietf.org</dd>
            <dt pn="section-10.4.1-1.13">Reference:</dt>
            <dd pn="section-10.4.1-1.14">RFC 9910</dd>
          </dl>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-10.4.2">
          <name slugifiedName="name-handle-2">handle</name>
          <dl newline="false" spacing="compact" indent="3" pn="section-10.4.2-1">
            <dt pn="section-10.4.2-1.1">Property:</dt>
            <dd pn="section-10.4.2-1.2">handle</dd>
            <dt pn="section-10.4.2-1.3">Property Path:</dt>
            <dd pn="section-10.4.2-1.4">$.entities[*].handle</dd>
            <dt pn="section-10.4.2-1.5">Searchable Resource Type:</dt>
            <dd pn="section-10.4.2-1.6">ips, autnums</dd>
            <dt pn="section-10.4.2-1.7">Related Resource Type:</dt>
            <dd pn="section-10.4.2-1.8">entity</dd>
            <dt pn="section-10.4.2-1.9">Registrant:</dt>
            <dd pn="section-10.4.2-1.10">IETF</dd>
            <dt pn="section-10.4.2-1.11">Contact Information:</dt>
            <dd pn="section-10.4.2-1.12">iesg@ietf.org</dd>
            <dt pn="section-10.4.2-1.13">Reference:</dt>
            <dd pn="section-10.4.2-1.14">RFC 9910</dd>
          </dl>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-10.4.3">
          <name slugifiedName="name-email-2">email</name>
          <dl newline="false" spacing="compact" indent="3" pn="section-10.4.3-1">
            <dt pn="section-10.4.3-1.1">Property:</dt>
            <dd pn="section-10.4.3-1.2">email</dd>
            <dt pn="section-10.4.3-1.3">Property Path:</dt>
            <dd pn="section-10.4.3-1.4">$.entities[*].vcardArray[1][?(@[0]=='email')][3]</dd>
            <dt pn="section-10.4.3-1.5">Searchable Resource Type:</dt>
            <dd pn="section-10.4.3-1.6">ips, autnums</dd>
            <dt pn="section-10.4.3-1.7">Related Resource Type:</dt>
            <dd pn="section-10.4.3-1.8">entity</dd>
            <dt pn="section-10.4.3-1.9">Registrant:</dt>
            <dd pn="section-10.4.3-1.10">IETF</dd>
            <dt pn="section-10.4.3-1.11">Contact Information:</dt>
            <dd pn="section-10.4.3-1.12">iesg@ietf.org</dd>
            <dt pn="section-10.4.3-1.13">Reference:</dt>
            <dd pn="section-10.4.3-1.14">RFC 9910</dd>
          </dl>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-10.4.4">
          <name slugifiedName="name-role-2">role</name>
          <dl newline="false" spacing="compact" indent="3" pn="section-10.4.4-1">
            <dt pn="section-10.4.4-1.1">Property:</dt>
            <dd pn="section-10.4.4-1.2">role</dd>
            <dt pn="section-10.4.4-1.3">Property Path:</dt>
            <dd pn="section-10.4.4-1.4">$.entities[*].roles</dd>
            <dt pn="section-10.4.4-1.5">Searchable Resource Type:</dt>
            <dd pn="section-10.4.4-1.6">ips, autnums</dd>
            <dt pn="section-10.4.4-1.7">Related Resource Type:</dt>
            <dd pn="section-10.4.4-1.8">entity</dd>
            <dt pn="section-10.4.4-1.9">Registrant:</dt>
            <dd pn="section-10.4.4-1.10">IETF</dd>
            <dt pn="section-10.4.4-1.11">Contact Information:</dt>
            <dd pn="section-10.4.4-1.12">iesg@ietf.org</dd>
            <dt pn="section-10.4.4-1.13">Reference:</dt>
            <dd pn="section-10.4.4-1.14">RFC 9910</dd>
          </dl>
        </section>
      </section>
    </section>
  </middle>
  <back>
    <references pn="section-11">
      <name slugifiedName="name-references">References</name>
      <references pn="section-11.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <referencegroup anchor="BCP195" target="https://www.rfc-editor.org/info/bcp195" derivedAnchor="BCP195">
          <reference anchor="RFC8996" target="https://www.rfc-editor.org/info/rfc8996" quoteTitle="true">
            <front>
              <title>Deprecating TLS 1.0 and TLS 1.1</title>
              <author fullname="K. Moriarty" initials="K." surname="Moriarty"/>
              <author fullname="S. Farrell" initials="S." surname="Farrell"/>
              <date month="March" year="2021"/>
              <abstract>
                <t indent="0">This document formally deprecates Transport Layer Security (TLS) versions 1.0 (RFC 2246) and 1.1 (RFC 4346). Accordingly, those documents have been moved to Historic status. These versions lack support for current and recommended cryptographic algorithms and mechanisms, and various government and industry profiles of applications using TLS now mandate avoiding these old TLS versions. TLS version 1.2 became the recommended version for IETF protocols in 2008 (subsequently being obsoleted by TLS version 1.3 in 2018), providing sufficient time to transition away from older versions. Removing support for older versions from implementations reduces the attack surface, reduces opportunity for misconfiguration, and streamlines library and product maintenance.</t>
                <t indent="0">This document also deprecates Datagram TLS (DTLS) version 1.0 (RFC 4347) but not DTLS version 1.2, and there is no DTLS version 1.1.</t>
                <t indent="0">This document updates many RFCs that normatively refer to TLS version 1.0 or TLS version 1.1, as described herein. This document also updates the best practices for TLS usage in RFC 7525; hence, it is part of BCP 195.</t>
              </abstract>
            </front>
            <seriesInfo name="BCP" value="195"/>
            <seriesInfo name="RFC" value="8996"/>
            <seriesInfo name="DOI" value="10.17487/RFC8996"/>
          </reference>
          <reference anchor="RFC9325" target="https://www.rfc-editor.org/info/rfc9325" quoteTitle="true">
            <front>
              <title>Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)</title>
              <author fullname="Y. Sheffer" initials="Y." surname="Sheffer"/>
              <author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre"/>
              <author fullname="T. Fossati" initials="T." surname="Fossati"/>
              <date month="November" year="2022"/>
              <abstract>
                <t indent="0">Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are used to protect data exchanged over a wide range of application protocols and can also form the basis for secure transport protocols. Over the years, the industry has witnessed several serious attacks on TLS and DTLS, including attacks on the most commonly used cipher suites and their modes of operation. This document provides the latest recommendations for ensuring the security of deployed services that use TLS and DTLS. These recommendations are applicable to the majority of use cases.</t>
                <t indent="0">RFC 7525, an earlier version of the TLS recommendations, was published when the industry was transitioning to TLS 1.2. Years later, this transition is largely complete, and TLS 1.3 is widely available. This document updates the guidance given the new environment and obsoletes RFC 7525. In addition, this document updates RFCs 5288 and 6066 in view of recent attacks.</t>
              </abstract>
            </front>
            <seriesInfo name="BCP" value="195"/>
            <seriesInfo name="RFC" value="9325"/>
            <seriesInfo name="DOI" value="10.17487/RFC9325"/>
          </reference>
        </referencegroup>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC7481" target="https://www.rfc-editor.org/info/rfc7481" quoteTitle="true" derivedAnchor="RFC7481">
          <front>
            <title>Security Services for the Registration Data Access Protocol (RDAP)</title>
            <author fullname="S. Hollenbeck" initials="S." surname="Hollenbeck"/>
            <author fullname="N. Kong" initials="N." surname="Kong"/>
            <date month="March" year="2015"/>
            <abstract>
              <t indent="0">The Registration Data Access Protocol (RDAP) provides "RESTful" web services to retrieve registration metadata from Domain Name and Regional Internet Registries. This document describes information security services, including access control, authentication, authorization, availability, data confidentiality, and data integrity for RDAP.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="95"/>
          <seriesInfo name="RFC" value="7481"/>
          <seriesInfo name="DOI" value="10.17487/RFC7481"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8446" quoteTitle="true" derivedAnchor="RFC8446">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
            <date month="August" year="2018"/>
            <abstract>
              <t indent="0">This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
              <t indent="0">This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8446"/>
          <seriesInfo name="DOI" value="10.17487/RFC8446"/>
        </reference>
        <reference anchor="RFC9082" target="https://www.rfc-editor.org/info/rfc9082" quoteTitle="true" derivedAnchor="RFC9082">
          <front>
            <title>Registration Data Access Protocol (RDAP) Query Format</title>
            <author fullname="S. Hollenbeck" initials="S." surname="Hollenbeck"/>
            <author fullname="A. Newton" initials="A." surname="Newton"/>
            <date month="June" year="2021"/>
            <abstract>
              <t indent="0">This document describes uniform patterns to construct HTTP URLs that may be used to retrieve registration information from registries (including both Regional Internet Registries (RIRs) and Domain Name Registries (DNRs)) using "RESTful" web access patterns. These uniform patterns define the query syntax for the Registration Data Access Protocol (RDAP). This document obsoletes RFC 7482.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="95"/>
          <seriesInfo name="RFC" value="9082"/>
          <seriesInfo name="DOI" value="10.17487/RFC9082"/>
        </reference>
        <reference anchor="RFC9083" target="https://www.rfc-editor.org/info/rfc9083" quoteTitle="true" derivedAnchor="RFC9083">
          <front>
            <title>JSON Responses for the Registration Data Access Protocol (RDAP)</title>
            <author fullname="S. Hollenbeck" initials="S." surname="Hollenbeck"/>
            <author fullname="A. Newton" initials="A." surname="Newton"/>
            <date month="June" year="2021"/>
            <abstract>
              <t indent="0">This document describes JSON data structures representing registration information maintained by Regional Internet Registries (RIRs) and Domain Name Registries (DNRs). These data structures are used to form Registration Data Access Protocol (RDAP) query responses. This document obsoletes RFC 7483.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="95"/>
          <seriesInfo name="RFC" value="9083"/>
          <seriesInfo name="DOI" value="10.17487/RFC9083"/>
        </reference>
        <reference anchor="RFC9110" target="https://www.rfc-editor.org/info/rfc9110" quoteTitle="true" derivedAnchor="RFC9110">
          <front>
            <title>HTTP Semantics</title>
            <author fullname="R. Fielding" initials="R." role="editor" surname="Fielding"/>
            <author fullname="M. Nottingham" initials="M." role="editor" surname="Nottingham"/>
            <author fullname="J. Reschke" initials="J." role="editor" surname="Reschke"/>
            <date month="June" year="2022"/>
            <abstract>
              <t indent="0">The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes.</t>
              <t indent="0">This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="97"/>
          <seriesInfo name="RFC" value="9110"/>
          <seriesInfo name="DOI" value="10.17487/RFC9110"/>
        </reference>
        <reference anchor="RFC9536" target="https://www.rfc-editor.org/info/rfc9536" quoteTitle="true" derivedAnchor="RFC9536">
          <front>
            <title>Registration Data Access Protocol (RDAP) Reverse Search</title>
            <author fullname="M. Loffredo" initials="M." surname="Loffredo"/>
            <author fullname="M. Martinelli" initials="M." surname="Martinelli"/>
            <date month="April" year="2024"/>
            <abstract>
              <t indent="0">The Registration Data Access Protocol (RDAP) does not include query capabilities for finding the list of domains related to a set of entities matching a given search pattern. Considering that an RDAP entity can be associated with any defined object class and other relationships between RDAP object classes exist, a reverse search can be applied to other use cases besides the classic domain-entity scenario. This document describes an RDAP extension that allows servers to provide a reverse search feature based on the relationship defined in RDAP between an object class for search and any related object class. The reverse search based on the domain-entity relationship is treated as a particular case.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9536"/>
          <seriesInfo name="DOI" value="10.17487/RFC9536"/>
        </reference>
      </references>
      <references pn="section-11.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="RFC3912" target="https://www.rfc-editor.org/info/rfc3912" quoteTitle="true" derivedAnchor="RFC3912">
          <front>
            <title>WHOIS Protocol Specification</title>
            <author fullname="L. Daigle" initials="L." surname="Daigle"/>
            <date month="September" year="2004"/>
            <abstract>
              <t indent="0">This document updates the specification of the WHOIS protocol, thereby obsoleting RFC 954. The update is intended to remove the material from RFC 954 that does not have to do with the on-the-wire protocol, and is no longer applicable in today's Internet. This document does not attempt to change or update the protocol per se, or document other uses of the protocol that have come into existence since the publication of RFC 954. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3912"/>
          <seriesInfo name="DOI" value="10.17487/RFC3912"/>
        </reference>
        <reference anchor="RFC6973" target="https://www.rfc-editor.org/info/rfc6973" quoteTitle="true" derivedAnchor="RFC6973">
          <front>
            <title>Privacy Considerations for Internet Protocols</title>
            <author fullname="A. Cooper" initials="A." surname="Cooper"/>
            <author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/>
            <author fullname="B. Aboba" initials="B." surname="Aboba"/>
            <author fullname="J. Peterson" initials="J." surname="Peterson"/>
            <author fullname="J. Morris" initials="J." surname="Morris"/>
            <author fullname="M. Hansen" initials="M." surname="Hansen"/>
            <author fullname="R. Smith" initials="R." surname="Smith"/>
            <date month="July" year="2013"/>
            <abstract>
              <t indent="0">This document offers guidance for developing privacy considerations for inclusion in protocol specifications. It aims to make designers, implementers, and users of Internet protocols aware of privacy-related design choices. It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6973"/>
          <seriesInfo name="DOI" value="10.17487/RFC6973"/>
        </reference>
        <reference anchor="RFC7480" target="https://www.rfc-editor.org/info/rfc7480" quoteTitle="true" derivedAnchor="RFC7480">
          <front>
            <title>HTTP Usage in the Registration Data Access Protocol (RDAP)</title>
            <author fullname="A. Newton" initials="A." surname="Newton"/>
            <author fullname="B. Ellacott" initials="B." surname="Ellacott"/>
            <author fullname="N. Kong" initials="N." surname="Kong"/>
            <date month="March" year="2015"/>
            <abstract>
              <t indent="0">This document is one of a collection that together describes the Registration Data Access Protocol (RDAP). It describes how RDAP is transported using the Hypertext Transfer Protocol (HTTP). RDAP is a successor protocol to the very old WHOIS protocol. The purpose of this document is to clarify the use of standard HTTP mechanisms for this application.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="95"/>
          <seriesInfo name="RFC" value="7480"/>
          <seriesInfo name="DOI" value="10.17487/RFC7480"/>
        </reference>
      </references>
    </references>
    <section anchor="Acknowledgements" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.a-1">The authors wish to thank <contact fullname="Mario Loffredo"/>,
      <contact fullname="Andy Newton"/>, <contact fullname="Antoin       Verschuren"/>, <contact fullname="James Gould"/>, <contact fullname="Scott Hollenbeck"/>, <contact fullname="Orie Steele"/>,
      <contact fullname="Russ Housley"/>, <contact fullname="John Levine"/>,
      <contact fullname="Stewart Bryant"/>, <contact fullname="Mark       Nottingham"/>, <contact fullname="Mohamed Boucadair"/>, <contact fullname="Deb Cooley"/>, <contact fullname="Éric Vyncke"/>, and <contact fullname="Roman Danyliw"/> for document review and associated comments.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author initials="T." surname="Harrison" fullname="Tom Harrison">
        <organization abbrev="APNIC" showOnFrontPage="true">Asia Pacific Network Information Centre</organization>
        <address>
          <postal>
            <street>6 Cordelia St</street>
            <city>South Brisbane</city>
            <code>4101</code>
            <country>Australia</country>
            <region>QLD</region>
          </postal>
          <email>tomh@apnic.net</email>
        </address>
      </author>
      <author initials="J." fullname="Jasdip Singh" surname="Singh">
        <organization abbrev="ARIN" showOnFrontPage="true">American Registry for Internet Numbers</organization>
        <address>
          <postal>
            <street>PO Box 232290</street>
            <city>Centreville</city>
            <region>VA</region>
            <code>20120</code>
            <country>United States of America</country>
          </postal>
          <email>jasdips@arin.net</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
