Hi Susan,
thanks for the additional feedback.
Again my comments below.
Il 22/08/2023 15:19, Susan Hares ha scritto:
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./
[ML] Perfect.
I noticed that the OPS-DIR review indicated operational difficulties
that I did not consider:
https://datatracker.ietf.org/doc/review-ietf-regext-rdap-reverse-search-24-opsdir-lc-chown-2023-08-21/
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?
[ML] The privacy concern is about the use of PII to discover facts about
individuals as contacts associated to RDAP objects.
Hence it's not the privacy of the requestor that must be preserved but
rather that of individuals whose information is stored in the registry
database.
For example, using an individual's email address as the basis for a
reverse search to obtain all the domains of that holder.
In general, unless the individual has given his consent for publishing,
the sensitive information gets redacted in the RDAP response when the
query is submitted by an anonymous user.
As a consequence, it's obvious that anonymous users can't submit a
reverse search based on it.
In addition, RDAP searches are usually not allowed to anonymous users
because of their impact on processing resources.
But an RDAP server can be suported by authorization mechanims to permit
some authorized and legitimate users to submit searches and,
specifically, reverse searches.
2) Should you include comments on rate limiting of reverse RDAP?
[ML] Rate limiting is a topic connected to the handling of RDAP searches
in general, hence, not specifically to that of reverse searches.
Besides, every RDAP provider can implement different strategies to limit
the query rate.
There are a number of measures coming in my mind but all of them are
based on my personal experience.
My opinion is that, if there's ever a RegExt draft about best practices
in providing RDAP searches, that document could be the right place to
address rate limiting.
Hope my responses could be satisfying.
Best,
Mario
Thank you, Sue Hares
*From:*Mario Loffredo <mario.loffr...@iit.cnr.it>
*Sent:* Tuesday, August 22, 2023 5:27 AM
*To:* Susan Hares <sha...@ndzh.com>; gen-...@ietf.org
*Cc:* draft-ietf-regext-rdap-reverse-search....@ietf.org;
last-c...@ietf.org; regext@ietf.org
*Subject:* Re: Genart last call review of
draft-ietf-regext-rdap-reverse-search-24
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
--
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
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
