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

[Mario Loffredo <[e-mail]>]

Hi Susan,

thanks a lot for your review.

Please find my comments inline.

Il 21/08/2023 22:14, Susan Hares via Datatracker ha scritto:
> 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.
[ML]  OK. Looks better to move up the link to RFC 3912 to the sentence 
including "... standardized Whois capability ... ".
>
> 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./
[ML] OK.
>
> #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./
[ML] OK.
>
> #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./
[ML] Do you mean "... so the basis of this objection 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./
>
[ML] OK.


Best,

Mario

>
-- 
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: [phone]
Web: http://www.iit.cnr.it/mario.loffredo