Susan, thank you for your review. I have entered a Discuss ballot for this document. Lars > On Aug 21, 2023, at 23:14, Susan Hares via Datatracker <noreply@xxxxxxxx> wrote: > > Reviewer: Susan Hares > Review result: Ready with Nits > > 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 > > <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. > > 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./ > > > > _______________________________________________ > Gen-art mailing list > Gen-art@xxxxxxxx > https://www.ietf.org/mailman/listinfo/gen-art
Attachment:
signature.asc
Description: Message signed with OpenPGP
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
