Hi, On 22 Aug 2023, at 10:50, Mario Loffredo <mario.loffr...@iit.cnr.it> wrote:
Hi Tim, thanks a lot for your review. Please find my comments inline I’ll answer the privacy point in response to Andy’s email. Il 21/08/2023 20:27, Tim Chown via Datatracker ha scritto: Reviewer: Tim Chown Review result: Not Ready 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. [ML] The concern is about RDAP searches in general, not specifically about the reverse searches. In addition, the reverse search is not new in RDAP. RFC 9082 defines queries to search for domains starting for a detail of the associated name servers. I would assume one aspect of the concern is the larger volume of queries that is likely to follow, and in particular efforts to recover potential PII (whether it is actually available or not). So both a general higher volume of queries, but also a level of additional ‘harvesting’ activity. I think that’s where some text could be added, and covered by similar protections as described for existing queries. This document just aims to describe a formal query model addressing every kind of reverse search based on the relationships between the RDAP objects. RFC 8977 and RFC 8982 already provide guidance to implementers on how to make searches more sustainable for both clients and servers but, obviously, RDAP providers can implement additional measures with the same purpose. That said, Section 10 already includes text recommending to use techniques speeding up the data retrieval and mitigating the risks of performance degradation. Hence, IMO, it already addresses your remark. The text further into the document helps, but the text I the Intro ignores this; it should forward point to that. 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. [ML] At .it, we have implemented only the reverse search based on domain-entity relationship and it's unaccessible to public users. Presently it's available to registrar users under the conditions explained in my first comment and we plan to make it available to authorities soon. ARIN and APNIC have described in draft-ietf-regext-rdap-rir-search<https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-rir-search/> a potential usage of the reverse search in their own RDAP servers. OK, thanks. This seems to boil down to a solution that is technically fine, from my level of knowledge of RDAP, but where the use cases need to be considered by the IESG in their evaluation. Tim Best, Mario Best wishes, Tim -- Dott. Mario Loffredo Senior Technologist Technological Unit “Digital Innovation” Institute of Informatics and Telematics (IIT) National Research Council (CNR) via G. Moruzzi 1, I-56124 PISA, Italy Phone: +39.0503153497 Web: http://www.iit.cnr.it/mario.loffredo
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
