Re: [regext] WG LAST CALL: draft-ietf-regext-rdap-reverse-search

[Mario Loffredo <[e-mail]>]

Hi James,

thanks a lot for your feeedback.

Please find my responses inline.

Il 26/04/2022 14:17, Gould, James ha scritto:
>
> I did a review of the latest version of the draft 
> (draft-ietf-regext-rdap-reverse-search-10), and below is my feedback:
>
>  1. Abstract
>      1. It states, “This document describes RDAP query extensions”.  
>         Shouldn’t it be “this document describes an RDAP query
>         extension” in the singular form?
>

[ML] Since the new version introduces a new path to obtain information 
about the supported reverse searches and new response providing that 
information, I'll change the sentence as in the following:

".... this document describes RDAP query and response extensions ... "

>
>  2. Introduction
>      1. It is not clear what adopted ad hoc strategies effectively
>         mitigate the impact of reverse searches.  Additionally, a
>         standard search is much less powerful than implementing a
>         reverse search, so I don’t view them as equivalent from a
>         server processing perspective.  Some clarity of how a standard
>         search is equivalent to a reverse search would be helpful or I
>         would remove the statement.
>
[ML] I changed that paragraph in the new version as in the following:

The other objection to the implementation of a reverse search capability 
has been connected with its impact on server processing.
However, the core RDAP specifications already define search queries, 
with similar processing requirements, so the distinction on
which this object is based is not clear.

Does it look fine to you? Should I explicitly refer to searching domains 
for nsLdhName or nsIp when talikng about "search queries, with similar 
processing requirements" ?

> 2.
>      1. How is the domain-entity relationship treated with a special
>         focus on its privacy implications?  Clarification would be
>         helpful.
>
[ML] Would it sound better the following sentence ?

The reverse search based on the domain-entity relationship is treated as 
a particular case, with a special focus on privacy implications of 
querying for sensitive information.

>
>  3. RDAP Path Segment Specification
>      1. Is it defining OPTIONAL extensions or an OPTIONAL extension? 
>         I believe the specification is defining a single RDAP
>         extension, so the singular form would be better.
>
[ML] Removed that sentence from the new version.
>
> 3.
>      1. The searchable-resource-type is limited to only resource types
>         defined in RFC 9082.  Shouldn’t it also support new resource
>         types defined by future RDAP extensions? My recommendation is
>         to have it read “it MUST be one of the resource types for
>         searched defined in Section 3.2 of [RFC9082] or a resource
>         type extension, …”.
>
[ML] Agreed.
>
> 3.
>      1. The related-resource-type is limited to only resource types
>         defined in RFC 9082.  Shouldn’t it also support new resource
>         types defined by future RDAP extensions? My recommendation is
>         to have it read “it MUST be one of the resource types for
>         lookup defined in Section 3.1 of [RFC9082] or a resource type
>         extension…”.
>
[ML] Agreed.
>
>  4. RDAP Conformance
>      1. Based on the definition of a single value, the specification
>         is defining a single RDAP extension and not multiple RDAP
>         extensions as indicated in the Abstract and Introduction.
>
[ML] Complying to rdapConformance tag "reverse_search_0" means 
implementing, at a least, one reverse search  by setting a pair 
<searchable-resource-type, related-resource-type> in the generic query 
model and, optionally, support the reverse search metadata request and 
response.


Best,

Mario

> -- 
>
> JG
>
>
>
>
> *James Gould
> *Fellow Engineer
> [e-mail] 
> <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com <http://verisigninc.com/>
>
> *From: *regext <[e-mail]> on behalf of Antoin 
> Verschuren <ietf=[e-mail]>
> *Date: *Monday, April 25, 2022 at 9:44 AM
> *To: *regext <[e-mail]>
> *Subject: *[EXTERNAL] Re: [regext] WG LAST CALL: 
> draft-ietf-regext-rdap-reverse-search
>
> WGLC for this document should have ended last week.
>
> But since there is still a good discussion going on between the 
> Document Shepherd and the authors, the chairs have decided to extend 
> this WGLC for another week till Monday May 2nd.
>
> Since we only had 2 valid support messages (not being the authors or 
> shepherd) we would like to ask for more support from the WG as well. 2 
> is very little to declare consensus. Could others please review as 
> soon as Mario has published a new version with the comments from Scott 
> and Tom included?
>
>
>
>     Op 11 apr. 2022, om 15:50 heeft Antoin Verschuren
>     <ietf=[e-mail]> het volgende geschreven:
>
>     Reminder,
>
>     1 more week remaining for this WGLC.
>
>     In addition to the authors, we received 3 responses so far.
>
>     Regards,
>
>     Jim and Antoin
>
>
>
>         Op 4 apr. 2022, om 15:18 heeft Antoin Verschuren
>         <ietf=[e-mail]> het volgende geschreven:
>
>         Dear Working Group,
>
>         The authors of the following working group document have
>         indicated that it is believed to be ready for submission to
>         the IESG for publication as a standards track document:
>
>         https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/
>         <https://secure-web.cisco.com/1ua3m1ygiPX3451lX_xaT9Z-dfjlDPcKJyp8avIFHXnHWndX3bvBPwhtbQU3yIZXz19hRC-18gI3rg7jzG1i7rI75UL5jo68iKqKYLCg2_-lG3zN36bOo2h-UDJuSccsr1TqPJzr-sh4pSgnm5JHfFINaH9HK5TbDl00Ye37nMZ6ecLZQrfipasSmiQTDKvrTDbd1MMXTyIRk2Q3nbS8JPcsGYYX3xs62rg93ONBCUdy48YH1INSVQUwIV2i3d8PO/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-rdap-reverse-search%2F>
>
>         This WG last call will end at close of business, Monday, 18
>         April 2022.
>
>         Please review this document and indicate your support (a
>         simple “+1” is sufficient) or concerns with the publication of
>         this document by replying to this message on the list.
>
>         The document shepherd for this document is Tom Harrison.
>
>         Regards,
>
>         Jim and Antoin
>
>
>
>
>
>         _______________________________________________
>         regext mailing list
>         [e-mail]
>         https://www.ietf.org/mailman/listinfo/regext
>
>     _______________________________________________
>     regext mailing list
>     [e-mail]
>     https://www.ietf.org/mailman/listinfo/regext
>
>
> _______________________________________________
> regext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/regext

-- 
Dr. Mario Loffredo
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