I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-regext-rdap-reverse-search-?? Reviewer: Susan Hares Review Date: 2023-08-21 IETF LC End Date: 2023-08-11 IESG Telechat date: 2023-08-24 Summary: The text is readable even for a novice in RDAP. I appreciated how sections 13 and 14 discussed the tension between the need for operational data and the need for the privacy of personal information. It is important that registry operators who use this technology to provide reverse RDAP provide clear communication to the following groups of people: a) the people registering this data, b) security personnel within the registry operator providing the data, c) any people allowed to access the data, and d) other registries that may import data from this registry. I find this text to be sufficient. I will please to see the security-DIR review found it ready to publish. Nits/editorial comments: Nits: Nit-#1: Section 1: It would be helpful to the naive reader to provide an IETF link for whois in section 1. Editorial comments: English textual comments to improve readability. #1 Section 1, paragraph 1 Old:/Since RDAP consequently permits a reverse search implementation complying with privacy protection principles, this objection is not well-founded./ New:/Since RDAP consequently permits a reverse search implementation complying with privacy protection principles, this first objection is not well-founded./ #2 Section 1: paragraph 2 Old:/The other objection to the implementation of a reverse search capability has been connected with its impact on server processing./ New:/The second objection to the implementation of a reverse search capability has been connected with its impact on server processing./ #3, Section 1: paragraph 2 Old: / However, the core RDAP specifications already define search queries, with similar processing requirements, so the distinction on which this objection is based is not clear./ New: /However, the core RDAP specifications already define search queries with similar processing requirements so the basis of this objection is based is not clear./ Section 3, paragraph 2 Old: /All of the reverse searches defined by this document (see Section 8) have property names that are the same as the name of the RDAP object member that is the subject of the search: for example, the reverse search with the property name "fn" relies on the value of the "fn" member inside the jCard of an entity object./ New: / All of the reverse searches defined by this document (see Section 8) have property names that are the same as the name of the RDAP object member that is the subject of the search. For example, the reverse search with the property name "fn" relies on the value of the "fn" member inside the jCard of an entity object./