Re: [Gen-art] Genart last call review of draft-ietf-regext-rdap-reverse-search-24

[Lars Eggert <[e-mail]>]

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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art