|
Mario:
Thank you for your response.
You are correct. My editorial #3 should be: New: /However, the core RDAP specifications already define search queries with similar processing requirements so the basis of this objection is not clear./ I noticed that the OPS-DIR review indicated operational difficulties that I did not consider:
For my own curiosity and learning, I found Tim Chown’s two questions were import: 1) why did you state “should” instead of MUST for HTTPS?
Excerpt from Tim Chown’s review:
The Privacy Considerations section also quite rightly talks about HTTPS being required for reverse search. But I’m curious as to why the reverse search functionality SHOULD only be accessible to authorised users for specific use cases, rather than MUST? And is that ‘should’ in paragraph two of the Privacy Considerations a SHOULD? I wonder also here whether as per other RDAP specs I’ve looked at as part of this review there is the privacy of the querier to be considered, but I suppose if specific authorization is required then that is an unrealistic expectation?
2) Should you include comments on rate limiting of reverse RDAP?
Thank you, Sue Hares
From: Mario Loffredo <mario.loffredo@xxxxxxxxxx>
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 ... ". >> Sue#2: This resolves my comment. > 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" ? [Sue]: Yes. My new should read: New: /However, the core RDAP specifications already define search queries with similar processing requirements 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: +39.0503153497 Web:
http://www.iit.cnr.it/mario.loffredo |
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
