Last Call Review of draft-ietf-regext-rdap-reverse-search-24
review-ietf-regext-rdap-reverse-search-24-opsdir-lc-chown-2023-08-21-00

Hi,

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written with the intent of improving the operational aspects of the IETF
drafts. Comments that are not addressed in last call may be included in AD
reviews during the IESG review.  Document editors and WG chairs should treat
these comments just like any other last call comments.

The document describes
Registration Data Access Protocol (RDAP) reverse search functionality that
allows queries on entity information to return corresponding domain lists.

The document is well-written, clear, and includes helpful examples.

I consider that the document is close to being ready for publication, subject
to the below caveats.

General comments

I am not an expert in RDAP, but the technical solution proposed in this
document for a reverse search capability seems reasonable.


My two concerns are not technical, rather related to the ‘objections’
 mentioned at the start of the draft’s Introduction section on privacy and
 server processing.

I note that the draft has been marked as ‘Ready’ after a security area review,
so perhaps these concerns are not warranted, but I feel I should raise them and
at least let the Ops AD look at them.

One concern is privacy.

Paragraph two of the Introduction appears to be waving away privacy concerns
based on new registration directory services that are being considered, and
thus may become reality at some point (this is not clear). I’d hope that the
controls on such new services would be more clearly articulated, rather than
the services being presented as being at an early ‘consideration’ stage.  Are
privacy protections guaranteed to be there? I understand the potential benefit
of this new service compared to Whois, but I would like to see the text say
more.

The Privacy Considerations section also quite rightly talks about HTTPS being
required for reverse search. But I’m curious as to why the reverse search
functionality SHOULD only be accessible to authorised users for specific use
cases, rather than MUST?  And is that ‘should’ in paragraph two of the Privacy
Considerations a SHOULD?

I wonder also here whether as per other RDAP specs I’ve looked at as part of
this review there is the privacy of the querier to be considered, but I suppose
if specific authorisation is required then that is an unrealistic expectation?

The other concern is the way the server processing aspect is presented.

It seems the text in paragraph 3 of the Introduction is saying it’s not an
issue as RDAP search queries already exist. But looking at related RFCs I see
examples where specific controls (rate limiting, response codes for too many
queries, etc) are described. So I think the concern is clear, rather the text
should state that controls can be implemented, or indeed SHOULD be, later in
the document.

Finally, related, I welcome the details of implementations in the draft, but I
note they are ‘alpha’ state. I’m curious as to their potential progression, and
what testing at any scale may have bene done.

Best wishes,
Tim