Hi John,
Thanks for your review.
On Wed, Feb 05, 2025 at 07:10:29PM -0800, John Levine via Datatracker wrote:
> Reviewer: John Levine
> Review result: Ready with Nits
>
> For this ART area review, I looked at the document as someone who is
> reasonably
> familiar with RDAP, having written some RDAP clients that look up information
> about both domains and IPs. It is clear enough and I was able to try a few
> experimental searches that returned what I expected.
>
> Result: Ready with Nits
>
> Section 2.1 says that search patterns are the ones in section 4.1 of RFC9082.
> That section describes patterns with a trailing *, with a special case for a
> domain suffix like "exam*.com". That special case doesn't make much sense for
> searching RIR data. It would be helpful either to exclude that case, or
> clarify that yes, you can search for patterns with a trailing domain suffix.
Added text:
Section 4.1 of [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.
> Section 3.1 says the status keyword can have any of the values in section 4.6
> of RFC9083, again, many of which don't make sense for RIR searches. (pending
> create? renew prohibited?) Section 3.3 describes status searching but only
> uses
> "active" or "inactive". It would be helpful to clarify either that you can use
> all of the 9083 values even though most of them will never match, or list the
> values that are useful.
Added text:
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.
> In section 3.4, I can't tell why you would use an up-active or top-active
> search rather than up/foo?status=active or top/bar?status=active. It looks
> like they're equivalent.
They are, but the intent was that 'up-active' and 'top-active' be
usable as link relations only in link objects, rather than in the
general search URL. Due to other feedback, 'up-active' and
'top-active' have been removed, and a single 'rdap-active' link
relation (to be used in conjunction with 'rdap-up' or 'rdap-top') has
been added, too. Added text:
"rdap-active" is used only as a link relation in a link object.
It cannot be used as a value for <relation> in the relation search
URL defined in Section 3.2. Section 3.3 details status filtering
for relation search URLs.
> In section 10.2 the link to the Link Relations registry links to the wrong
> registry. That's very meta.
This link has been updated now.
-Tom
_______________________________________________
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org
