Re: [regext] I-D Action: draft-ietf-regext-rdap-rir-search-09.txt

[Tom Harrison <[e-mail]>]

On Sun, Mar 24, 2024 at 06:07:41PM -0700, [e-mail] wrote:
> Internet-Draft draft-ietf-regext-rdap-rir-search-09.txt is now available. It
> is a work item of the Registration Protocols Extensions (REGEXT) WG of the
> IETF.
> 
>    Title:   RDAP RIR Search
>    Authors: Tom Harrison
>             Jasdip Singh
>    Name:    draft-ietf-regext-rdap-rir-search-09.txt
>    Pages:   27
>    Dates:   2024-03-24
> 
> Abstract:
> 
>    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 IP and ASN-related search options provided by RIRs via
>    their Whois services for which there is no corresponding RDAP
>    functionality.  This document extends RDAP to support those search
>    options.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-rir-search/
> 
> There is also an HTMLized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-rir-search-09
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-rdap-rir-search-09
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts

The diff from the WGLC version to this updated version is available at
https://author-tools.ietf.org/iddiff?url1=draft-ietf-regext-rdap-rir-search-05&url2=draft-ietf-regext-rdap-rir-search-09&difftype=--html.
We would appreciate review by the working group of the current version
prior to requesting another round of working group last call.  The
non-editorial changes between the WGLC version and this updated
version are:

 - The "up" and "top" search behaviour is now the same as that for
   standard object lookup.  If the relevant object exists, it is
   returned as-is, and if it doesn't, then the client gets a 404
   (instead of an empty ipSearchResults/autnumSearchResults list).
   This means that server operators can substitute direct object links
   into "up"/"top" link relation objects, and it also preserves
   consistency with how "up" is used in RFC 9083.
 - Server operators can opt not to support status filtering requests
   outside of the "active" status filter for "up" and "top" searches
   (the server can return 501 for other status filtering requests).
 - The requests for which the different conformance codes need to be
   returned are now documented in section 6.
 - The RIPE NCC implementation of the basic IP/ASN searches is now
   documented in section 11.

-Tom