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